Real Incremental Build - Part 1 – Motivation for small deployment packages

You have deployed version x of your compiled application to your production environment.
Some bugs were resolved and you want to deploy a fix.

You have 2 options:

1. Deploy a full updated build of the application.
2. Deploy differential package only.

Now, Option 1 will clearly work.
You run your build, take everything from the drop location, and deploy it.

Pros:

• You're sure that you won't missed anything.
• All files are compatible with each other.

Cons:

• The package will have big size (lots of MB – depends on your application size)

At first, the size of the patch looks unimportant.

But if you take into account the time it will take to upload it to your production environment and distributed it between your hundreds of applications instances – this would be unwise not to consider this factor. Or if you let users to download this patch from your website – I guess you’ll want to minimize its size to save your bandwidth usage.

on the next parts we will go from this globally described scenario into more detailed one – based on Microsoft TFS (Team foundation server) source control & Team Build. We will try to show how to create a delta package contains only the new and updated binaries and files. We will meet some implantation problems – and hopefully overcome them.

See part 2.

Funny commercial or TFS DB upgrade?

Hi again

This time I'm not here to speak about technology, but to tell you about a very funny commercial produced for the company I work for, about American travel to Paris...

You know what? maybe I'll use the opportunity to share with you some technology issues anyway:

I was in the middle of replacing the machine of our TFS Data layer server, and got to the step where you should tell Sharepoint Services that you have switched Database...

I was using the instruction from "How to Restore Data for Team Foundation Server to a Different Server" document from MSDN:

Type the following command:

stsadm –o renameserver –oldservername
OriginalDataTierServerName -newserver NewDataTierServerName

So I just copied the line from the doc, and paste it into the Command Line Console.
I have changed the old & new server names, and... It didn't worked.

I got "Command line error".

After struggling this for 15 minutes, I found out there is a mistake in the doc:
The second parameter should be "-newservername" and not "-newserver".

So now it worked? of course not!

Struggling again, until I found one comment in WSS Blog from that guy "paisleygo", who says:

There is also the issue with the "typing" the command rather than pasting it. That part is critical - the paste seems to mess up the hyphen character. - So once I fixed all the hyphens in my bat file - things worked great!

Thanks paisleygo!

So my teacher was right all this time: "READ THE INSTRUCTIONS!"
Yes M'em - it was written in the doc to TYPE the line - not to copy it...

Building a Specific Version with Team Build 2008

You need to rebuild your code as it was at a specific point in history (by a label or a changeset)?

With TFS 2005 you would have needed to change the core implementation of Team Build.
See Aaron Hallberg's "Building a Specific Version with Team Build" blog.

But with TFS 2008 Microsoft already put this logic in, and even gave a GUI to use it:

Go to Team Explorer 2008 --> Builds.
Right click the Build definition you want to build.

click Queue New Build.

On the pop up window in MSBuild command-line arguments (optional) write:

/p:GetVersion=version

Where version is the Versionspec by the following syntax:

Hope it will help someone.

My TFS 2008 installation experience

Saturday night - 20:00 - At my home

Connecting to work VPN.

Uninstalling TFS Proxy, TFS Build, TS Web Access, TFS Application layer, TFS DB layer.
Also uninstalling custom web services:

• CI (continuous Integration) - good riddance... (TFS 2008 has a built in CI)
• Build Failure Smart Email Notification Service - (will be reinstalled later)
• Check In notification Service

22:00

last backup before starting.
actually not a standard backup...
I have detach all TFS Databases, and copied the db file and the log file to another computer.

Sunday begins - 00:00

Starting the Installation!
.NET 3.5 already installed so no waste of time here.

00:30

The installer still running...
The installer's CPU is zero.
Checking CPU on the DB - it is working pretty hard. so I let it continue working...

00:45

Still working on the DB side.
Checking the Activity Monitor to see what happens - It works on the Source Control DB.
A short Google search find some blog which says it can take more then an hour if you have a large repository. I do have a large (not huge) repository so I wait.

01:05

A new window pop up with a Progress Bar telling me it updates the source control DB.
Probably Microsoft guessed I have thoughts about canceling the installation...

01:30

The Progress Bar window disappeared. The Source Control DB has been updated.

02:00

The Installer still running...
checking again the activity monitor - Now it works on the TfsBuild DB.

03:30

still on the TfsBuild.
This is the point to tell that before the upgrade I have deleted almost all the build history. so I thought it would take a short time...

Googled again to find there was a bug in Beta 2 regarding this step.
Someone suggested to cancel installation - then delete all data in TfsBuild DB. then retry the installation.

It would be hard to delete all the data as there are relation constraint between the tables...

04:00

Killing the DB Process which has been running for more then 2 hours in the Activity Monitor. it tries to rollback everything.

Deleting the TfsBuild DB.

The Installer pop up a message about failure to upgrade Build DB.
Options: Retry / Cancel.

Bringing it again from backup (attaching it).

Choosing Retry.

06:00

Still on the same process in the Activity Monitor which was started at 04:00...

07:30

My little daughter wakes up.
Preparing breakfast, dressing her up, bringing her to the kindergarten.
(Yes, on Sunday. I'm in Israel. we work on Sundays... which means people will be at work in about one hour and TFS is still in the middle...)

08:00

Heading to work.

08:25 - At work. (yes, I live pretty close to work)

This Process is still running.

deciding to take drastic step:
Installing a clean TFS Database layer on my own computer (not the server).
Backing up the TfsBuild DB from my machine.
Deleting the TfsBuild DB from the server again (pop up again...).
Restoring my Clean TfsBuild DB to the Server.

08:50

Choosing Retry.

09:10

Installation completed successfully !!!!!!!!!!!!

People start to come asking if they can start working. Yes they can.

What has been lost (except from sleeping)? - empty Build history.
The Build descriptions are kept anyway in the source control on TFS 2005 - so they have been restored once I have open team explorer and got latest version for them.

Couldn't be easier, could it?