Source control repositories are an important part of software development. They ensure that data can always be recovered and they also enable continuous integration. Azure DevOps includes features common to modern software development such as source control repositories, continuous integration pipelines, agile planning tools, and more. This course covers several topics which fall under the umbrella of configuring repositories for Azure DevOps.
- Integrating GitHub repositories with Azure DevOps Pipelines
- Configuring permissions in source control repositories
- Configuring tags to organize source control repositories
- Recovering data using Git commands
- Purging data from source control
- Software engineers
- DevOps engineers
- Site reliability engineers
- Be comfortable using Git
- Be familiar with Azure DevOps
Hello and welcome. In this content, we'll explore how to configure tags for Azure DevOps source control repositories. Azure DevOps allows tags to be applied to different resources such as pipeline runs. These are useful for organizing disparate resources. Azure DevOps Git repositories use Git tags, which are a different concept altogether. Git includes two types of tags: lightweight and annotated. Lightweight tags are just named pointers to specific commits. Annotated tags include additional information.
They include details such as the create date and the name and email of the tag creator. They can also be signed and verified using GNU Privacy Guard. Azure DevOps Git repositories support both types of tags, however, only annotated tags can be created from the web portal. Git interfaces such as the command line interface, VS Code, etc., can create both. Annotated tags can be created on multiple pages. I'm going to browse to the primary tag management location by clicking 'Repose' on the side navigation followed by tags. Clicking the 'New' button opens up an interface to populate tag details.
A name is required, so I'll name this beta-release. The "based on" dropdown requires the selection of a branch, tag, or commit. Notice what happens when I select the commits option. It sets focus to the commit search box. Commits are identified by hashes. Before this search locates any commit, it requires the first few characters of the hash ID. Since I don't know any commit hashes by memory, I'm going to apply this tag to the compose branch. The description is required, so I'll enter something here, and I'll click 'Create' to save this tag. This is the general flow for tag creation. Next, I'm going to navigate to the commits page to demonstrate how to create tags for specific commits without having to know the commit hash. This table displays the commit history. Hovering over a row displays an ellipsis on the right-hand side of the row. Clicking it opens up a menu.
I'm going to select the create tag option. This is the same interface to use on the tags page with the based on field prepopulated with the commit hash. I'll complete this form and click 'Create'. Notice it's applied directly to the commit. From this page, clicking on tags opens up the repository to the commit represented by the tag. Notice this dropdown at the top of the page allows branches and tags to be selected. I'm going to review some of these options from the tag options menu. Tags can be used as a starting point for a new branch by selecting the new branch option. Filling out this form will create a new branch based on the commit for which the tag is applied.
The files can be downloaded as a zip file and they can be viewed in the file viewer. The commit history of the tag can be viewed by selecting the View History option. Tags can also be deleted by selecting the 'Delete' tag option. Tag deletion should be performed with caution. Once users have pulled, forked, or cloned a repository, its tags are part of their local repository. This can reintroduce previously removed tags back into the repository. Before deleting tags, ensure that those tags have not been propagated out to other users. Okay, we're going to wrap up here. I hope this demonstration was helpful. Thanks for watching.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.