Software Configuration Management and Agile Software Development

Posts Tagged ‘merging’

Avoiding Merge Hell

March 7th, 2012 by clucca

As you start to scale a software development process it becomes apparent that code and user stories have to be merged more frequently. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate and test those changes with everyone. Each team needs to be able to work on its own schedule, this means that if multiple teams want to work on different sized iterations they can. It also means they can deliver changes as needed and on a regular basis, independent of other teams.

To do this in a traditional Software Configuration Management system, you’ll face two major problems.

You have to merge these code changes daily for them to be of any use.
You also still need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, configuration teams use a single baseline or “trunk” methodology for situations like this, where all changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

In terms of traditional Software Configuration Management, your teams will have to deal with these branching and merging issues. But there are STILL other problems that can happen when you use this trunk methodology:

Delivering 2 weeks worth of changes only causes isolation among teams, because teams are working in such a rapidly paced environment.
It’s too difficult to pick out each user story from the codebase as it is completed because no tracking is in place.
Figuring out the dependencies of those above mentioned user stories is complex.
Identifying what changes came from what branch is impossible.

This “baseline pollution” is not scale-able. There are a few ways to alleviate these issues that break the baseline mold. I recommend using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. AccuRev supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

No comments »

Posted in AccuRev, Best Practices, SCM, SCM Resources, Software Configuration Management, Software Tools, Tips and Tricks, version control

Tags: baseline methodology branching merging traditional SCM

Quick Tips on Branching Patterns from an Expert

February 10th, 2012 by clucca

Share|

The goals of a branching pattern should always to be to manage a software team’s development process and to make this process as easy and straight-forward as possible. With this process, the team should be able to complete all of the things that need to happen in order to release a piece of software. So how you establish this pattern?

Make Merging Changes Easy and Straight-forward

The funny thing about branching patterns is that we often attempt to create a process, but have a hard time following it. Typically someone from the team will draw the branching pattern on the whiteboard, and even go as far to take a picture of it with a phone to send around to teams.

Unfortunately this process doesn’t scale well when development teams have more than a few people. Change management on the whiteboard isn’t an effective system for ensuring the success of a software release.

Branching patterns should be able to support the development process, and mirror the natural flow of the development team as they work towards a release.

To achieve this, we might want to think of branches as a process management tool, not just a place to put a specific release, patch or development build. Promotional branching patterns allow for different “states” of code, which is hugely powerful when working through the development cycle. This is a huge topic that is part of larger conversation. To find out more about promotional branching and merging patterns check “A Guide to Branching and Merging Patterns.”

Provide Private Areas for Teams to Check-in and Integrate

Committing early and often is an SCM best practice. Over the years, developers have been told “If it’s not in source control, it never happened.” To avoid this philosophy, teams may require people to check code in everyday so work isn’t lost.

In a practical branching pattern, teams and developers create both private workspaces and branches, allowing them to create builds, releases, and tests of code before they push those changes to other team members. Avoid using mainline type branching patterns that don’t provide code stages; this leads to broken code and unfinished work making its way into a release.

Manage Distributed Teams

Collaborating and sharing code with distributed teams is more complex than ever – teams routinely develop in one location and test or perform other tasks in another location. This distribution of teams strains the development process, yielding security, auditing, and integration problems.

Development teams must appear to be co-located while utilizing the same process with lower complexity. This means code integrations with other projects should happen in real time, so teams can give each other feedback immediately. The branching pattern and process must be followed by everyone, to ensure they are all on the same page.

Understand What has been Delivered

User Stories, bugs, and requirements drive any process, but the ability to see what changes match such items and the location of those code changes are often overlooked in the branching structure.

There is a magical feature that many SCM tools have, called “change-sets” or “Change Packages” in AccuRev. Change Packages associate your changes in the branch with an issue, so you can stay organized and move issues from branch to branch, without having to remember what file went with what issues.

Take these pieces of advice, and they will help if you want to build a release with “finished” issues or if you want traceability into what people are currently working on for a specific release.

1 comment »

Posted in AccuRev, Best Practices, change packages, SCM, Tips and Tricks

Tags: branching branching pattern change packages change sets distributed teams merging software development process

Branching and Merging, or How to Learn to Love Change

July 11th, 2011 by clucca

Share|

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?