Archive for the ‘change packages’ category

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

Whiteboard Quick Tips on Branching Patterns from an ExpertThe 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.

GDD Quick Tips on Branching Patterns from an ExpertManage 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.

 

 

What’s New in AccuRev Version 5.2?

August 22nd, 2011 by damonpoole

I’m very excited about our 5.2 release! We’ve completed the move to PostgreSQL on the back end, fully internationalized our products, and added a slew of new features, like per-element security so that you can lock down certain files or directories to specific groups or users.

In addition to moving to PostgreSQL, we’ve taken advantage of its capabilities to increase performance in a few key areas such as update, especially when using cross-links, populate, and more. And as a first step towards fully embracing 64bit servers, we now support 64bit CPUs on Linux servers. You can look forward to additional performance boosts as we exploit the capabilities of PostgreSQL in the future.

Haven’t upgraded in a while? Check out what else is new! To get a full flavor of all of the new functionality we’ve added recently, check out recent webinar which highlights what’s new.

If you haven’t tried our plug-ins in a while, we’ve put out new releases of our Eclipse and Visual Studio plug-ins for all versions of AccuRev. Eclipse and Visual Studio plug-ins will work with older releases, so no need to wait for 5.2 to start benefiting from the new features in the plug-ins.

We’ve fully integrated the Web UI into the plug-ins so you can now use all of the following functionality: version browser, annotate, stream browser, and all of AccuWork. Also, in 5.2 you can now access the Web UI with a single click from most screens. For instance, if you want to send somebody a URL of a file or diff, you can just click the “copy to clipboard” button in the toolbar and then compose an e-mail to somebody and paste in the URL. When they click the URL, they will go right to that file or diff. And the Web UI now allows you to print any table that it supports.

While we are in the process of making the new functionality in the Web UI available in all of our UIs, this is a great first step to quickly link to the new functionality.

A Few More Details on What’s Available Via the Web UI
If you haven’t used the Web UI or are using an older version, you may not have heard that there is an entirely new version browser in the Web UI and for AccuWork users- AccuWork on the Web has been completely revamped. For instance, it is easy to search by keyword and you can do drag and drop query editing.

5.3 and Beyond… Here We Come!
The database and internationalization are two very important infrastructure changes which will accelerate both our engineering velocity as well as our market penetration. With our upcoming 5.3 release we will be re-introducing our quarterly pace of releases as we had with our 4.8 and 4.9 releases. With the switch to PostgreSQL and an internationalized code base complete, you will see the release of new functionality faster than ever before. In preparation for 5.3 and beyond, we’ve just launched a new product survey as one of the many ways we collect product priorities. Make sure to look for it and fill it out. It is one of the best ways to have a significant impact on our product roadmap. If you haven’t gotten an e-mail yet, you may not be in our survey database. Just ask your AccuRev administrator for a link.

Configuration Management & Customer Specials Shouldn’t Be Difficult

May 12th, 2011 by jtalbott

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:

customer image1 Configuration Management & Customer Specials Shouldnt Be Difficult

customer image2 Configuration Management & Customer Specials Shouldnt Be Difficult

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.

customer image3 Configuration Management & Customer Specials Shouldnt Be Difficult

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?