How Azure Can Help Your Company Expand In Multiple Regions (4 Of 5)

In a previous article, you were guided through the benefits of running an Azure App Service application in multiple regions. Now that the cloud part of your application is ready, we can move forward by setting up Azure DevOps.

Create a New Azure DevOps Project

Sign in to your Azure DevOps organization.
Select your organization.
Click the New Project button in the top right-hand corner of the page.
Name your project, give it a description. and select its visibility.
Expand the Advanced section.
Select Git for version control and Agile as the working item process template.
Click the Create button.

Establish a Repository for Source Code

Now that your projects are ready to go, it is time to configure Azure Repos to use the Git flow development model.

Initialize your Repository

First, you must initialize the repository. This procedure will create a .git subdirectory containing metadata like refs, objects, and a HEAD file. The HEAD file points to the checked-out commit.

Select Repos from the sidebar.
Click the Initialize button.

Because I’m not going to add any .gitignore files, I have to add a README file to my repository.

Create Critical Branches

I can now move forward with implementing the Git flow development model. First, I am going to create the branches expected by this model:

Expand the Repos tab and select Branches.
Click the New Branch button.
Name your branch and select its base.
Click Create.

The branches and bases are:

The Develop branch based on Main
The Release branch is based on Develop

Protect Critical Branches by Creating Branch Policies

Next, disable direct pushes to these critical branches and require pull requests to perform any kind of changes to them.

From the Branches page, click on the ellipsis icon on the right side of the branch.
Select Branch Policies.

To require approval for a pull request, enable the Require a Minimum Number of Reviewers policy and define the Minimum Number of Reviewers. Repeat this procedure for the main, develop, and release branches.

Branch security

When a pull request is approved, the approver can delete the source branch after merging. By default, this option is disabled. However, a mistake might result in the deletion of one of these critical branches. To disable this option, making the workflow more secure, you must do take the following steps:

From the Branches page, click on the ellipsis icon on the right side of the branch.
Select Branch Security.

In the securities pane that will appear, select the development team’s groups then set the Force Push property to Deny.

Repeat this procedure for the development and release branches.

Clone the Repository

Now that the branches, policies, and securities are properly configured, we can proceed by cloning the repository onto your local machine:

Expand the Repos tab and select Files.
Select Clone on the upper right side of the panel.
Select HTTP and copy the URL to the clipboard.

Open your command prompt and execute the following commands,

$ git clone https://[email protected]/GTRekter/Training/_git/Training
Cloning into 'Training'...
remote: Azure Repos
remote: Found 3 objects to send. (14 ms)
Unpacking objects: 100% (3/3), 739 bytes | 20.00 KiB/s, done.

According to the Git Flow model and the branch protection policies we have instituted, you must branch off a new branch with the following pattern feature-<feature name> of the develop branch in order to push your development.

$ git branch
* main
$ git checkout --track origin/develop
Switched to a new branch 'develop'
Branch 'develop' set up to track remote branch 'develop' from 'origin'.
$ git branch feature-amazingfeature
$ git branch
* develop
  feature-amazingfeature
  main
$ git checkout feature-amazingfeature
Switched to branch 'feature-amazingfeature'

Now that we have set up the local environment, we can move forward with the development.

Create a new application

Because the bare development of the application is out of the scope of this article, we will create and publish a default .NET 5 web application for demonstration purposes.

$ dotnet new web -f net5.0

The results is the following tree,

.
├── Program.cs
├── Properties
│   └── launchSettings.json
├── README.md
├── Startup.cs
├── Training.csproj
├── appsettings.Development.json
├── appsettings.json
└── obj
    ├── Training.csproj.nuget.dgspec.json
    ├── Training.csproj.nuget.g.props
    ├── Training.csproj.nuget.g.targets
    ├── project.assets.json
    └── project.nuget.cache

Before pushing the application to the remote repository, create a solution file and add the web application project to it.

$ dotnet new sln
$ dotnet sln add .\Training.csproj

Push the application to the repository

Now it is time to push your code to the repository,

Stage all the files you want to push to the remote server by using the command git add.

$ git add .
warning: LF will be replaced by CRLF in appsettings.Development.json.
The file will have its original line endings in your working directory

Create a new commit containing the staged files, giving it a descriptive message.

$ git commit -m "Starting commit"
[feature-amazingfeature 98d4c6d] Starting commit
 11 files changed, 311 insertions(+)
 create mode 100644 Program.cs
 create mode 100644 Properties/launchSettings.json
 create mode 100644 Startup.cs
 create mode 100644 Training.csproj
 create mode 100644 appsettings.Development.json
 create mode 100644 appsettings.json
 create mode 100644 obj/Training.csproj.nuget.dgspec.json
 create mode 100644 obj/Training.csproj.nuget.g.props
 create mode 100644 obj/Training.csproj.nuget.g.targets
 create mode 100644 obj/project.assets.json
 create mode 100644 obj/project.nuget.cache

Publish the new local commit on a remote server. In this case, you must use the attribute set-upstream origin to set an upstream remote.

$ git push --set-upstream origin feature-amazingfeature
Enumerating objects: 16, done.
Counting objects: 100% (16/16), done.
Delta compression using up to 8 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 4.19 KiB | 1.40 MiB/s, done.
Total 15 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (15/15) (27 ms)
remote: Storing packfile... done (118 ms)
remote: Storing index... done (48 ms)
To https://dev.azure.com/GTRekter/Training/_git/Training
 * [new branch]      feature-amazingfeature -> feature-amazingfeature
Branch 'feature-amazingfeature' set up to track remote branch 'feature-amazingfeature' from 'origin'.

Managing pull requests

Now the feature branch with your code is on the remote server. Once the development of your feature is finished, you need to merge its content with that of the base develop branch. Because of the branch policies that we previously set up, you can’t perform a base git merge operation; you need to create a new pull request. To do so:

Select Pull Requests and click New Pull Request.
Select the source branch (in this case b) and the target branch (in this case develop).
Give a name and a description to your pull request. Add optional reviewers.
Click Create to confirm.
The approver will receive a pull request notification. After entering the pull request details, the approver will be able to start a discussion between the members by adding a comment, adding other reviewers, or approving or rejecting the pull request.
Once the pull request reaches the minimum number of approvals, a Complete button will appear in the upper right-hand corner of the page.
From the Complete Pull Request pane, you can decide the merge type, decide how to handle work items after merging, and delete the feature branch once the merge is completed.

IMPORTANT
The option to delete the branch is not available on the main, develop, and release branches because of the branch securities that we previously set up.

In the next article, we will continue discussing architecture implementation by setting up continuous testing, integration, and deployment mechanisms using Azure Pipelines.

References

Azure Repos