 |
 |
Software development is full of best
practices which are often talked about but seem to be rarely done. One
of the most basic, and valuable, of these is a fully automated build
and test process that allows a team to build and test their software
many times a day. The idea of a daily build has been talked about a
lot. EWI Technologies recommends it as a best practice and it's been
long known as a feature of the Microsoft development approach. We
agree with the XP community, however, in saying that daily builds are
a minimum. A fully automated process that allows you to build several
times a day is both achievable and well worth the effort.
We are using the term Continuous Integration, a term used as
one of the practices of XP (Extreme Programming). However we recognize
that the practice has been around for a long time and is used by
plenty of folks that would never consider XP for their work. We've
been using XP as a touchstone in our software development process and
that influences a lot of our terminology and practices. However you
can use continuous integration without using any other parts of XP -
indeed we think it's an essential part of any competent software
development activity.
There are several parts to making an automated daily build work.
- Keep a single place where all the source code lives and where
anyone can obtain the current sources from (and previous versions)
- Automate the build process so that anyone can use a single
command to build the system from the sources
- Automate the testing so that you can run a good suite of tests
on the system at any time with a single command
- Make sure anyone can get a current executable which you are
confident is the best executable so far.
All of this takes a certain amount of discipline. We've found that
it takes a lot of energy to introduce it into a project. We've also
found that once installed, it doesn't take too much effort to keep it
up.
|
 |
 |