Meeting SPICE requirements with agile tools
Integrated tools for configuration management and change control like Source Integrity or Serena Dimensions offer advantages in an enterprise environment with large globally distributed teams.
At the same time, many client look for more lightweight and agile solutions that better fit a company culture based on delegation and trust.
This post will look at some options with no or low license fees and how these can help you meet SPICE requirements.
On the CM side we have:
The key differentiator between theser two is in my view the distributed repositories in GIT that makes GIT a good option for larger teams which may develop on different branches using different respotories.
Subversion uses a central repository which means every developer commits to the same reposotory. This requires better discipline, i.e. do not commit changes that “breaks the build”. It is also a weaker approach if you do speculative development.
Let us look at the differences between the tools when it comes to handling some SPICE base practicies.
BP3: Establish a configuration management system.
All tools mentioned of course meets the basic requirements of supplying a CM system. GIT and Subversion foucses on one thing only, configuration management. The enterprise tools handle changes and can also be used for work and release planning.
BP4: Establish branch management strategy.
BP5: Establish baselines.
All tools mentioned support baselining, branching and merging on project, folder and document level. Subversion addtionally has a global revision number in the repository whcih can be used as a type of fine grained baseline.
BP7: Control modification and releases.
Source Integrity and Dimensions integrate change control in one tool. Subversion or GIT is normally used with a separate change management tool that when connected with GIT/Subversion provides similar functionality. More about this below.
BP8: Maintain configuration items history.
When using GIT or Subversion with a connected chanage management tool you get links between change sets and change requests. This connection is normally achieved by referring to the change request id in the commit message. This achieves the same effect as in integrated enterprise tools.
BP9: Report configuration status.
This is the one base practice where I believe the enterprise tools excel. Their ability to work with different lifecycle for different configuration items and work with hierarchies of work packages give very good control of work progress and configuration item status. When you use GIT or Subversion this has to be replaced with a manual approach.
Let us look at what change management tools you may want to pair with GIT or Subversion:
- and more
There are quite a number of tools available out there. All tools can do the basics, configure a workflow with different issue types, priorities and so forth.
My normal recommendation to clients is to look at the added values that may be provided by some of the tools. Trac for instance provide an integrated Wiki.
My personal preference is Jira because of the many plugins available. One plugin I would recommend you to check out is the Agile plugin for agile planning and tracking.
In summary it is possible to put together a lightweight combination of configuratiuon and change management tools using for instance SUbversion and Jira and achieve almost the same functionality as expensive enterprise tool.
What you have to consider is the loss of reporting functionality. What you typically have on the plus side is a tool chain which is more developer friendly and creates less overhead.
What are your thoughts?