Software Configuration Management and Agile Software Development

Posts Tagged ‘change packages’

Quick Tips on Branching Patterns from an Expert

February 10th, 2012 by clucca

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

Opening the Desk Drawers of the AccuRev Mind

January 3rd, 2011 by jtalbott

Share|

To borrow from a common print journalism trick, consider this the cleaning out the desk drawers of my AccuRev mind. Or if you tend to avoid newspaper columnists, especially sports ones, then let’s just call this a random “did you know” or “what’s new” post. I think the last time I did one of these was in the AccuRev Version 4.5 days, and we now entered the days of AccuRev 4.9, so there might be a few things tossed in here that aren’t necessarily fresh off the presses…

AccuRev 4.9 introduces the long sought after “stale filter”. Actually, it’s an Update Preview search, but it shows not just (stale) files, but also anything that will change at update time, like moves and new elements. You can even perform actions in that search pane, like Diffs, prior to updating…

AccuRev 4.9 also brings you the -t <time_spec> argument for both stat and pop. This lets you provide a transaction or time stamp to the command so you can reference a configuration of code at a point in time without having to utilize a time-based stream.

Sticking with command-line tidbits, you can now use pop -D to populate elements without including their entire directory structure. Very useful in situations where you might have different applications contained under a root folder yet want to populate them at a top level.

Another really helpful enhancement is to the Deep Overlap search. Now when you Merge a file that is in Deep Overlap, AccuRev changes the status to (kept)(member) in the filter so that you know which files have been operated on. You also have the ability to promote from this search window, and subsequently the promoted file will no longer appear in the filter.

If you haven’t started using the AccuRev WebUI, you’re really missing out. One lesser known capability in the WebUI is the ability to take a regular query, Group by any field, and automatically convert it to a bar, line, or pie chart. This report can then be sent and accessed as a URL, and obviously can be viewed by users without installing the classic GUI.

To further bind the classic GUI and WebUI together, AccuWork issues in the classic GUI now contain a hyperlink “Issue URL” which takes you directly to the URL rendering of the issue in the WebUI. And for those with a very extensive stream structure, have you checked out the St\ream Filter to personalize and only display streams that you care about?

For folks running Continuous Integration, or for those who just want to be able to use command-line to see what’s changed in a stream over time – including inherited content! – I think you’ll be happy with this one. You can use the accurev diff command to compare the contents of a single stream with itself over a period of time, without having to create a time-based stream.

Have you noticed that when using the Stream Issue Mode in the StreamBrowser, you now see Incomplete Issues right in the “Show Active…” box attached to streams?

And lastly for now, bonus points for anyone who can comment here to point out the AccuRev command-line typo that still works as if it is spelled correctly. AccuRevers or former ones need not apply

__________________________________________________________________________________________________________________________________________________

4 comments »

Posted in AccuRev, Agile, Best Practices, change packages, continuous integration, News, Product Review, SCM Resources, Tips and Tricks

Tags: accurev 4.9 branching and merging change packages streambrowser web user interface

Change Packages for Agile Workflow

June 24th, 2010 by damonpoole

Share|

User Story Based Engineering

In other blog posts I’ve talked about using Multi-stage Continuous Integration to scale Continuous Integration for use in multi-team environments and using streams or branches to model your workflow directly in your SCM tool. While both of these approaches work well and provide a lot of value, they can also present a new challenge: how to associate enhancement requests and defects, which can be lumped together using the term “work items,” with the changes that implement them?

If you are doing mainline development, life is pretty simple. On check-in enter the enhancement request ID or defect ID in the comments. Once that association is made, it is fairly straightforward to figure out which enhancements and defects have been checked in. On the other hand, the more people you have checking in to the same branch, the less likely it is to be stable, even if you are doing Continuous Integration. So, how can we maximize the benefits of using streams to represent process and integration stages and still have the ability to match work items to the work done to implement them?

Representing Process and Integration Stages with Change Packages

(Let me first point out that while I’m using the generic term “work item” here, in an Agile team one would most likely use the term “User Story.” Both apply equally well in this context, but I’ll stick with work item for now.)

There is an SCM concept that maps to a work item which can be tracked from place to place, and that is a “change package.” It is called a change package because it represents something which, once defined, can be applied to multiple places and tracked regardless of how many different places it has been propagated.

Change packages can be promoted individually or in groups from stream to stream. That way, as work is promoted from stream to stream you have a record of the content of each stream from a high level perspective instead of a files perspective. A list of files is not very meaningful or useful. On the other hand, change packages allow you to ask questions like “which user stories are in the stream that represents all user stories that are ‘done’,” without having to resort to mainline development.

No comments »

Posted in AccuRev, Agile, Best Practices, change packages, continuous integration, user stories

Tags: Agile Best Practices change packages continuous integration SCM Software Configuration Management software development user stories