The enterprise software development arena can be a harsh and unrelenting environment – not a place for the faint-of-heart to work. Fortunately, software configuration management (SCM) software can make it not only more tolerable, but more efficient and, yes, even more successful.

SCM software is not a luxury, nor just another layer of technology to be added to an already complex process. SCM software is a necessity for development teams working concurrently and in parallel on development projects, especially those employing agile processes to deliver higher quality software more rapidly.

Two of the biggest benefits of using SCM software are the ability to coordinate distributed teams and parallel development more effectively, no matter where your team members are located or even the language of the replicas being used – they can be in the next cubicle, the next state, or the next country.

We, of course, recommend AccuRev SCM

No surprise there. After all, we designed it to be fast, flexible, scalable, and effective. After all, we’ve taken process management and version control and made the ideal mash-up that provides the most comprehensive set of SCM tools available, including these best practices:

• Change management
• Visualized SCM patterns
• Automated workflows
• Private developer history
• Multi-stage continuous integration
• Issue-based development

With a single set of comprehensive, best-practices SCM tools to work with, life becomes much easier for your development teams – they can focus on software development instead of management and administration tasks. SCM software made nice and simple.

What makes it even easier is how AccuRev SCM easily handles virtually any combination of development processes, including Agile, XP, and waterfall – you name it. You’re free to mix-and-match because AccuRev SCM’s flexible model enables your teams to rip through development with continuous integration, code refactoring, and automated code sharing, to name a few.

Even parallel development is a cinch with fully-transparent code base relationship management that enables teams to store work safely and test it before sharing it with others. A stream-based architecture makes code branching and merging easier, too – it even allows changes to be automatically inherited from other teams.

If for some reason you’re not already using SCM software or if you’re unhappy with whatever software configuration management tool you’re using now and you want to know more about SCM software and AccuRev SCM in particular, check out our SCM Software Resource Center and AccuRev SCM 5.3.

Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! You need to trust me on this one, SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases
• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy
• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system. Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

• Merge early and often
• Enforce a workflow for development teams to follow
• Record and have full visibility into all of the changes that were made
• Write build and compiler scripts
• Automate builds, deploys and tests
• Understand the dependencies between projects and code
• Maintain the development environment for a team
• Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At it’s core, SCM answers the question “Somebody did something, how can one reproduce it?” In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!

As the software development process has evolved over the past couple of years – particularly enterprise software development – one aspect  of software configuration management has drawn increasing attention as a means for controlling risk and maximizing success rates. Of course, I’m talking about software release management.

What is software release management?

It’s the practice of doing all the builds for the various aspects of a project and then moving all those builds to its particular process – development to QA to user acceptance to production to deployment.

What’s made software release management crucial to efficient and timely software development is the use of parallel and geographically dispersed development teams. What was once a pretty straightforward, linear process has now become a major, multi-tasking effort as engineering teams work concurrently on various aspects and features of a product that then need to be merged into a single main trunkline for QA, production, and eventual release to the marketplace.

Compounding this release management challenge are additional issues such as:

• error correction
• additional customer feature requests
• risk management
• product revisions
• manufacturing issues
• general software entropy over time

As a result, the release manager function was developed to deal with all these challenges – a sort of software release management superhero. Part overseer, architect, coordinator and support engineer, the release manager is expected to have a general, transparent view of the entire project development process along with a granular view of every aspect of it. Never mind real-time issue and code change tracking, along with  the ability to head off error propagation and broken builds. How can any one person manage to accomplish all this?

The best answer? With a software release management tool that provides a stream architecture, or something that can be described as “intelligent branching.” Streams are ideal configuration objects because they contain absolutely everything associated with any particular release, making it easy to track the history of the release and merge any changes with minimal (if any) errors. In fact, streams make it easy to dial back the clock and return to virtually any version of a release to quickly and effectively handle any errors that might pop up.

What makes this type of tool particularly useful is the way it helps release managers handle all the important aspects of software production, including build stabilization, QA testing hand-offs, product assessments, and archiving activities, to name a few. In short, software release management makes it really easy to move new builds to any one of the configurations needed in the software development and release process.

Some of the major features of our software release management tool include:

• Use of streams to store and make available complete code files for all release versions
• AccuRev TimeSafe architecture for atomic application of all code changes to minimize errors
• Integrated issue tracking
• Improved developer productivity

The holidays are still several months away, but for software development teams in the travel industry, the “hustle and bustle” of the season is already here.

If you think about the ways you make your business or personal travel plans today, you’ll begin to appreciate the increasingly complex software development challenges travel websites present – and the importance of advanced SCM tools.

Just 10 or 15 years ago, many of us were still making travel arrangements through an agent – on the phone or in-person.  We may have gone online to check out a hotel and moved to another site to check on flights – and yet another to rent a car.

Today, travel websites like Kayak and Orbitz bring together all these consumer options and more – and others include frequent flyer miles, preferred guest points and other information related to our travel plans, often involving outside partners.  All of these variables are changing rapidly and are updated dynamically and in real time on travel websites.  This places greater demands on software development teams – teams that are increasingly distributed across multiple time zones and locations.

Also important to note is that the changes and updates these teams are called on to make are increasingly “business-critical.” A software glitch or a site crash can result in major revenue losses, not to mention the residual consumer frustration and damage to the brand.

More variables, more frequent updates and a more business-critical focus — now magnify all this during the many times of peak travel or weather-related interruptions and one begins to understand why more advanced SCM tools are required in the travel industry today.

Basic software development tools may have been fine for some organizations in travel — smaller airlines or hotels with more basic informational web sites that aren’t designed to process high volume reservations and transactions.  But such basic sites are becoming a rarity in the travel industry, leading more and more travel and hospitality businesses to turn to more advanced software development solutions.

AccuRev’s SCM solutions are designed to handle today’s most complex software development challenges, which explains the growth we’re seeing in travel and hospitality business customers.

So when the holidays draw near and you go online to book a hotel, schedule a flight or rent a car, you can thank all of those software developers that have been working hard behind the scenes to make sure the site is up and running 24/7.

Mammoth retailer Target must have had very high hopes for big sales when a new designer collection went on sale last week. Unfortunately it ended up being a bust. (The site quickly became overwhelmed and crashed several times throughout the day.) Online retail experts say losses for the retailer could run into the millions as a result.

Scenarios like this are not new, though with a large retailer like Target, it was somewhat surprising. The painful reality of eCommerce is when transactional websites experience dramatically increased traffic, there is always a chance that, without well maintained software development measures in place, crash scenarios like Target’s will occur.

When an eCommerce crisis like this occurs, developers go into fire drill mode to make rapid changes so the site is back up and running as quickly as possible. Software change and configuration management tools play a crucial role in both ongoing updates and crisis management updates, like the Target example.

It’s also important to note that traditional SCM tools won’t cut it when it comes to high volume transaction web sites like Target, Amazon or any major retailer. Most retail and eCommerce sites need enterprise SCM tools that can scale to accommodate large, geographically distributed teams of developers working in parallel. More advanced SCM tools are integral to the success of transactional web sites, both from a day-to-day aspect, and when there are spikes in traffic and transactions for special sales events, promotions, and holiday shopping.

While last week’s incident demonstrated what can go wrong when an eCommerce site experiences significant problems, there are some great stories out there as well.

One such example is that of a very large and well known travel eCommerce site that receives an average of ten million visitors a month.

As with most of the top of travel eCommerce sites, this one is very dynamic. Users can make reservations for airlines, car rental, hotels, sign up for text message alerts about delayed flights, rate their own experiences and much more.

While these features are popular with consumers, these transactional environments are highly complex to manage. At this particular website, there are as many as 40 different development teams working on 40 different projects. One “project” might be car rentals, another hotel reservations, etc.

When development environments have this much complexity, when teams are working in parallel on a wide variety of projects, only the most powerful SCM tools can help minimize version control problems that lead to bugs slipping through. What may appear at first to be a minor issue can, in the worst case scenario, cause an array of site problems and crashes that have a direct impact on the consumer and revenue. This travel site, which uses AccuRev’s SCM solution, is able to do everything possible to ensure the site and the software behind it stay up and running smoothly, 24/7.

The web storefront is a business critical tool for any type of eCommerce business.  For these reasons, enterprise level SCM tools under the hood are essential to success.

What other similar success and web crisis/failure stories have you experienced directly or heard about?

Source code control is one of those topics that can cause some software developers to sweat profusely and make the veins to pop out of their necks, especially if the project includes working with third-party or vendor code – and these days, what project doesn’t include vendor code?

I should probably start by defining source code control as that mechanism for checking source code in and out of a central repository, enabling several developers to work on the same project simultaneously without the risk (hopefully) of mucking up the source code in the process.

If that isn’t difficult enough already, add vendor code customization to the mix and even the sanest developer becomes a serious candidate for expensive therapy. After all, isn’t traditional branch-and-merge challenging enough without adding a entirely new layer of software configuration management for the vendor code and its corresponding upgrades?

Most of the headaches associated with source code control and management can be attributed to traditional, file-based branch and label source code control tools. The problem stems from traditional branch-based SCM models that require numerous branches to track both vendor source code and custom modifications to that code. Individual branches are needed to track just the vendor code, making merging really unwieldy, especially if you want to do a branch-to-branch merge. Throw in a vendor upgrade and then try to merge a subset of existing custom features and you can see how this can rapidly get ugly.

What’s the answer? Real simple: streaming.

Think of streaming as “intelligent” branching. What makes streaming so great for source code control is that each stream contains every single file needed for that specific source code configuration. They are complete entities unto themselves. Streams can be arranged in a simple “parent-child” hierarchy with a built-in feature that causes configurations to be automatically inherited by every new stream from the parent stream. Even better, the inheritance can also apply to any previous, older streams!

In fact, stream-based architecture provides a host of developer-friendly source code control benefits, including:

• a flexible release process that includes integrated source code control and issue-tracking
• private developer workspaces that enable private versioning  with continual server-backup
• instant, authentic, single-step renaming of any object in the source code control system with full history preservation so no changes are lost

If you’d like to know more about stream-based source code control, especially when using third-party code, we’ve got a free white paper you can download: Managing Vendor Code Customizations with AccuRev’s Stream-Based SCM.

I mentioned on this blog last week that AccuRev had big news coming that would mark the next phase in the evolution of SCM – the first big leap since AccuRev introduced the stream-based approach. Well, the big news has arrived with this week’s launch of AccuRev SCM Version 5.2. AccuRev Version 5.2 arms developers with one of the few SCM solutions on the market today that offers streams and enhanced enterprise performance, reporting, security, and scalability through the postgreSQL relational database we’ve embedded into our system.

With this release, AccuRev has also introduced AccuWorkflow 2.0, a collaborative process-centric governance tool that enables automation and compliance with an issue-based lifecycle workflow directly within AccuRev. AccuWorkflow is especially valuable for developers of software solutions for highly regulated industries such as financial services with its stringent requirements for SOX compliance.

AccuRev 5.2 is available immediately.  Check out the press release here  for more details, or see us demo 5.2 at Agile 2011.   You can also check out a brief podcast we put together that examines the major issues and challenges today’s enterprise developers face and how we’ve attempted to help solve those challenges with AccuRev 5.2.  Click here to listen in.

For more info, check out What’s New in 5.2.

One question I hear a lot is “what’s so important about change and configuration management systems? Isn’t that just another layer of software that can clog up the software development process?” The fact is, a majority of software projects fail because of poor change and configuration management and improper use of SCM systems.

So what seems to be the problem? Well, efficient software development is often muddied by the increased use of outsourced development teams spread out over a variety of geographic locations, using a mix of Agile and waterfall modeling processes, and working on parallel projects. Choosing the wrong SCM system can reduce development efficiency, lock engineers into inappropriate processes, and cause defects to ship that can cost a boatload to fix and adversely affect overall product quality and, ultimately, customer satisfaction.

The right SCM tool, however,

• enables flexible processes for easier change and configuration management
• stands up to demanding frequent build, test, and release cycles
• helps improve quality while reducing the cost of the shipped product

In other words, the right SCM system, properly implemented and used, will make the entire software build, test, and release process faster, easier, and more successful. And isn’t that the whole idea?

Any good, comprehensive SCM system consists of four basic elements:

1. Version control, which tracks changes to a file over time
2. Build management, which enables developers to track a build’s progress and what goes into it
3. Release management, which handles the transition from initial build to shipped product
4. Process control, which ties it all together

The right mix of these four components will depend on the project size – more complex projects might require more build management, frequently-updated products might need more release management.

Size matters.
One of the most important aspects of efficient and effective SCM is right-sizing – making sure your SCM system is scalable to meet the size and scope of your development projects. Too often, organizations struggle with a one-size-fits-all SCM system that is simply inappropriate for the project at hand. Likewise, use scalable best practices; for example, don’t waste precious time and resources collective extensive project metrics for one-off projects – save the thorough data collecting for more complex builds, potential version updates, and product line extensions.

Managing change and configuration
All development processes, waterfall or Agile, need to handle branching, merging, and refactoring as efficiently as possible. Code often needs to be modified or revised for maintenance purposes or to facilitate emergency releases associated with defect repairs. Your SCM system needs to be able to handle branching, merging, and refactoring effectively to ensure that any fixes carry forward from maintenance releases to major future releases so that any errors or bugs don’t perpetually pop up as ongoing problems after their initial fix.

SCM Best Practices to improve your software development processes
To help you implement the ideal SCM system or improve your current one, here are eleven SCM Best Practices to aid process improvement and make your SCM as efficient and effective as possible:

• Forget one-size-fits-all SCM
• Design scalable Best Practices
• Plan your SCM environment carefully
• Ensure absolute reproducibility for all artifacts
• Require change requests and change packages
• Maintain private developer workspaces
• Create and work from appropriate baselines
• Leverage metrics for process improvement
• Create reusable components
• Merge and integrate as often as possible
• Structure for distributed development

The proper SCM system, implemented well and thoroughly embraced by your development teams, can make the difference between having a wildly successful product or an error-prone disaster that sucks up time, money, and resources in ever-increasing amounts.

Branching and merging is one of those things in software development that tends to drive most developers right around the bend. It’s understandable why so many fear branching and merging – after all, so many things can go wrong once you veer off the baseline and wander into uncharted territory and try to get back. But instead of fearing the beast, here are two tips to help you drag it up out of the basement, smack it around, and show it who’s boss.

Just so we’re all on the same page, branching and merging is defined as the process of duplicating part of a software development project baseline so that some parallel development can take place, say, to fulfill a customer’s change request, then once completed it’s merged back into the baseline.

The fat can hit the fire in two places: first, determining when and why a branch should be started, and then when and how it’s merged back into the main development baseline. Done poorly, both of these actions can result in confusion, errors, and delays. No wonder branching and merging gives developers night-sweats.

Because branching and merging has the potential to be problematic, some developers unintentionally make it worse by either branching too often or merging too late. The result can be increased risk in errors and/or a decrease in productivity.

So what’s a developer to do?

Start by determining what should rightfully constitute a branch – does a branch get triggered by a change request? How about a specific integration effort? Perhaps it’s based on system architecture? These are just a few of the common branching strategies, so you need to decide which one provides you with an acceptable balance of risk versus productivity. Do you want to branch and merge early and often, reducing risk but also slowing productivity? Or are you willing to roll the dice that things go smoothly during development so you’ll hold off on merging to potentially increase productivity and value?

Where things can get really sticky is in the merging process.

So my second tip is to make sure you can fully track all your file changes, especially across code lines, or you run the risk of some seriously broken builds and test failures. At AccuRev we have a branching model that we call streams which provides some great code flexibility to make branching and merging as fast and efficient as possible. Stream branching easily accepts parent code while allowing you to then push code out to other streams. All file versions are stream-based, making merging easier because the entire file change history is available and automatically tracked. Pretty cool.

Here’s the big pay-off – because branching and merging is made a lot easier with streams, development teams can branch more often and more confidently, reducing risk without seriously impacting productivity. Perhaps best of all, it helps you avoid a potentially-disastrous end-of-release merge dump that could result in costly and time-consuming fixes and release delays.

So let’s recap: avoid a branching and merging nightmare by carefully considering the branching model that best suits your needs and your level of risk versus productivity. Make sure that your methodology provides maximum visibility into the process and enables you to fully track your file change history, enabling better decision-making and ensuring more effective merging that’s less prone to errors. The result? Better product,faster, and with less errors. How sweet is that?

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.