Archive for February, 2012

Why Create Branches?

February 20th, 2012 by clucca
Share|

Branching and merging is one of the most critical things a development team must work on over the course of a software release cycle. But there’s a funny thing about branching and merging – it’s usually not thought of as part of the development process. How often do you see a user story called “as a developer I want to merge code to trunk”?

The fact that we often don’t follow a process for the branching and merging of code leads to disarray and pain.  It really shouldn’t be that hard! Teams end up in “merge hell” and deliver changes late to schedule. This problem stems from the way branches are created. They’re often not part of the process and are created from a specific business need, not a from a development practice.

When development teams do create a branching pattern, it’s usually drawn out on a white board or in a Visio document, and is used as a model for the overall development process. While the intention is good, many times these plans become quite complex for reasons that can’t be foreseen.

So, why even create branches, if they’re too complex, and unaccounted for?

Create branches the right way, and use them as:

  • Development Branch – A branch created for a development code configurations and builds
  • Integration Branch – A special branch for parallel teams to integrate code
  • QA Branch – QA branches for QA teams to create builds and environments
  • BETA – A preproduction branch for customer sign-off, etc…
  • Production – All of the content that ends up in prod

If we take a more philosophical view of what branches represent, beyond business needs, they actually serve as workflows for different aspects of the software development process.

 

 

No comments »

Posted in Best Practices, Tips and Tricks

Tags:

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

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.

 

 

1 comment »

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

Tags:

Q&A from “A First Look at Kando,” AccuRev’s Seamless Git Integration

February 3rd, 2012 by AccuRev
Share|

We held a “First Look at Kando” webinar on Tuesday to mark the launch of our back-end platform for security and compliance with Git. Unfortunately we weren’t able to answer all of the questions in the allotted time, so here are answers for some of the most commonly asked questions.

Q: Can a developer use Git without an AccuRev workspace?

A: Absolutely. With Kando, the developer does not require an AccuRev workspace. Kando uses a native git repository, so developers can use Git with no modifications – it works seamlessly with AccuRev on the backend. It’s all native Git-to-Git.

Q: Is the Git repository limited to a single AccuRev stream, or can it follow most or all of the AccuRev depot?

A: The Git repository is not limited to a single AccuRev stream, it is completely configurable. When you create a repository, by default, it’s going to ask you to map the master branch in that Git repository to a stream in AccuRev, but you can set up multiple mappings. You could map 100s of branches to streams if you wanted to.

Q: Let’s say I’m an integration manager for a project. Can I create a Git repo using Kando, Git clone it on my system, and let other users clone from me?

A: You can certainly use that model if that’s how you’re most comfortable, where you clone from the bare Git repository associated with AccuRev, and then other people can clone from you. There’s nothing to preclude that from happening because it’s normal Git-to-Git. Another possible solution would be to have all of your developers push and pull from the Kando repository, then you could merge those changes up to the QA or Master branch using AccuRev or Git if you prefer. Kando supports both models.

Q: What about integration with code review tools (like Gerrit).  We actually use Gerrit as the centralized control for our Git repositories

A: If you are connecting Git to anything, whether it be Gerrit, GitHub, an open source library, etc., everything will work. Because Kando is reliant on Git working natively, you can connect to Gerrit or any other tool that integrates with Git. You can push and pull from Gerrit and GitHub as normal. When you push to the remote that is associated with Kando, which is connected with AccuRev, those changes end up in AccuRev in the stream that you’ve mapped to the Git repository’s branches.

Q: How do you handle bugs in Kando itself? Is there support?

A: Kando is an officially supported AccuRev product. If there are defects in Kando, they’ll be handled through our support and services organization the same as they would with AccuRev. Kando is developed using an Agile development methodology, so as we get feedback on defects and enhancement requests, we will turn around fixes and enhancements as quickly as possible.

Still have questions? Ask below, visit www.accurev.com/kando for more information, or check out the Kando video.

No comments »

Posted in AccuRev, Integrations, News, Product Review, SCM, version control