Software Configuration Management and Agile Software Development

Posts Tagged ‘SCM’

Best Practices to Optimize Continuous Integration

June 28th, 2011 by AccuRev

There are a handful of SCM best practices that can optimize continuous integration. This post will look at:

Establishing a staging and isolation hierarchy
Automating builds at all stages in the hierarchy

Establishing a staging and isolation hierarchy for optimizing Continuous Integration

Proponents of continuous integration commonly suggest branching as little as possible and having developers work directly from the mainline as much as possible. However, this approach has several difficulties:

It puts the stability of the mainline at risk
It presupposes that traditional legacy branches are the only available isolation mechanism
It decreases the flexibility and agility required for fast iterative development

With modern SCM systems, a better approach is to implement a staging and isolation hierarchy for the development process. A staging and isolation hierarchy uses objects in the SCM system to represent the dependencies between development groups and process steps. For example, you may wish to model the following teams and activities:

Release engineering
Quality assurance
Product engineering
Component engineering

Each team or activity is assigned the equivalent of a private workspace (variously called “streams” or “branches” depending on the SCM system). Each team then receives the same benefits of private workspaces that individual developers receive. With a staging hierarchy, changes move from less stable configurations to more stable as they are tested and deemed “good” for the next level. This allows the code to be stabilized as it gets ready for release without developer downtime. It also allows additional separation for each team if needed, so that the team’s changes can be integrated and tested before the components are integrated together.

In this figure, there are four development teams as well as an area for accepting third-party code drops. The teams are located in different geographical areas. The hierarchy represents the normal flow of changes through development from stage to stage. In the example of the above figure, changes provided by the GUI product engineering team in India flow from individual developer workspaces (not shown for brevity) to the GUI stage, where they can be continuously integrated and tested. Mature changes then flow to the UI_int stage and on to the QA and Release (Rel) stages, again being subject to continuous integration and testing at each stage. The web development team in Austin picks up well-tested changes from the UI_int stage and uses them as the basis of their development work; when the web changes are mature they can be pushed up the hierarchy and subject to broader testing in the UI_int, QA and Rel stages.

Using a development hierarchy provides more opportunities for check-pointing. Every change introduced into the system is a potential source of failure, and thus a potential checkpoint. If a change proves to be unstable, you can return both the source stage and the destination stage back to a previous checkpoint. By contrast, mainline development only offers you a single opportunity for check-pointing, specifically, the state of the main codeline itself. Unless your development process includes “freezing” the mainline for a long enough period to build, test and otherwise validate, the chances of isolating and check-pointing at an appropriately fine level of code granularity are slim, making any available checkpoints stale and of limited utility.

Automating builds at all stages in the hierarchy

In order to give developers prompt feedback about the changes submitted, the code must be built frequently, ideally several times per day. A continuous integration server such as CruiseControl, CruiseControl.NET or Draco.NET can be employed to automate this process. The continuous integration server periodically polls the SCM system for changes, populates the changes to the build server, initiates the build process, and reports the results of the build and unit tests. It is important to note here that the continuous integration server utilizes the existing build scripts and build environment to execute the build. For example, if make is used to compile and link components written in C, then the continuous integration server will call the makefile to initiate the build process. Because the continuous integration system uses the existing build, it is important for development groups to devote time and effort to:

Making the build as fast as possible,
Building automated unit tests and
Including unit tests as part of the build process.

Spending time on these items, even if it involves some rework of the build system to make it more compatible with a continuous integration environment, will improve not only the build process but the overall quality of the software release.

When utilizing continuous integration, it is crucial to communicate the results of the builds to the entire development team. Continuous integration system planners should consider a scalable communications method such as e-mail notification or an internal website to display build results.

Continuous integration servers such as CruiseControl come with built-in web reporting that can be easily customized, so that build results can be displayed on LCD panels in common areas at geographically dispersed locations. In this way, team members can easily see and respond to the build results and reduce the “fix latency” often encountered with nightly or weekly integration build approaches.

No comments »

Posted in AccuRev, Agile, Best Practices, continuous integration, SCM Resources

Tags: automation CruiseControl hierarchy SCM Software Configuration Management

SCM Best Practices and Continuous Integration Go Hand-in-Hand

June 15th, 2011 by AccuRev

Share|

There’s no denying that this has certainly been the Agile decade for the software development industry. It’s evident all around us in this tenth year since the Agile Manifesto was created. Most companies and development organizations today have implemented some form or aspect of Agile methodology into their software development processes. Whether you’re aiming for pure Agile or a mixed/hybrid approach, proven best practices in all phases of the software development lifecycle are crucial to success.

This is especially true in the case of continuous integration, one of the foundational aspects of the Agile methodology. The concept of continuous integration, as defined by Martin Fowler, is “a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems.”

With this approach, developers can work more closely in parallel while identify problems and debugging on the fly, accelerating the development process and improving the quality of the finished product. The benefits of continuous integration are tremendous, but can quickly be eradicated if software configuration management (SCM) best practices are not carefully followed.

There are a handful of SCM best practices that can optimize continuous integration. Let’s start with a quick look at the first two:

Using an SCM system to store and version all source code
Utilizing private developer workspaces

Best Practice: Using an SCM System to Store and Version all Source Code

Parallel development and distributed software teams can make tracking changes a daunting task, especially with the frequent changes that occur when using continuous integration methods.

For this reason, it is important to employ a software configuration management (SCM) system to strictly version changes to the code base. In addition to versioning source code, everything needed to build the system should be placed under version control, including the following:

Third-party libraries
Properties files
Database schema
Test scripts
Install scripts

All developers should have at least read-only access to all files needed for the build and should obtain all such files directly from the SCM system. This approach ensures that developers are working with the latest build environment, and is preferable to the common but error-prone practice of placing such files on a shared file server.

To effectively implement continuous integration, all development groups should work from the same central source code repository so that the latest changes from other developers are easily and immediately available.

Best Practice: Utilizing Private Developer Workspaces

In order to fully realize the benefits of continuous integration, software development organizations need to ensure that developers can remain productive regardless of the overall state and stability of the project source code. To achieve this, private workspaces that give developers full SCM capability should be used. Private workspaces enable developers to

work in isolation
revert to known “good” states when needed
checkpoint their changes
share only mature, well-tested code with other team members

The benefits of isolation are bidirectional—it protects developers from incoming changes, and protects the shared code configuration from incomplete or incorrect changes from any one developer. By creating private workspaces, developers receive all the benefits of SCM for their personal use, including the ability to revert to a previous state, viewing and tracking of changes between software configurations, and setting aside changes to begin work on a different task.

Once a new known good state is reached (for example, when a developer completes engineering and testing work on a feature), developers should checkpoint their work, typically by “checking in” or “keeping” the local changes in the SCM system. The checkpoint ensures that the developer’s work is safe on the SCM server and that the checkpoint can be revisited at any time. However, since the changes have not been shared, other developers and teams are not affected.

When a developer breaks isolation and decides to share a code change, he or she is essentially making an assertion that the change has reached a higher level of maturity. This, coupled with the use of local developer builds, helps to ensure that only mature, well-tested code is passed on to the rest of the development team, a primary benefit of continuous integration.

No comments »

Posted in AccuRev, Agile, AgileCycle, Best Practices, continuous integration, Enterprise Agile, SCM Resources

Tags: Agile configuration continuous integration management manifesto private workspaces SCM software source code

Configuration Management & Customer Specials Shouldn’t Be Difficult

May 12th, 2011 by jtalbott

Share|

In the world of software development, or any product, for that matter, one of the things you may frequently be asked to do is to create a “special version” for a specific consumer. This version might be almost identical to something you have already created, but with a few minor tweaks, or it might need to share some of the same core characteristics but have critical deviations in certain areas.

For software development – and the correspondingly essential Configuration Management of that software – I’ve seen how this can be one of the more challenging aspects of the job. It’s not actually the creation of the “customer-special” that’s difficult though; in fact this is usually fairly trivial. Traditional software configuration management, or SCM, systems use the branch-per-variant approach typically, and everyone knows that branching is easy. The hard part comes when you need to manage that customer release in an ongoing fashion. How do you upgrade them to a newer release of your product? They probably won’t want to remain on their baseline version forever. They’ll want to take advantage of new features and fixes, while still retaining their unique aspects. So this brings you to… oh yeah, the actual _merge_ part! That’s where it gets hard. Reliably merging changes from one variant to another is a manual, error-prone, labor-intensive process. Now I remember! That’s why we try to limit branching.

Configuration Management with Customer Specials

Well, all of that messy, cumbersome, and problematic stuff in traditional configuration management systems utilizes a traditional architecture of branches. Fortunately, you use AccuRev, which completely removes this obstruction and makes the management of customer specials not only easy, but elegant as well. Let’s consider the following purely mythical scenario. A company called ‘Stadiums’ that makes Ballparks for general use released Stadiums_Ballpark_2.0 a while back. Stadiums had a customer who wanted a custom version of the Ballpark that had some significant differences. For example, they had special contours to the outfield, a truly unique left-field wall, and a good old fashioned mechanical scoreboard. Those were the changes that needed to be made which deviated from the core Ballpark. So Stadiums made these changes in a dedicated stream, associated their work with issue records using AccuRev Change Packages, and cut the Stadiums_Ballpark_Fenway_1911 snapshot:

Fast forward a few years. It’s been a while and there have been numerous advances in Stadiums’ technology. Ballpark_4.0 has been released. The Fenway people don’t want to purchase a brand new product, but they do want to upgrade. This is where it would get really complicated in a different configuration management tool. To boil it down, Stadiums would have to figure out what changes were made for Fenway back then, what changes have happened in their ongoing development, and intelligently merge these together. They’d probably still want to maintain traceability and reproducibility of the “older” version of Fenway. Some of the other tools out there make this near impossible, some slighly less onerous, but none of them make it simple.

Enter AccuRev. Here’s what you do. Drag the Stadiums_Ballpark_Fenway stream and drop it onto Stadiums_Ballpark_4.0. That’s it, you’re almost done! Because of Inheritance capabilities in AccuRev streams, all the content of Stadiums_Ballpark_4.0 will flow down into the _Fenway stream… except items that are in conflict. Those items will be identified by AccuRev both visually and with status flags, and you will be able to deal with them quickly and appropriately.

In our example, Stadiums developer llucchino has worked on the greenMonster.wall file and replaced class Netting with class monsterSeats. So this file automatically becomes (overlap) in the _Fenway stream and can be merged. There are more teams in the league so the scoreboard.mechanical file has been updated to change various properties. This also is in (overlap) status. But the contours of the outfield haven’t been updated at all, so despite that file being a custom modification for _Fenway, AccuRev intelligently knows that it doesn’t even need to be merged. All other new content was automatically inherited by the stream, and so literally nothing needs to be done by the development team.

It’s that simple. You’re done, go ahead and release Stadiums_Ballpark_Fenway_2011. Another happy customer and it didn’t set you back many man months. Can your configuration management tool do this?