This blog is part of a series.

← Read Part 2: How We Moved from TFS to git: Owning git
 

SherWeb’s CI/CD-friendly git Integration

Repository Strategy

Since a team can work with various repositories hosted on the same server, the following question comes to mind : how many repositories do we create? Once again, the answer came from our CI/CD (continuous integration and continuous delivery/deployment) implementation: one repository per pipeline. This is great for release purposes. Not every application has the same release cycle due to both the current development effort  on the application and its upstream and downstream dependencies.

Branching Strategy

We integrated continuous delivery in our department a year ago and created a working group to address all related issues. Given the nature of branching with git, the possibility of releasing only production-ready features while not preventing ongoing development became a reachable goal. We just needed to define a branching strategy which would serve us right. In a nutshell:

  1. Task branches. Long-living branches are bad. Considering other peoples’ experience with everlasting branches, we defined the shortest lifespan possible for a branch: the task branch. Therefore, the master is the only long-living branch and it is protected by pull requests. When a developer starts a task, it branches from master and pushes its code changes in it. When the pull request is accepted, the code change is merged in master and can go into production.
  2. Feature branches. If a task introduces breaking changes which cannot be resolved with feature toggles and the former can only be resolved at the end of the feature development, then a feature branch is created and the task branch is created from it. The task branch is merged in the feature branch and the latter is merged in the master at the end of the feature development.
  3. Release tags. When the department decides to release a version of an application, the latest commit going into production is tagged with the version number of the application and the continuous delivery pipeline is launched with the commit. If a hotfix is later needed for this production version, a branch is created from this tagged commit and then two strategies can be used. This can vary depending on the complexity of the fix and the history state of the repository :
    1. Cherry-picking: commit the fix in master and cherry-pick the commit in the hotfix branch; or
    2. Merging: commit the fix in the hotfix branch and merge the fix in master.
  4. Branch naming. With the multiplicity of short-lived branches, there is a need for specifying branch names, so collaboration is eased. We used the feature that makes a forward slash treated as folder by some git client (e.g., SourceTree). Therefore, we are naming our branches as follows: <team name>/story <story number>/task <task number>. This naming can change from one team to another, but the first portion <team name> is always present so teams can collapse other team branch groups and within a team, the naming can vary to better suit the team’s needs

 

Choosing TFS to Host git Repositories

Our department chose TFS to host git repositories for a number of reasons. First, TFS is already used to manage the agile development process (read work items, sprints and backlogs). We could have chosen to shift the agile management process to some other solution, e.g., Jira. However, this would have slowed down the migration of the code base tremendously, which was the only requirement.

Second, Microsoft acknowledged git is trending, so they put a very significant amount of effort to support git in its 2015 version. As a result, we could only migrate users from 2013 to 2015. This was a significant effort, but we are now using the version Microsoft supports for git and we’ve also gained interesting features for agile management. Conclusion: everybody won something here.

Third, the CD pipeline acknowledged TFS work items, so no effort was required.

Migration note: Microsoft’s TFS is new to git. Therefore, you should follow releases closely because key features are included in every release to close the gap with existing git servers.

Tune in next week for the final part!

 
← Read Part 2: How We Moved from TFS to git: Owning git

Written by Guy Lépine Employee @ SherWeb

Guy Lépine has a degree in Computer Engineering from the Royal Military College of Canada in Kingston, Ont. He has worked as a computer engineer in the private sector and has also held jobs as a software developer in various application domains. Guy has a diploma in Project Management from the Université de Québec à Montréal and in Electrical Engineering Specializing in Computer Security from the Université de Sherbrooke. Guy has participated in several software development projects using the Agile methodology.