Every high-functioning organization has a “master plan” that details how they are supposed to operate and accomplish tasks. The military has organization charts. Construction contractors have critical path scheduling. Mathematics (not an organization, I know) has Order of Operations.
The world of software development is no different. While there are many project management methodologies and performance monitoring tools, there is one system that defines it all. That system is called software configuration management.
Software configuration management (SCM) is a set of processes, policies, and tools that organizes the development process. It simultaneously maintains the current state of the software (called the “baseline”), while enabling developers to work on new versions for features or fixes.
Without SCM, source code would become so fragmented and unorganized that development would be impossible without breaking major pieces of the application. Scaling your development team would be a nightmare because there would be no way to organize the work of individual developers. Software development would be slow, error-prone, and frustrating for everyone involved.
Technically, every team employs some form of SCM, whether they intend to or not. The aim of this article, however, it to define effective SCM and discuss how to accomplish it. The goal of SCM is to improve the speed of and quality of software development by catching errors early and enabling quick fixes when they occur.
Software configuration management structure is comprised of a series of “patterns” that create an organization chart for developing software. Each pattern represents a step where code is either written, tested, or integrated into another pattern and eventually released as a new version of the software.
Steve Berczuk is an engineer at FitBit who literally wrote the book on software configuration management patterns. He outlines 16 different patterns that work together to help agile teams manage their software configurations. Below is a visualization of the patterns laid out by Berczuk.
There are 3 categories of patterns according to Berczuk: core patterns, workspace patterns, and codeline patterns.
Core patterns define the current state of the software. The primary pattern in SCM structure is the “main line”, which is the codeline that is released for deployment. All changes by developers are eventually funneled into this single stream of code.
But what would happen is multiple developers were trying to make changes to the main line at the same time? Very likely, someone would break the software because their changes didn’t integrate with everyone else’s changes. This is where SCM starts to play a role.
In effective SCM, there are other patterns that ensure the main line does not break. The first line of defense is the “active development line”. The active development line is the working draft of the main line. It is a crucial component of agile development because it allows teams to develop and release changes more frequently with reduced risk of breaking the main line.
Workspace patterns are where actual development occurs. These patterns feed into the active development line and eventually the main line. The primary workspace pattern called the “private workspace”, where individual developers can replicate the main line and make changes without impacting the other developers.
Other patterns then feed into the private workspace and enable developers to build, integrate, and test along the way. These patterns include:
For more information on each of these patterns, check out Berczuk’s great article on DZone
Each pattern requires a set of rules and guidelines in order to remain effective. These are called codeline policies. The codeline policies also dictate what tests and integrations need to occur before code is released upstream. These requirements should be automated as much as possible, such as automating tests in the Integration build.
Core patterns and workspace patterns represent a single path of development, or a single release. It is like a river where boats stop at ports along the banks to fill up and check their inventory. Codeline patterns are like creeks and streams that feed into the river. They are separate from the primary development path and are also called branches.
Branches are used when activities could destabilize the main line or considerably slow down development. They use should be used infrequently and adhere to strict codeline policies to ensure they’re used correctly. Examples of when you should use a branch line include:
Along with an organizational pattern chart, effective SCM is based on a set of principles. If these principles sound familiar to you, you’re not wrong. They map very closely to a number of Agile principles.
One of the main values of SCM is to root out redundancy and integration issues. Your team’s default approach to development should be to use as few codelines as possible, only branching when certain caveats arise.
Testing is fundamental to good software configuration management. Each pattern represents an opportunity for testing before code is released to the next pattern in the hierarchy. Performance testing can be done right on your workstation with pre-prod performance tools like Prefix.
Private workspaces are critical because they allow developers to test integration before actually integrating with the main line. Developers also need to frequently integrate the main line with their workstation to account for any changes.
There are dozens of tools that help teams automate critical aspects of the development process. We’ll talk more about those tools in the next section.
Steve Berczuk identifies five categories of tools you will need for effective software configuration management:
This tool will serve as your source code repository and help you manage your software versions. You’ll use this system to replicate the main line state for your private workspace and new branches. Examples of source code management systems include Git, Subversion, and Mercurial.
While build and continuous integration are two separate functions, many tools do both. These tools will turn your source code into an artifact, test it for errors, and integrate it with higher-level patterns. Tools include Jenkins, Bamboo, TeamCity, Maven, Puppet, and Chef. Note that not all of these tools have overlapping capabilities and multiple can be used at once.
A documentation system will contain all codeline policies. A simple Wiki will do, or a well-known spot in your SCM repository.
Artifact repositories allow your team to store, organize, and distribute software artifacts and not just source code. According to Automic, artifact repositories are critical for, “reducing errors and ensuring the right pieces are included with each build/deployment/release.” Artifact repository tools include Artifactory, Nexus, and Archiva.
Improving SCM in your company means improving your patterns, processes, and tools for software delivery. Like any good agile practice, you should start by identifying the top priorities for your organization.
SCM patterns are the most fundamental piece of software configuration management. If your patterns are poorly laid out, then processes and tools will not help. Patterns should be your top priority.
Processes like codeline policies and automated testing are almost as important as the patterns themselves. Make sure everyone on your team knows the processes for working through the SCM patterns.
Finally, look at your tool stack for chances to improve efficiency. This should be the last stage of improving your SCM, because the tools will only work as well as you configure them to do so.
Here at Stackify, we are passionate about agile, automation, and building better software. Follow our blog to learn more about these practices and more.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
