How Can I Keep Code Quality High When Publishing to Azure?

This is part 3 of a series on deploying to Microsoft Azure. Check out the other parts here:

• How can I deploy my ASP.NET website to Microsoft Azure?
• Can I use Git to deploy my ASP.NET website to Microsoft Azure?

How can we avoid deploying flawed code to a production environment? We might be taking care of this if we’ve got a good CI process in place. If we use a tool like TeamCity or TFS. Running automated tests and code analysis. Insisting on code reviews before we commit changes. On a busy project, it can be hard to keep track of everything.

We can make use of pull requests in BitBucket to streamline our workflow. They allow us to make comments against code changes. If a change doesn’t pass a review, we can wait until it’s fixed before we accept it. It’s a powerful way of helping a team maintain code quality. I believe that Continuous Integration and Deployment is the ultimate goal for software delivery. It takes time and effort to set up though. Not all projects and teams are ready to make that step.

In this article, we’re looking at pull requests. We’ll see how they make an excellent code review tool. We’ll look at a branching strategy that streamlines deployments. The workflow looks like this:

1. Start work on a new feature or bug
2. Create a branch for the feature work
3. Once completed, push that branch to BitBucket
4. Within BitBucket, create a pull request
5. Different team member (reviewer) reviews code in pull request, adds comments if necessary
6. If code has issues, go away and fix issues, then repeat steps 3 - 5
7. If code is OK, merge pull request into Master branch
8. If change needs deploying:
   1. Create pull request from Master to Release branch
   2. Review code in pull request
   3. If code is OK, merge pull request into Release branch
   4. Track merge commit within Azure
   5. Test once Azure has deployed changes to live website

Let’s look at this in more detail. We’ll use our old favourite, the DataTables example from the previous article. At the moment, it has one branch called Master. We’ll add to that so we can control which changes we deploy to Azure. We’ll start by creating a Release branch and updating Azure to match it.

Step 1: Create Branches in GitKraken and Make Feature Change

Thus far, we’ve been committing all our changes to the Master branch. To use pull requests, we’ll need to create some new branches. This allows us to merge our changes between those branches. First, we’ll create a Release branch. We’ll be changing Azure so that it watches this branch instead. We need to create it first though. Right-click the Master branch and choose "Create branch here".

Name the new branch "release" and push it to BitBucket. It’s a new branch, so GitKraken will ask you for the name. Origin is the default name for the remote repository. It’s the place your repo originated from. Origin/release means the release branch on the origin repo. Click Submit to push that new branch to BitBucket.

Next, we need a feature branch to do our work. We’ll be creating a new feature branch each time we have a piece of work to do. We’ll then merge that branch across to the release branch to deploy. We’ll do all this through pull requests, as you’ll see. For now, right-click master and choose "Checkout master". Then, right-click master again and create a new branch called "feature\F001-SwapTableOrder". The "feature" part of the branch name becomes a folder. This allows us to group our feature branches together.

Now we need to do the development work on our feature branch. It’s a very complex and important task! The business have decided that we need the users and customer table swapping round. We’ll make a change to the Home\Index.cshtml view. I'll leave that as an exercise for the reader. :)

Next, we’ll stage that change and commit it, as we did last time around. Done that? Great, let’s push our new branch to BitBucket again.

Step 2: Update Azure Watched Branch

Head over to the Azure portal and navigate to the Deployment options for your App service. We need to set things up for our new Release branch. We’ll disconnect and then reconnect using a different branch. Click the Disconnect button.

Now select BitBucket as the deployment source as before. This time, choose the release branch instead of master.

Step 3: Create a BitBucket Team and Migrate Existing Repository

BitBucket works fine if you’re using it as an individual. You set up your repository and away you go. As soon as you want to add other people into the mix, you need to create a team. This gives you a place to group your projects and repositories. It’s simple to set up. From the Teams menu, select Create Team. Give it a name and an ID. You can then add extra team members by email address. If they’re already BitBucket users, they’ll get an email invite to the team. If they’re not, they’ll get an email invite allowing them to create an account. Once they do that, you can include them as reviewers for your pull requests, etc.

• View the original article

Next, from the Projects menu, create a Project. Give it a name and BitBucket will suggest a key to go with it. Add a description and replace the avatar if you wish. Click Create project and on we go.

Now that we have our team and project, we can add our existing repo to that project. Click the Add existing repositories link. You’ll need to add the repository from an existing account, so follow the link. Select the repository from the list of individual repositories. In my case, there’s only one, which is the one we want. Click Add and let BitBucket do its thang.

You need to accept the transfer. Once you’ve done that, you should see the repository listed in your project repository list.

Step 4: Create Pull Requests and Merge Changes Across to Release

Select the repository from the projects list to bring up the repo dashboard. Head to Create pull request in the left-hand menu. BitBucket should select the feature and master branches by default. In our case, Simon is creating the pull request. We’ll add Dave as the reviewer. This is for information, so we’ve got a record of it. It doesn’t affect who can do what. At the bottom, we should see details of the commits included in this pull request.

Create the pull request. We should then see details of the file changes included within the commits. We can add a reviewer comment for the whole request. We can also add comments against individual lines within a file.

If we’re happy with the changes and want to accept the request, we merge it. Once it’s merged, we’ll see details of the merged request. The rest of the team can now pull the master branch onto their local machines. They can then merge those changes into their own branches using GitKraken.

If we want to deploy these changes, we repeat the process. This time, we create a pull request and merge from master to release. As soon as we finish the merge, Azure starts the deployment.

Give it a couple of minutes and we should see success. A quick check in the browser and our changes are now live! It’s not the most brain-straining change. All we’ve done is flip the users and customers tables around. Here’s the updated site in all its glory:

That’s all there is to it. Here’s a quick recap on the flow:

• Create a new feature branch from master
• Make changes and push that branch to BitBucket
• Create a pull request in BitBucket from the feature branch to master
• Merge the changes to close the pull request
• Repeat from master to release to deploy the changes

View the original article.