Design Process - Code Management
Code Management (CM) Tools
Code Management (CM) tools such as CVS or Subversion
should be used to record the history of all source files. When working
with a CM tool, developers should be aware of their actions. Committing
code that will affect others will stop/slow the development process.
Developers that submit code while their working copy is out of sync
(old versions of code) with the repository will most likely break the
Developers can commit code that is
incomplete or doesn't work but they should never commit code that does
not compile. This will break the build and it is highly frowned upon.
To ensure a smooth process, developers should follow the following guidelines:
Build Process and Continuous Integration (CI)
A build converts the source code into a
runnable program. We don't recommend using an IDE to perform a build
since most IDEs are just not flexible enough to include all of the key
features that should be part of a build. Instead, we recommend
automating the build process by scripting the build using tools such as
Apache Ant. Scripting the build makes the process repeatable and much less error prone than building by hand or through an IDE.
Each build should contain a unique build
number, release notes and change log. The build number can be generated
during the build process. The releases notes can be maintained within
an XML file and be displayed within the application. The change log is
automatically generated by the Code Management (CM) tool. This should
include all change files since the last release. Once the build is
created, the files used to create the build should be tagged in the CM
tool. This make it easier for developers to know which version of a
particular file is in each build.
The build process should also make use of
several test environments. A Dev environment can be used by the
internal development team and should contain a daily build for internal
testing. The test team should receive a new build every week or two and
this can be a build that has migrated from the Dev environment to an IT
environment. Finally, the client can perform their own testing and
evaluate the progress of the application by testing within a QA
An important part of any software
development process is getting reliable builds of the software. The
best way to achieve this is to use a process of fully automated and
reproducible build, including testing, that runs many times a day. This
allows each developer to integrate daily thus reducing integration
problems. Ideally, a rebuild should occur every time the code changes.
Several open-source tools are available that support this task with CruiseControl
being the most popular. We also like to couple the use of a Continuous
Integration (CI) tool with a workstation utility called Build Eye which
monitors the current status of the build. Since a new build is
generated whenever the developer commits code to the CM repository,
this Build Eye utility immediately notifies the developer if they have
broken the build.
Return to Design Process