The Tool is the Easy Part – What about the Processes? The FishEye team was the first team at Atlassian to make the switch to DVCS, and while some Atlassians had previous DVCS experience, quite a few had not yet used it in the workplace with a medium-size team of developers before. We looked for help around the web, but there wasn’t a lot of people sharing their experiences at the time. We found many resources like “How do I push a branch in Git?” or “How do I pull from multiple remotes in Mercurial?”, but we found few resources that explained “What is the best way for a 15-developer team to move from SVN to DVCS?” Rather than diving in and prematurely using every DVCS feature out there, the FishEye team decided to keep our old SVN workflows until we got the hang of DVCS. After all, we were still trying to ship new features to our customers as fast as possible, and we couldn’t risk slowing down our development learning completely new workflows. So, we continued to develop new code on trunk up until a couple of weeks before a release. We would then create a release branch to manage last minute features and bug fixes. Once we created our release branch, we would begin new development of the next release back on trunk. When a new version was ready for release, some poor developer was then assigned the time-consuming and painful task of merging the release branch back to trunk using SVN. If we needed any immediate fixes, it was normal to cherry-pick them rather than to merge the whole branch. In practice, our development team could have one or more release branches (e.g 2.5 and 2.6) that they were maintaining at the same time with occasional bug fixes or crucial security fixes. In SVN, the easiest way to manage small bug fixes was often to make the same changes 2 or three times over these release branches. Occasionally, these bug fixes either would not get merged into our latest version, get misapplied, or get merged in once the actual code had been refactored, making it extra difficult to figure out where the fixes should be applied. Copying the SVN workflow with Mercurial, we pushed all of our development on default – Mercurial’s version of trunk. We also strongly advised our developers against using any history modifying commands like histedit or rebaseuntil we were extremely familiar with the tool and the concepts that Mercurial provided. The immediate downside of this workflow for a team of 14 active developers was that by the time somebody pushed his/her commits to our Bitbucket hosted master repository, it was highly likely that someone else had already pushed his/her own changes. This meant you had to hg pull; hg merge; hg commit to integrate their changes, then hg push and hope someone else hadn’t done the same before you! Generally, following our old SVN habits, people started off trying to push after every commit, meaning we had a lot of merges! There were several people in the team agitated that Mercurial created more work! Feature Branches versus Continuous Integration Luckily, branching [...]
Previous Topic
