What is a good practice for building software patches? [closed]

Question

I recently took charge of a software product which was evolved rather unorganized and I have established a new project structure,a source code repository, issue tracking and a buildsystem using nant and teamcity. I'm at the point where every commit to one of the major branches gets compiled, tested and build into a setup.

Always building and shipping full setups seems wrong to me and I'd like to establish some kind of automated patch building, but I have no idea of how to do that. Do you have any suggestions how I could do that or where I could find some information on the topic? Google was no help so far.

Some more details on my current setup:

Repository: - git: -- 2 major branches: development and master

Build system: - teamcity - 2 configurations: one for building each branch - build consists of only one build step: -- nant runner: nant script is part of the repository and contains the following targets: clean, init, compile, test, deploy, build_setup (using inno setup)

I guess I'll have to split the nant script into pieces and use different build steps to somehow compare the new build artifacts to older ones and create a patch containing the updated files. Am I on the right track and if so, does anyone know a good example or tutorial on how to setup teamcity.

Answer 1

Unless what you have is a massive multi-megabyte end-user application, generating patches (which I assume you want to be minimal) is a daunting task, since you'll have to provide patches from each previous version to the most up-to-date one.

Alternatively, you can invest into autoupdate infrastructure, so that an app will update itself whenever a new version is released.

As for building setups for each commit, I personally don't think this is neccessary unless you're continuously testing setup program itself. Rather, complete build should be triggered manually, whenever it's time to release.