1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Implementing Version Control on Azure Repos

Summary

The course is part of this learning path

AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
course-steps
18
certification
1
lab-steps
5
description
1
play-arrow
Start course
Overview
DifficultyIntermediate
Duration38m
Students323
Ratings
4.7/5
starstarstarstarstar-half

Description

This course explores how to implement version control on Azure repos. It begins with an overview of what source control is and the different types of source control available. It then looks at the key elements of branching, different branching strategies, and how they impact the development process. You'll move on to learn about pull requests and merging as repository functions, and the different merging scenarios available to you. Finally, you'll be guided through using third-party systems in conjunction with Azure DevOps. This course contains several guided demonstrations from inside the Azure portal to give you real-world exposure to the concepts covered throughout the course.

If you have any feedback relating to this course, please feel free to reach out to us at support@cloudacademy.com with any questions or comments.

Learning Objectives

  • Understand what version control and Git-based repositories are
  • Learn about branching and the branching strategies
  • Learn about pull requests and merging in Azure DevOps
  • Set permissions on repositories and on TVFC in Azure DevOps
  • Use Azure DevOps in conjunction with build pipelines set up on other platforms

Intended Audience

This is an intermediate level course suited to developers, engineers, and project managers.

Prerequisites

To get the most out of this course, you should have a basic understanding of the software development lifecycle. Knowing what's involved in deploying software to a production environment would also be helpful. If you want to follow along with the demonstrations in this course, you'll need to have an Azure DevOps account.

Transcript

In this course, we've seen how the differences between centralized version control systems like TFVC in distributed Git-based systems impacts multiple and remote teams, and how these different architectures deal with access permissions. I think it's fair to say that Git and its derivatives are the preeminent systems at this time, and the main reason for this is branching.

Branching is technically easy and often referred to as cheap in comparison with centralized systems equivalence. While branching may be quick and easy, as with everything in life, there are no free lunches and all branches must end up being merged back into the main or master trunk in the end. This merge date must be repaid through the pull request mechanism. This is where we see how our different branching strategies evolved to lighten this burden.

Obviously, not all software projects organizations are the same and they have different needs, but what I find interesting is how branching models proliferated, became more complex, and convoluted, but we're always hamstrung by the same basic issue; merging. In this new automated DevOps world, this very important, but potentially manually intensive task is a real fly in the ointment. I like how the release flow strategy goes back to basics, which is trunk-based development off the master branch, but with a twist of using feature flags to isolate incomplete work. This method addresses one of the key pain points by keeping branches as short as possible and related to just one feature or function. Of course, no branching strategy is a silver bullet and the release flow only fulfills its promise with a rigorous testing on branches before the pull request.

There are always going to be situations where you need to revert changes and this is sometimes referred to in complex situations like trying to get the sugar out of your coffee. Smaller branches merged more often can definitely minimize the associated grief in this situation. The bottom line is that all strategies are conventions using the same tools and is up to you to settle on a strategy that best works for you. Having said that, repository systems do offer mechanisms to enforce best practices or the strategy you have decided to adopt.

In Azure DevOps, branch policies can enforce proper behavior within pull requests by requiring a minimum number of approvers, for example. Branch policies also allow you to enforce particular merging strategies. Finally, we took a look at integrating third-party repositories with Azure DevOps pipelines and how to integrate Azure DevOps repos with a Jenkin build pipeline. It turns out we're spoiled for choice with version control systems and it's just a case of finding which one is most easily adapted to your situation.

About the Author
Students7457
Courses12
Learning paths1

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.