Real Incremental Build - Part 2 – Getting only new/updated files

see part 1 for motivation.

So how do you prepare a package with only the new and updated files?
(whether those are binaries, images, aspx files, resource files, etc.)

The simplistic answer would be to ask the developer which files he touched, and either take them themselves or their products (e.g. the assembly which was generated from the source file).

However there could be lots of developers involved who changed multiple files each.
Try to keep a trace of all those files…

You can use your source control to find all new and changes files, of course, but that still requires someone to sit and analyze which of them can be taken as is, and which of them generates changes in end products.

The knowledge of what file update ends up in a new version of which dll or exe sits inside the project files. So you must use this knowledge automatically.

Which means… Build. 

But wouldn’t a build gives us the whole package again?
No. at least not if you use Incremental Build.

Remember when you change some code in visual studio after you already complied big solution?
the next build finishes faster.
Why? because it rebuild only those projects that have been changed.

So let’s see how can we use it:

1. Build the original source (which already in use in production).
2. Write down the build finish time.
3. Get only the changes from source control (all changes from last original check in till last fix).
4. Build again.
5. Get only new files (newer then the original’s finish time) – or – delete all older files.

How to do it technically?

See part 3.

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.

Tamar Yifrach – תמר יפרח - First Music Album

My sis, Tamar Yifrach, has created a wonderful Folk/Pop/Jewish/Hebrew music album:

The album name is: “תמיד היה מזה קצת בעולם” or “There was always a bit from that in the world”.

You can listen to some tracks from the disc in Tamar Yifrach on MySpace
And for the Hebrew readers – her name is תמר יפרח.

Hope you’ll enjoy it.

I did.