Moving to git hasn’t been easy. We, at DeltaX, moved from SVN source control over 6 months ago now. I write this to give an overview/early reaction on how it has been working for us.

Introduction

We had an SVN repository, until Nov 2017, that included most of the projects for and around the web application. Essentially this mono-repo was being used by all developers around the table. The different three deploy environments were each branches on the same repo, along with one development (“trunk”) repository. This repository has been in use for the last 5 years of DeltaX, forked just a year before this migration. The fork covered nearly 30 thousand commits, performed by an average of 20 developers.

Prerequisites for new flow

  • Inspired by distributed version control systems (DVCS) implementations like git-flow. Alas! It wouldn’t work because of the next requisite.
  • Need to have keep a similar environment workflow. That is, to have three environments,
    • Production
    • Staging
    • Testing
    • Development
  • Ability to take features from one branch to another without much hassle.

Development Workflow

  1. Three Permanent Branches
    1. master (deploys to Production)
    2. staging (deploys to Staging)
    3. develop (deploys to Testing)
  2. Multiple feature and hotfix branches which are in active development.
    1. feature/dx-AAAAA-My-One-Line-Description (like dx-1234-rich-media-creatives)
    2. hotfix/dx-AAAAA-My-One-Line-Description (like dx-4321-rich-media-creatives-upload-fails)

alt_text

  1. All development happens on feature and hotfix branches
  2. Feature Workflow
    1. Feature branches are remote branches too
    2. Make sure feature branch is a checkout of development git checkout -b feature/DX-- develop
    3. The is an feature/issue card, that we track on Atlassian Jira.
    4. Commits are pushed to remote feature branches periodically. Convention to commits can be found [here]. 
      git commit  
# DO NOT USE "git commit -m" !! We want well described commits.
    5. Every commit shall include the Jira card numbers that it relates to. This helps us to look it up easier on the CLI or even on Bitbucket.
    6. When a feature is “Dev Complete,” then merge develop to ensure there’s nothing breaking, then, a pull request (PR) is created to merge the feature into the develop branch. The PR is reviewed by at least one person (usually the whole team is added to the review) for approval. 
      git checkout develop  
git pull origin develop  
git checkout feature/DX-...  
git merge develop  
# Ensure nothing breaks
    7. Peer review changes (if any) are implemented under the same PR.
    8. On merge to develop branch, the feature is deployed to testing environment.
    9. The feature is tested on the testing environment.
    10. On testing completion, a release branch is merged to staging, which is then QA tested. A merge here should not arise to any conflicts, if it does your master may be dirty too, with probably a relating hotfix. 
      git checkout staging
git pull origin
git checkout -b release/DX-1234-My-Feature-Branch
git cherry-pick $(git rev-list --reverse --no-merges --grep "DX-<card-number>" staging..develop)
    11. Deployment scenarios
      1. You may keep your feature on staging to be deployed at the end of the sprint, or
      2. You can further merge the release branch to master to make it production deploy ready.
    12. At the end of the fortnightly sprint the staging branch as-is is merged to master. Tagged appropriately with release number.
  3. Hotfix Workflow
    1. Hotfix branches are remote branches too.
    2. Make sure hotfix branches are checked out from master as they have to end in production without any new code. 
      git checkout master
git checkout -b hotfix/DX-...
    3. Hotfixes may merge into any of the first two permanent branches (i.e. master & staging)
    4. Ideally, hotfixes should be tested on staging and then (the hotfix branch) merged later to master for production deployment.
    5. Do remember to merge the hotfix branch to develop.

Differences from SVN

  1. No need to checkout develop before commiting.
    Every code commit on SVN required the developer to be connected to the internet in order to apply the changes on the server. This not only increased development time and productivity but also the commit history is not relatable at all. Every commit was made directly on the environment branch.
  2. Better code-reviews.
    The code-reviews have become much easier than it was previously performed, even more productive with the web interface of the pull request mechanism. One secret sauce is to have ensure all commits include the Jira issue identity so that we can find the progress of a card on Jira too and other related advantages.
  3. Blames and online code exploration is much easier.
    Using the web interface to blame and understand which changes have been pushed to a specific branch eases resolution of many conflicts and root cause analysis of issues.

In the last 6 months, the 25 developers have commited over 5 thousand commits and played around with this repository of millions of lines of code. The shift has given way to a smoother deploy process and much better development experience. While there are companies, like Facebook, who are moulding mercurial, a DVCS, to be inclined towards centralised versioning system, we are venturing into the realm of distributed. Moreover, this progress gives us a chance to rethink the monorepo architecture itself, to learn from the mistakes of others.