In 2019 we had the opportunity to start a project from scratch for a new customer. We decided to experiment with our workflow to try and resolve recurring issues from other projects and use the maximum potential of the tools and products available to us. For Example, as a Microsoft Gold Partner, we are primarily using Microsoft Products for collaboration and project management (i.e. Microsoft Teams, Azure DevOps, Office 365).
One of the biggest changes was the switch from TFS to Git for our code repository and Microsoft Azure DevOps for project and task management.
In this article, I will summarize our approach using these tools including the git client GitKraken which implements the GitFlow workflow approach. Each concept can be used separately but for us, those tools combined gave us a nice and smooth experience.
****Note: GitKraken has a free desktop version but for this tutorial, we are using the pro version which includes Azure DevOps integration.
- Challenges and problems we tried to resolve
- Definition & Tool
- Environment Setup
- WorkFlow in Action
- Starting a feature
- Creating a feature from GitKraken
- Create Pull Request with GitKraken
- Pull Request on Azure Devops
- Pull Request Approval and Code Review
- Multiple Features / Conflicts
Challenges and problems we tried to resolve
This is a summary of what we tried to achieve and why we think these tools combined have helped us in many areas including collaboration, git concept learning curve, code quality, code consistency, and code stability.
Having multiple developers working on the same projects isn’t always easy especially when you try to not step on each other’s feet. A new coder on the team can break the project branch with one wrong commit and affect all other members. Which sometimes ends with stressful and complete chaos for a short (sometimes long) period time on the entire team. Unit Tests can’t be done on dev because the feature isn’t completed yet. What features are being worked on and by who.
Git Flow to the rescue
With Git Flow branching strategy and some settings on Dev Ops no commits can be done directly on the
develop branch. Each developer is required to create a feature branch off the
develop branch. All work related to the feature they are working on will be done there. Once a feature is considered done, the developer has to create a pull request to merge their feature into the
develop branch. Their pull request then has to be reviewed and approved by the project lead, or another member of the team.
Pros we see:
- It forces the project to be split into little features
- Corrupted commits don’t affect other team members
- Dev can easily relate their feature (pull request ) with bugs, tasks, and stories
- Dev branch will receive only approved code (more stable, less potential bugs)
Even as a small company, we struggle to find the right process to perform code reviews. It can be hard to find a tool to review commits correctly or easily provide feedback on the developer’s code you are reviewing. Azure DevOps offer a smart and very user-friendly way to remedy that challenge and it was a huge success using this feature during our last project.
Pull Request & Azure DevOps to the rescue
As mentioned in the previous point. Once a feature is considered done the developer has to create a pull request asking his feature to be merged to the
develop branch. With a few settings on Azure DevOps, we can set multiple criteria for a pull request to be approved.
- Be approved by one or multiple team members
- The project has to build with no errors
- All code review comments must be resolved
- One or more work items must be associated with the pull request
This gave us an incredible way to keep the code consistent, easily explain to your peers what is wrong with their code or approach and at the end lower the number of bugs present in the application.
Definition & Tool
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
Why git is called a distributed source control system?
This is very important and probably one of the biggest mindset changes we had to do from switching from TFS to Git.
A distributed source control system has each user create a copy or clone of a repository on their local machine. All commits made by the user are done so only on their local repository and not directly to the origin repository (server). To synchronize changes between a client and origin repository the user performs, pull and push commands. This allows the user to work independently of others. Then pushing their changes and pulling in the most recent changes when they need to.
In the figure below we have the origin repository while each user has their own repository. With changes being synced back and forth between the origin.
Azure DevOps formerly known as (VSTS) is a recent continuous integration (CI) and continuous delivery (CD) service provided by Microsoft. It works with any managed Git provider and can deploy to most major cloud services, which allow for Azure services. Azure DevOps provides pipelines to configure and automate builds and releases to different environments. These pipelines can be in YAML or as visual models in the Azure DevOps webpages. Azure DevOps is a fast way to automate build (CI) and deploy (CD) projects and make them available to users. source
GitKraken is a Git GUI client for Windows, Mac, and Linux. It helps developers become more productive and efficient with Git. It’s free for non-commercial use. (Need a Pro license to connect to Azure Devops)
GitKraken simplifies complicated commands into drag and drop actions. It makes working with remote repositories easier through integrations with GitHub, Bitbucket and GitLab. It allows you to resolve merge conflicts without ever leaving the app. And it supports Gitflow, Git Hooks, LFS, and more. source
Official site https://www.gitkraken.com/git-client
GitFlow is a branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team.
One of the great things about GitFlow is that it makes parallel development very easy, by isolating new development from finished work. New development (such as features and non-emergency bug fixes) is done in feature branches, and is only merged back into main body of code when the developer(s) is happy that the code is ready for release.
Although interruptions are a BadThing(tm), if you are asked to switch from one task to another, all you need to do is commit your changes and then create a new feature branch for your new task. When that task is done, just checkout your original feature branch and you can continue where you left off.
Feature branches also make it easier for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. That makes it very easy to see and follow what each collaborator is doing.
Release Staging Area
As new development is completed, it gets merged back into the develop branch, which is a staging area for all completed features that haven’t yet been released. So when the next release is branched off of develop, it will automatically contain all of the new stuff that has been finished.
Support For Emergency Fixes
GitFlow supports hotfix branches - branches made from a tagged release. You can use these to make an emergency change, safe in the knowledge that the hotfix will only contain your emergency fix. There’s no risk that you’ll accidentally merge in new development at the same time.
Create a new project
First thing let’s create a new project on Azure DevOps. Of course, you have to make sure the version control is set to Git. The other options can be set to your preferences.
Welcome to your newly created project.
Connect GitKraken to Azure DevOps
First thing is to connect GitKraken to your Azure DevOps. For that, you are going to need to create a Token
When opening GitKraken you should see Azure DevOps option available (Pro Version)
Enter your devops url and click “Generate a token on Azure DevOps”.
You will be redirected to your AzureDevOps personal setting and will be invited to create a new Token
Give it a name and depending on your preferences you can set a maximum of one year validity.
Then switch to a full access scope.
Once you click on create Azure DevOps will give you a Token to copy.
Copy that token and return to GitKraken to past it.
Once you click on Connect you should see your token
You can then make sure SSH Key has been correctly added to your DevOps SSH public keys
Now your GitKraken is successfully connected to your Azure DevOps
Clone your Git Repo from GitKraken
Now you are connected to your DevOps organization you can clone your newly created project.
GitKraken will clone to the location you indicated and invite you to do an initial commit to initialize the repo.
Once the initial commit is done you should see the following screen
To confirm that you repo was correctly initialize. You can navigate to the Repos tab of your project on DevOps and you should see a master branch with a readme file in it.
Initialize Git Flow branches from GitKraken.
We are now going to initialize the Git Flow branching strategy with the help of GitKraken. It will give you a quick way to create new branches (develop, features, releases or hotfixes.)
From GitKraken open the Preferences
And then reach the Git Flow menu
Then click on Initialize Git Flow
You will see now that new menu appeared on your GitKraken main screen but also
develop branch was created locally.
As mentioned earlier Git is a distributed source code repository
develop is only on your local machine. That’s why we can’t see it on the remote yet. It needs to be pushed.
On GitKraken you can see what is on remote and what is on local by checking little icon. Little computer is where local is and the DevOps team logo is where remote is.
On the screenshot bellow, I need to push my local to remote if I want to init the
And that’s the beauty of Git. You can do as many checking you want locally before sharing it with the rest of the team.
First, you need to
checkout the development for Git to point to this branch.
Normally with command line, it would be done by
git checkout develop
Within GitKraken you can simply double click on the develop from Main area or left panel.
Now develop should be focused.
Now you can click push to push all the
develop changes from
origin. This will create the branch on the server.
Unless you want to rename anything or have multiple remote you can confirm by clicking submit.
If everything went well you should be able to see the
develop branch on
remoteand logo from team should be also beside
Setting Branch Policies and Pull Request
As mentioned earlier we want to block people from pushing directly to the
develop branch forcing them to create pull request and also setting some rules for a pull request to be approved. (like can’t be approved by yourself and so on.)
Go on Repo-> Branches menu of Azure Devops
You should see the two branches
First, little thing to do (optional) is setting the
develop branch as the Compare one. Then all the features branch will take the
develop branch as a comparation reference and show how many commits behind or ahead it is.
Click on the 3 dots and then
Set as compare branch
Then we want to setup Branch Policies by again clicking the 3 dots and then
You can now set the rules as you wish.
- Having Reviewers
- Linked work items
- Resolved Comments
- Merge type
- Build validation (we will do a tutorial on this topic as well)
As mention in the disclaimer of that page setting rules will automatically apply the following.
For the purpose of this tutorial I’m going to activate only a reviewer and comment being set to resolve. (I can approve my own pull request but it is for this tutorial purpose)
Here is option example:
Congratulations!: Your environment is now ready to use and setup correctly.
WorkFlow in Action
Starting a feature
Now we are starting a new project which will be a small API made with node.js.
Let say you have all your user stories setup with tasks on DevOps
The first feature I’m going to work on is
project setup. (note here the project is a sample one very small but normal features are a group of one or multiple tasks and not user storied like this example.)
Just to confirm my setting applied. I’m trying to commit my initial files to the
I am able to push against dev locally but when trying to push on remote I have the following message
Creating a feature from GitKraken
Click on Open GitFlow panel on the left panel of GitKraken
Select Start New Feature
Then type the name of the feature and click start feature
Now we can see that we have a local feature folder created with a project-setup branch in it (only locally for now). I can now push my changes to that local
Notice that Gitkraken has a nice code comparison tool with different types of view including side by side view.
We can now as many
commit we want on our local branch.
When a feature is done or when we want to share progression we can push all the changes to remote
Create Pull Request with GitKraken
Now it is time to ask for the feature to be merged with
Of course, pull request can be created on dev ops directly, command line etc.
Here we are going to create a pull request via GitKraken.
Two ways of doing it.
Click Create pull request menu
Or Drag and Dropping the
feature branch to
We can enter the information we want and then create the pull request.
You can now view your pull request on azure. It needs now to be approved to be merged on
Pull Request on Azure Devops
Adding Work Items
You can now add work items related to the pull request (they can be automatically close when pull request is approved )
Reviewers can be set and they will receive a notification via email automatically
One nice feature is you can set some rules whenever the PR is approved like
Deleting feature branch automatically
Set related work items to be resolved, completed, closed …
Now Pull Request is fully setup and is waiting to be approved
Pull Request Approval and Code Review
As a reviewer, you will have all you need to see what was done for that feature.
Azure devops provide a nice and easy way to review and give feedback on your peers’ code.
Indeed in one view only you can scroll through all the changes at once.
Feedback on code
As mentioned reviewers and any people can leave a comment on a specific line of code or an entire file.
A nice feature is the fact that comments can be rich and including many formatting/tagging/images/Pull Request or items reference and much more.
Now a comment is posted we can see on the PR timeline a policy that it doesn’t comply to rules of having
all comments resolved
The developer will be notified about the comment and make the required changes or reply to the comment
He can push his new changes and reply to the comment by tagging the reviewer for example.
The new commit will appear in the Pull Request timeline
If change is good then the reviewer can now resolve the comment
Now Pull Request is ready to approve. The reviewer can click on Approve.
The PR will now indicate that the changes will be merged into
Once Merge being completed the Pull Request will be set to
We can also notice the Tasks and User Story being closed automatically
Finally, we can visually see the merge happened in GitKraken
Notice also that feature branch was deleted from remote. To keep things clean it is better to delete it also locally
Multiple Features / Conflicts
Now any developers can start there one feature without affecting the develop branch
In the following example, we can see 2 features going on
Following the previous pull request creation sequence each feature will have its pull request once completed.
We can see that
develop now is behind and can be tested with the previous request being approved
We will end with pull request for each feature
It can happen that the order of Pull Request being approved and changes may trigger conflicts.
For example, while working on orders feature (product and many others were already done.) Two developers changed the application variable name.
Result being Pull Request indicating that there is a conflict
Merging and Resolving Conflicts using GitKraken
To have pull request completed and conflicts resolved. The developer needs to merge all the
develop changed into its feature.
In that case, we are going to merge
It can be done by drag and dropping
develop on the
Then the conflict will be detected
Clicking view conflicts will show all the files that cause the conflicts
You can click on each file and have access to a very user friendly editor where you can select or exclude any line or even edit the output as needed
Once conflicts edited click on save Now Merge is ready to Commit and Merge
Once commit is pushed. The Pull Request will be ready to be completed.
Once completed you can see how dev once merge before feature being merged itself in
In conclusion, we did a retrospective on this project and all the team members agreed by saying this workflow really help the project and all its participants. All dev have a different level of experiences and different preferences but everyone agreed this was the way to go to work together.
GitKraken really simplifies everything when it comes to deal with all the Git concepts without using a console any single time. This is definitely a tool we want to keep in our work and it will be hard to go back on other code source repositories like TFS or SVN.
Having Git Flow and Pull Request policies in place was a bit challenging at first but in the end, we were always able to provide nice and smooth feedback on each other code which ended with much more consistent and solid code without enforcing strict coding style policy.
Azure Devops is a must-have for us now. Everything is very user friendly and the amount of things we can do with this tool is amazing. One of the policies we had for pull request was the application being able to build (.net core api + angular). We didn’t have last-minute bad surprise we an application not able to build for production and not being able to deploy.