Question

Right now a project I’m working on has reached a level of complexity that requires more than a few steps (actually its become arcane!) to produce a complete/usable product. And unfortunately we didn’t start out with a Continuos Integration mindset, so as you can imagine its kind of painful at times, and at others I can easily waste half a day trying to get a clean/tested build.

Anyways as any HUGE project it consists of many components in many different languages (not only enterprise style Java or C# for example), as well as many graphical, and textual resources. Now the problem is that when I look for Continuos Integration, I always find best practices and techniques that assume one is starting a new project, from the ground up. However this isn’t a new project, so I was wondering what are some good resources to proactively start migrating from Arcane Integration towards Continuos Integration 🙂

Thanks in advance!

Answer 1

Here it is in two simple (hah) steps.

1. Go for the repeatable build:
   1. Use source control, get all code checked in.
   2. Establish and document all tools used to build (mainly, which compiler version). Have a repeatable deployment and set up process for these tools.
   3. Establish and document clearly any resources which are necessary to build, but are not checked in (third party installations, service packs, etc). Have a repeatable deployment and set up process for these dependencies.
2. Before commiting to source control, developers must
   1. update their working copy
   2. successfully build
   3. run and pass automated tests

These steps can be done 1 at a time, sort of a path to follow. You’ll get benefits at each stage. For example, if you aren’t using source control at all, just getting the code into source control (without anything else) is a big step forward. Also, if there are no automated tests, then developers can’t run them – but they can still get the prior commits and get the compiler to check their work.

If you can do all of these, you’ll get to a nice sane place.

The goals are repeatable build processes and developers that are plugged in to how their changes affect the build and other developers.

Then you can reap the bonuses by establishing higher compliance:

• Developers establish a frequent commit habit. Code that is in the working copy should never be more than 1 day old.
• Automated build process monitors source control for check-ins and gets the results to a place where the users can accept them (such as a test environment, a preview website, or even simply placing an .exe where the user can find it).