Putting together an continuous-integration-style automated build
and deploy halfway through the project is exponentially more effort
than starting off with on. At some point in the project, it may even
be that the effort outweighs the gain.
The automated build run at least daily, more often is better, is ideally
the release point of the project. Whatever the result of the process is considered the most recent version of the software, and the last good build is the
current best version. At the beginning of the project, the result is
extremely minimal, but it is working and can be considered the product.
A later introduction of continuous integration misses this benefit.
Instead of starting with a simple working build and nurturing and growing
and evolving it with additional build tasks and deployment steps, the
effort begins with a potentially massive and intricate set of components
to thrash out. Early in the project, the codebase is small and there are
not many pieces to build, and the changes are confined to a smaller range.
Later, the changes are widespread and come fast and furious. At the
beginning of the project, getting all the code to successfully build
and run is easy, and the team can begin to get used to the idea that
this is an ideal state.
Having a working, if incomplete, product seems to encourage efforts to
keep it working. Developers soon discover that checking in small, specific,
changes as often as possible, say on a per-task, basis, is the best way to
ensure the build doesn't break. Team members not already familiar with
small check-ins after every task and seeing the build as the heartbeat of
the project will not gain from a mid-project introduction of continuous
integration.
Later in a project that does not have an automated build of any kind,
it's not unlikely that the code in the repository is impossible to build
without local tweaks. Each team member may be able to get it running
on his or her workstation by ignoring broken bits or setting various
options, so the fact of the entire system is broken may not occur to
anyone. Whatever product that might have been handed off to testers of
for demonstration purposes came together as the result of an individual
or team effort on the workstation of whoever seemed to be most able to
make it work.
This, "but it builds on my machine" mentality hinders acceptance
of the automated build as the "gold standard" against which progress
is measured. The team's rhythm has been set and become accustomed to
another build process. In addition to getting team effort towards the
build process, there is the task of weaning and migrating the team away
from the habits already in place.
Without the will and desire from all members of the team the
task is not only of questionable value it is also not going to get
appreciation.
Previous Topic
