Implementing a version control centric software configuration management (SCM) strategy can help organizations reduce surprises, improve quality and speed results from software development through application lifecycle management (ALM). Senior managers who adopt an overall, automated and Agile development-based source code control (SCC) approach to version control and revision control in SCM can help their teams accomplish those goals.
Source code control (SCC) is a holistic approach to SCM and a mature one. Yet, despite its familiarity, many organizations don’t yet take advantage of well-documented best practices in SCC and even fewer recognize the value of automating source code control systems (SCCS).
Learn six concrete, agile techniques to ensure you’re taking advantage of the latest features and functions in SCCS.
Any SCCS can be customized
There are a number of SCCS technology selections: Git, Mercurial, distributed, hosted, cloud-based, open source and proprietary. Whichever underlying SCC tool you select, it’s crucial to recognize that it can be customized and automated.
Organizations typically make selection decisions through some combination of an engineering “bake-off” and the prestige of internal champions for different choices. Organizations also often decide on their base technology before adoption of ALM more generally. From the perspective of ALM, SCC is generally a “legacy” technology. Whatever your organization’s technology decision, document it explicitly. If you want the advantages of open source tools, but not the management overhead, contract for an external vendor to take responsibility for maintenance of your repository. Cloud offerings have improved so dramatically in recent years that quite a few developers now regard external hosting by a service as the default choice.
Some organizations work with products or methodologies called continuous integration (often called Ci). While CI in its various forms is also related to SCC automation, it’s possible to make considerable progress in automation without adoption of a particular product. Moreover, effective light-weight ALM automations should fit well in any sensible CI .
What I see in my own consulting is that choice of SCC tools or methodologies don’t determine results as much as the use of those tools. Eric Sink expertly documents in his Version Control by example many of the general principles that you need to know whichever specific technology or product you choose. Different tools have different cosmetics and reporting facilities; essentially all of them, though, offer ways to manage file system “trees”—specific examples of folders and files which reflect the source on which a particular application is based.
Even though syntax differs, they all have some query for retrieving the check-ins performed by a particular developer during a particular time interval.
Also, even if you rely on a hosted source code control system (SCCS), there are at least a couple of possibilities for introduction of your own automation, including the following:
- Most hosting services provide at least minimal “hooks” so you can script server-side action This might take the form of a facility to upload server-side scripts, or an event notification service that provides alerts on check-ins and other operations; or
- Client-side automation driven either by alerts as just described or a periodic monitor perhaps tied in to other organization monitors, such as Nagios, Tivoli or OpenNMs.
Implementing SCCS automations
Start to get more value from your SCCS by having it enforce code standards. You want your builds to be healthy, right? Have the SCCS check them. It can also check the style of source-code, run regression tests and validate content languages, such as HTML.
That’s the idea at an executive level, at least; any useful implementation will take a bit of craftsmanship. For example, take the idea of maintaining code health by ensuring that generations or builds are clean. Distinguish a couple of cases: does a typical build take more, or fewer, than five seconds? if fewer, wire the build into the check-in process, so that every check-in results in a build. each build, in turn, is either successful, or not; if the latter, reject the check-in.
What if generations take longer? Again, there are several possibilities; in the worst common case, comprehensive generations are done only overnight. if this is how your organization is structured, then ensure that any failure in a nightly build issues a notice to everyone who checked in source that day.
Notice several alternatives and possible policies have already been presented, including such dimensions as:
- How long does a generation take?
- Does a generation evaluate to a meaningful pass-fail result?
- When a check-in breaks a build, should the check-in be blocked entirely, or allowed, but with reports sent to the author and his or her team?
Other guarantees of quality
Although the state of the build is the most compelling index of code quality, it’s far from the only one. Once that’s in place, you’ll also want to automate some or all of these additional five categories of ALM activity:
- Style conformance—Do definitions have mandated header blocks? Are declarations expressed in the organization’s preferred style?;
- Static source analysis;
- Preparation of check-ins for review—whether by e-mail of checkin diff-s to mentors or whatever else is appropriate for the organization’s preferred workflow;
- Performance of regression tests; and
- Preparation of management reports, including such artifacts as
When they read reports of automated static analysis tools, many programmers accurately observe, “Oh, that—it’s not really an error, because i know that ...” This is often true—but off the point. The appropriate goal is not to allow anything that might work correctly, but to help a team code in a way that’s as likely as possible to be correct. As John Carmack put it recently while recounting his own experience with static code analysis, “Anything that isn’t crystal clear to a static analysis tool probably isn’t clear to your fellow programmers, either.” Automation is critical to this end, moreover; as fond as I am of such other techniques as code review, Carmack further reports “that if you have a large enough code base, any class of error that is syntactically legal probably exists there. in a large project, code quality is every bit as statistical as physical material properties—flaws exist all over the place, you can only hope to minimize the impact they have on your users.” Our only realistic hope to keep these mechanical errors out is through automation, and automation at the time of check-in catches these problems as early as is practical.
Not everything having to do with style can or should be automated. This is part of the reason that SCC, and ALM more generally, remains a toolkit, rather than a product. What you can always do, though, is identify technical choices explicitly, and document the projects and returns you receive from them.
Know the following:
- SCC is an essential part of ALM.
- There is a wide range of SCC technologies and applications.
- With a particular SCCS chosen and policies for its use begun, there is almost certainly a way to ensure that check-ins validate against the build process. This is the automation to tackle.
- SCCS automations will demand coding because there is still so little standardization in SCC. The return on this investment will be large, though.