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 build.

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:

  • Perform an update from top most source tree on a daily basis.
  • Address all messages in the CM status window and resolve all problems.
  • Perform a global rebuild of all the source code. This will wipe out any old class files and ensures that there is no out-dated code included in the compile.
  • Develop the use case to be worked on and make any necessary changes to the existing source code.
  • If a new class has been added or an existing class removed, make sure to add/remove the file in the CM tool.
  • Once development is completed, perform a second update and rebuild all the files again. This ensures that any changes made since the original update will not break the use case code being worked on.
  • Ensure that the code compiles. If it doesn't compile make the necessary adjustments or comment out the code.
  • If there are dependencies on another developer's code, they must commit their changes first. If they are not ready, developers cannot commit their work unless the code is modified to work with the current build.
  • If everything compiles, developers can commit their work from the highest package in the source tree. Developers should always make sure to include a relevant log message when committing their code.
    •

    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 environment.

    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