designmuse » Agile

Continuous Integration Pre-Commit Etiquette

admin — Wed, 25 Mar 2009 03:32:33 +0000

For many agile developers, continuous integration is second nature and breaking the build is rare. But believe it or not there are a number of developers who have never worked on a team that practices continuous integration. Introducing the uninitiated to a team actively practicing continuous integration can be painful for everyone without some guidance. The following is intended to outline some common pre-commit activities and CI etiquette to ease the transition into an agile team.

Pre-commit Activities:

Run test suite – If tests fail, fix and rerun until they all pass
Update from trunk
Merge changes
Run test suite – If tests fail, fix and rerun until they all pass
If committing configuration changes, run smoke test in local environment – if smoke test fails, fix and rerun until it passes

Continuous Integration Etiquette:

Ensure a successful build before leaving for the day
Verify the build on the build server to eliminate any workstation specific dependencies or files
Work in small logical units and integrate often throughout the day
Run tests locally before committing
Notify the team if you are fixing the build
Notify the team of any major refactoring work or configuration changes
Adopt a “stop the line” mentality with the whole team working together to fix the build when it breaks

Hopefully these guidelines will help ensure a painless introduction to a continuous integration environment.

Eliminate Waste

admin — Wed, 10 Sep 2008 03:39:52 +0000

Lines of code is still one of the best predictors of support costs and number of defects. By eliminating unused features, ruthlessly refactoring and eliminating redundancy it stands to reason that we can dramatically reduce the long term support cost. But perhaps an even more effective way to reduce the maintenance cost is to eliminate waste early in the process by not implementing unnecessary features in the first place. Eliminate Waste is a core principle of Lean Software Development with unnecessary features as a key example of waste in software.

Instability of Requirements

admin — Mon, 25 Aug 2008 00:50:12 +0000

Requirements are inherently unstable especially in the early phases of a project. So why over invest in big up-front design based on unstable requirements. All requirements are subject to change in the real world. The only way to introduce a degree of stability is through iterative development and development spikes. This isn’t to suggest that projects should enter into development without some sort of a high-level design. It just means that the time spent in design up-front should be focused on building a roadmap for the product rather than on a graphical representation of the code.