Azure DevOps Services
This post will show the main features of the Azure DevOps services.
Few words about Microsoft Azure DevOps
Azure DevOps has been created as a successor of Visual Studio Team Services, mainly known as VSTS. In general, there is no one application. We should look at this service as a set of tools, which can help in several ways people who use the “DevOps” methodology for continuous delivery of the highest value for their end-users. Summarising, we can use Azure DevOps for storing our source code in the GIT repositories, setup an automatic build and release solutions for every new piece of code committed to the repository, as well as plan & track all the activities related to Agile project management on dedicated backlog and set of useful boards.
Before we start building our pipelines and committing code, we must create a project in Azure DevOps. To do that, we need an account in the service. Account creation is free. When the account will be ready, the new user is able to fill in all the information related to the organisation, and after that he can create a new empty project.
In the Azure DevOps project settings pane, the project owner can decide which features will be used. Below the picture shows a full list of available services. Let´s focus in detail on some of them:
When a new project starts, all the features should be divided into tasks and described in the project backlog. This is a place, where the Product Owner can create a proper order of activities, which will be implemented by the Development Team. Azure DevOps board features provide a way to create Epics, Features, User Stories filled by Tasks etc. Here testers can also create Test-Case scenarios and report bugs or issues.
Azure DevOps provides an access to unlimited, private GIT repositories – Azure Repos. GIT is one of the most popular versions of control systems, with full scope of features like branching, tagging or pull requesting which are covered by the build-in repos service inside Azure DevOps. External providers like GitHub, Bitbucket or GitLab can be used as source repositories of an application code, when a build pipeline will be created in the Azure DevOps.
Information about the build pipeline setup is stored inside the GIT repository in a YAML file. When the file exists in the repository, we can start the configuration process of our new build, and Azure DevOps will automatically use a pre-defined pipeline stored as a code inside project repository. This feature is really great. When in the future someone will need to re-create the pipeline, all information is stored in one file, which can also be used as a some kind of a process documentation.
If the new project is configured, Azure DevOps project owner can use one of the pre-defined templates for build pipeline, and not only Microsoft solutions are supported:
When the build pipeline is ready, we can easily queue our build, and when completed, track building history on dedicated pane:
If something went wrong during the building process, all information will be available in the logs section inside the broken build. History pane shows also all additional information like the branch from which the code has been used for building, an icon adequate for the build status, and the unique number of the build from the solution.
Release pipeline is a functionality which allow us to deploy our application to one or more destinations. Before we begin, we need to setup the correct service connections in the project settings pane. For example, if we want to deploy our web application to Azure App Service, we must configure service connection between Azure DevOps and Azure Resource Manager service. Part of the available service connections are shown below:
In the first step we can decide if we want to use one of the pre-defined stage templates, or if we want to start with an empty job and setup all the steps on our own. Available templates for the stages are for example: “Azure App Service Deployment”, “Deploy to Kubernetes cluster” etc. Picture below shows a part of the pre-defined templates list:
A pipeline can be edited interactively. Every stage can be modified individually, and can consist of a set of tasks like: “Azure PowerShell” script execution, whole “Azure Resource Group Deployment” or even an interaction with Linux or macOS system by “Bash” script.
A sample of the release pipeline is shown below. As the artifacts source for a pipeline has been selected, the build is created in the previous step. We can of course create the release pipeline without an associated build. If our repository contains only scripts, which do not have to be build, we can set as an artifacts source the GIT repository directly.
This post is the 1st part in our Azure DevOps series. Check out the other posts:
Get in Touch.
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.