The Daily Build Process
While building a requirements traceability matrix is great to understand the status of the project and identify functional gaps, implementing a daily build process is excellent for ensuring that the load is consistently stable and developers are not committing code at the expense of quality.
Check Out the Source Code
Check out the source code from the version control system to the workstation where you'll be writing new code. Depending on which version control system you're using, other developer’s may be able to check out their own copy of the same files and edit them.
Modify the Source Code
Modify the source code to implement the feature as per the functional specification. The feature implementation could take days or months to complete. In the event that it takes more than a few days, you might want to commit your code before you're completely done. This is acceptable, as long as you don't break the build. If you know your code will remove functionality or temporarily break the build, create a backup using some other means, or commit your changes to a separate branch.
Build a Private Release
Once you're ready to commit your code to the development branch, first build the load on your own private system, or a system available specifically for building loads. Since this is something you'll have to do on a regular basis, I recommend the build manager writes a script to automate all or part of the process.
Test the Private Release
Test your newly implemented functionality with unit and/or feature tests, and automated tests that you've developed specifically for your feature.
Synchronize your Changes with the Version Control System
Unless you work for a very small company (i.e. 1-2 developers), other developers will also have committed code to the version control system. You'll therefore need to synchronize your changes with theirs. Most systems will automatically merge the code and identify conflicts if they exist. You might however need to manually merge conflicting files. This is why I recommend you synchronize your code on a regular (i.e. weekly) basis.
Build a Private Release
Once again, build a load on your workstation or a system available specifically for building loads to make sure that the synchronized code will still compile and run.
Test the Private Release
Run your unit and/or feature tests, and automated tests to make sure your newly implemented feature still works with the synchronized code.
Execute All Automated System Tests
Once you're confident that your feature works and are ready to commit your code, run the existing automated system tests to make sure that your changes have not broken the build. This is by far the most overlooked part of the daily build process. Developers usually test their own feature properly, but forget to test other part of the system that might have been affected.
Check In your Source Code and Automated Tests
When all tests are successful, commit both your code and the automated test scripts to the version control system.
Generate the Daily Build
At least once a day, at a pre-scheduled time, have a build script tag the load, compile it, and install it on a dedicated daily build system. This environment should be as close as possible to live environment where the customer will eventually deploy the system. When the installation is successful, have the build script run the automated tests, and report any errors to the build manager. Any errors identified must be rectified as soon as possible. Once the daily build is stable, make it available to all project personnel, including developers and testers.
This article was originally published on www.gantthead.com.