What are the reasons to use build scripts and continuous integration?

Question

I'm trying to grasp the idea with build scripts, nightly builds and technologies like continuous integration, but I fail to see the advantages. Take this as an example:

We are a 4-person team developing an application, without unit tests. We also use Subversion for source control.

What benefits do we get by using custom build scripts and things like continuous integration? Do you "need" unit tests for this?

I can also mention that we develop on our local machines, and when the code is working we just update the svn checkout on the production server.

Answer 1

If you don't have continuous integration you will need to wait until someone decides to do an integrated build to find out about conflicting or inconsistent commits. An integrated build is one that incorporates changes from all developers. If each developer is diligent about updating their local working copy then you might be able to get away without a regular integrated build, but really, why wouldn't you automate it?

A test suite will also help uncover changes to behaviour that break things but that do not necessarily cause an integrated build failure.

It is also standard practice to perform a smoke test on the fresh integrated build.

In addition to detecting conflicts and changes that break things, a nightly integrated build means you will always have a recent build that incorporates everyone's work to date. This is a boon for testing and demo purposes.

There's also some fun to be had in thinking up suitable punishments for whoever breaks the nightly build -- the implication is that they committed stuff without checking it was ok, so they should feel some pain in addition to resolving the build-breaking commit.

Answer 2

Well, for a start it would be useful to have a repeatable build from a known environment. If you need to make a small change to a particular version (e.g. a customer is unwilling to move from version 1.5 even though you're now developing 3.2, but you could apply a patch to 1.5 on a branch) it really helps to be able to build easily.

It also means that as soon as you do start writing unit tests you'll derive even more benefit from them.

If you don't have any build scripts/servers at the moment, how do you build what you ship? Just on a random developer box?

Also see the answers to this related question.

Answer 3

So how do you make sure that changes one of your co-workers made won't break any functionality? Do you try and test every single functionality after each check-in? Sounds like a lot of time wasted to me that you could save by implementing unit-tests.

And how do you make sure that the changes made by two or more individual programmers won't interfere in a way that the next person doing a check-out on a clean machine won't be able to build the software? A nice time to realize such problems is short before a planned release.

The reason behind a lot of these techniques is to fail early so you can pinpoint and change whatever just made your precious piece of software stop from working as it should.

Now, you don't need unit tests fro continuous integration, but they are sure a major improvement of your build process and you should definitely consider to read up and make use of them!

Answer 4

Using something like CruiseControl and CCTray gives you confidence, you know when that little icon is green that you can get the latest code and it will most likely work with your local copy.

To get the best from it you need to be in good habits, always getting latest before you commit, etc. It won't stop conflicts, or even broken builds but it will let you move forward with your development with confidence knowing that there is a working version of the software.

Using custom build scripts, again gives you confidence as you can get the build done and then run unit tests, code coverage, fxcop. It all adds to the quality of the main body of code.

As always there's a time and effort cost, but you'll quickly get to a balance of how much quality you need to deliver the software consistently, versus how much testing and code analysis you want to do.

Answer 5

The key advantage of having a dedicated build machine (putting CI, unit tests and even automated builds aside) is to ensure you have a clean, predictable & reproducible build environment.

This alone should lead to more stable product releases. It helps you to find issues with your solution & code base earlier then once you've already deployed/released it. A common example could be components which had been GAC'd on a developer's machine but are missing from the deployed product.

Automated builds are useful because they remove the human element - i.e. they repeat the same steps every time (they aren't as prone to forgetting build steps, for example) - which gives you predictability. If you run the same build script with the same source you should get the same output. This is essential for proper release management.

As you develop a build environment it can be extended to provide more support to the development team - especially once the team starts to grow. The rest can be debated - implemented if you (or your team) can see the value in reducing risk or effort to your project.

Continuous Integration (CI) basically lets you know earlier if there are any conflicts with your project's source/solution - i.e. before the rest of your team gets a broken code base when they refresh their source from source control.

The main advantage here is resolving broken code bases faster - usually when it is still fresh in people's minds (since, in theory, they just committed changes to the source control repository). People do need to keep an eye on it however..

Answer 6

Simply put, we use it to make sure that if someone commits code to the integration branch/release branch, and it's not been properly tested, we find out within 10 minutes rather than 10 days.

We don't use it to test, we use it to backup our testing process.