Best Practices For Setting Up Azure DevOps Projects With Git

As I have been delving into Azure DevOps for a while now, I have discovered some best practices utilizing Azure DevOps Projects that I thought might be useful to share. Also, as my quest into the realm of Azure DevOps has continued, I have had quite a bit of useful guidance granted to me by my friend and colleague Carlos Santos, he also blogs when he has time in his corner of the web, so be sure to check it out sometime.

Setting Up The Project

Once you have secured an Organization, you can create a new Project in Azure DevOps. The Project creation is straight forward, and you only need to fill out a few details before getting started. Here's an example of a project I created for this blog post:

In the Project creation screen, you can choose the visibility of the Project, that is, you can choose Public for open source based code bases and Private for your organization's proprietary code base. Also, you have a choice of the type of Version control and Work item process, in this case Git and Agile, which are the default values and the ideal choices for the majority of projects in my opinion.

Once your Project is created, you will have access to Boards, Repos, Pipelines, Test Plans and Artifacts. I will cover some guidelines for just a few of them in this post, that will help you to get started with a some guard rails in place for all of your Project Stakeholders and Contributors:

Azure Boards

The nice thing about Azure Boards is that they provide quite a bit of flexibility. You can add and remove columns and tailor your board to your needs while also providing a common place where everyone on your Project can view the pulse of your progress. Also, the documentation for Azure Boards is pretty good and it offers quite a bit of information about how to conduct many actions such as adding or editing columns. One thing that I really found useful is the guidance of placing the different definitions for the stage of your story on the actual board. For instance, you can add the Definition of Done to the Resolved column and it would display on the board under the Resolved column information tooltip:

Azure Repos

Your code repository, in my view, is analogous to the central nervous system of your Project because everything that you do stems from it. Therefore, you want to keep it as clean as possible and you also want to guide your engineers to 'fall on the pit of success' by allowing them to do the right thing, consistently. Thus, when first setting up a Git code repository, you can set some guidelines on how you want the codebase managed in your project. In a Private Project, the first thing that you can do is disable the ability for contributors to Fork a Private Project. As opposed to a Public Project, where the codebase is most likely under an open source license and free to fork and use as anyone pleases, your organization's project should minimize the need for forks, unless explicitly requested, in which case you can enable this again. In my sample project, I imported the Parts Unlimited repository from GitHub to use as an example:

You can disable the ability to fork projects by navigating to Project settings/Repos/Repositories then selecting your Git repository and on the right tab screen, under Options/Forks, toggle the ability to Allow users to create forks from this repository to Off:

Consequently, the ability to Fork is disabled for that repository:

Another thing that you will want to do when setting up a Git repository for your Project is to provide policies for your branches. Now, before you set up your policy branches, make sure that you have designed and documented your branching strategy for your Project, as that should be a well known and enforced standard at your organization. Note, that you can use the new built-in Wiki hosted on your Project:

Having a well documented internal branching strategy will also help to guide the Contributors on your project to know how the Release Flow should be conducted. If you would like to read more about Release Flow then this great  article by Edward Thompson from Microsoft should be of interest to you.

Lastly, once you have a well known branch strategy as your standard, you can automatically prevent anyone from creating branches where they should not or outside of the folder conventions you have established. The steps for accomplishing this are already well outlined in the Azure DevOps Services documentation, therefore I won't go into detail about it on this post. However, just be mindful that having those policies in place is key to keeping your branches clean and release ready. It is simpler to manage your branches when the policies are in place before you open the repository for daily usage.

In A Nutshell

In this post I shared a few guidelines that you can introduce in your newly created Azure DevOps Project that will help you to maintain your codebase a bit more pristine and keep things tidy when many folks are accessing your Azure DevOps projects.

Until next time, happy branching :)