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:
- Build the original source (which already in use in production).
- Write down the build finish time.
- Get only the changes from source control (all changes from last original check in till last fix).
- Build again.
- Get only new files (newer then the original’s finish time) – or – delete all older files.
How to do it technically?
See part 3.