Azure DevOps webp image

In the IT world, there are several tools that support application life cycle processes. We use them to automate repetitive tasks and also to keep control over the whole process. They can be divided into two categories: tools that support only separated parts of the process and platforms which can be used to manage the whole process. If you're seeking a set of tools that can speed up your process of delivering IT solutions, you might be interested in the Microsoft platform called Azure DevOps.

What is Azure DevOps?

Azure DevOps is a (SaaS) platform that allows you to implement all your DevOps processes. DevOps is a combination of concepts, tools, and practices to develop and release applications in an automated way with speed and quality. Azure DevOps is designed to support individual DevOps processes and its components to enable the application life cycle to be as efficient as possible. We can point out 5 core services that support each step of the application life cycle. Let's go through this process and see how those services could make our work simpler and faster.

Azure Boards

Development of every application starts with planning - we need to know before work is started what needs to be done, what we want to accomplish and what's the business value of the product we plan to deliver. This is where Azure Boards come in handy.


image source

Define processes and workflow on how the team will work on the application. Assign roles to each team member and split the tasks. Azure DevOps projects support several workflows: Agile, Basic, CMMI, and Scrum, so you can choose one which best suits your team or organization.

In an organization, you can have many projects, and within the project - many teams. Azure Boards supports multiple projects and multiple teams within the organization. It appears to be a very useful onboard tool for communication between project members like developers, testers, analytics, or product owners because of its native integration with other Azure DevOps components. Azure Boards can be used to have an overview and transparency over the status of the feature while it is being developed.


So all this looks like a pretty standard tool for supporting workflows, but Azure Boards also has some interesting features. For example, you can enable DevSecOps methodology. It is delivered in cooperation with Github. Among others, it involves securing the application code in the production environment and enables scanning of the code for vulnerabilities and third-party components.

Checkout Microsoft documentation on Azure Boards.

Azure Repos


The main part of the application lifecycle is code created by developers. Azure provides Azure Repos to host that code. It can support many different workflows like git-flow, which all aim to deliver the best possible quality of code. Like most repository tools nowadays Azure Repos supports developers in their collaboration by not only hosting the code but also the possibility of connecting commits and pull requests to specific requirements or tasks in Azure Boards and tests in Azure Tests.


Checkout Microsoft documentation on Azure Repos.

Azure Pipelines


Once a feature has been developed and its pull request is approved and merged into the main branch, the next step is to release the code. To do so, the code needs to be tested and packaged into an artifact. Once this is done, the artifact can be deployed in the intended environment. This ensures that the feature is available for use by end-users. Azure gives us the means to automate this process. It’s called Azure Pipelines. This is the part where we can automate the CICD process. We can start with Continuous Integration. You can define a pipeline using YAML files, which means that we can store them in a code repository and track their version and also keep them as a part of our code.

Azure pipelines consist of steps, which are the primary building blocks. Steps can be used to perform various tasks, such as running tests, packaging applications, building images, and pushing images to repositories. These steps can be scripted or executed using tasks, which are pre-built commands designed to perform specific actions within the pipeline. Azure Pipelines provides a wide range of pre-built tasks for different use cases, such as building, testing, and deploying applications. These tasks can be easily selected and configured using a graphical user interface (GUI) in the Azure DevOps portal, which simplifies the process of creating and managing pipelines. This allows users to build complex pipelines with minimal coding and scripting, making the development process more efficient and streamlined. If you prefer, you can automatically convert them into yaml format then you can adjust it or add any configuration and finally push it to the repo.


When working with multiple jobs, they must be defined within job attributes. Each job can have multiple steps, and all of these steps can be executed within the job on an agent. With this approach, it's possible to run multiple processes in parallel and improve the overall speed and efficiency of the pipeline. By defining multiple jobs and steps in the YAML file, we can create a more complex and customizable pipeline that meets the specific needs of our project.

The gent is a machine that will execute the tasks or steps of the pipeline. With the pool attribute, we can define what kind of agent we want to run steps (i.e. Linux, MacOS, Windows) and also specific versions of those OSes.

In Azure Pipelines, one common use case for multiple jobs is when we have a set of steps that we want to run in parallel to speed up the overall build process. By defining different jobs, we can distribute the workload and execute the steps concurrently, which can improve the performance of the pipeline.

Checkout Microsoft documentation on Azure Pipelines.

Azure Artifacts


Depending on the application programming language the team will produce different artifacts. For storing this kind of artifact you have another feature called Azure Artifacts. If your artifacts belong to one of the types:

  • NuGet
  • npm
  • Maven
  • Python
  • Universal Packages

you can store them in Azure Artifacts after they are produced in your pipeline.

However very often the result of the build pipeline is a Docker image. If that’s the case you will need a dedicated repository. The easiest way is to use Azure Container Registry, but if you need an external repository like Docker Hub it will require a connection from Azure DevOps to it.

Checkout Microsoft documentation on Azure Artifacts.

Azure Test Plans


A very important part of the application release process is testing. Azure DevOps has a separate component suitable for that purpose - Azure Test Plans. Application code needs extensive testing in all stages of its development. From smoke tests during CI to acceptance testing on pre-production. Test Plans give you support for manual and automated tests. It is a central view of all the test cases that need to be checked before giving a green light to production deployment.


Here you can create manual test cases and plans. When a new feature is ready a tester can go through the steps and test the application.
This could also be automated tests that will be executed as part of the CICD process. Also, test reports from the pipelines can be presented in Azure Test Plans.

Very important advantage is integration with Azure Boards which allows you to run your test from there, for example from the Kanban board.

Checkout Microsoft documentation on Azure Test Plans.


When you run the pipeline, configured tasks have to be executed somewhere. Earlier I mentioned that you can run them for example on different operating systems. So where exactly are those tasks being executed? Azure DevOps is SaaS so all its components work as a service. All configurations, pipelines, and repositories are stored in this service. As for executing pipelines Azure DevOps gives you two options. You can use machines (agents) managed by Microsoft or self-hosted agents which you can configure to connect to Azure DevOps service. If you need total control over agents this may be the option. You can also use both kinds of agents at the same time.


Azure DevOps supports pretty much the whole application development cycle out of the box. But what if you already are using different tools in your process? For example, there is already code in another repo. So let's say after the project has started you decided to switch to Azure DevOps. Does it mean you have to migrate all parts you already started working on to that platform? Well... no. Azure DevOps has integration capabilities. You can use its component connected for example to Github or Docker Hub or when you would like to deploy on other cloud platforms like GCP, or AWS. That's why you have a service connection feature.

The service connection feature in Azure DevOps simplifies the process of connecting to external services. It manages the credentials needed to connect to those services, which are created on the Azure side automatically, and it provides better connection security because the connection secrets are managed by Azure DevOps. This helps to minimize the risk of accidentally exposing sensitive information or misconfiguration of the connection settings. Service connections can be used with a wide range of external services, including cloud providers, code repositories, build and release systems, and monitoring and analytics tools.

Also, you can adjust permission to every connection within your organization and project separately.

Checkout Microsoft documentation on Azure Pipelines Service Connection.

Azure DevOps comparison

There are quite a few tools that can support application development in many popular workflows. It can be difficult to give a simple "yes" or "no" answer when it comes to the question of why one should learn and use Azure DevOps, as it depends on various factors and contexts. However, it can be helpful to make a quick comparison with its competitors to understand how it stands out. On the market, you can find CICD tools like Jenkins, Github Actions, Argo CD, and Bamboo. The main difference is that those are exclusively CICD tools. They are great at automating tasks and executing them in intervals. But as we know DevOps is a collection of activities that span over the whole application life cycle process. Azure DevOps offers an all-in-one solution that integrates project management, source control, continuous integration, and delivery, testing, and deployment. Additionally, it provides native integration with other Azure services, which can simplify the process of building, testing, and deploying applications on Azure. You get one place to manage all its parts and this is extremely convenient.

However, there is another player - AWS DevOps. It’s embedded in AWS and directly connected to your billing account, so to use it, you need to have an AWS account. On the other hand, Azure DevOps is a separate product, and you can manage it separately from your Azure account. This means that you can use Azure DevOps without necessarily using Azure, and vice versa. However, both AWS and Azure DevOps offer similar features and functionalities, such as continuous integration and delivery, testing, and deployment, and they both have native integration with their respective cloud platforms. For example, the hosted runners for Azure DevOps run on Azure, and the code on Azure DevOps repositories is also hosted on Azure.

You can integrate Azure Active Directory with Azure DevOps. But if there is a need to deploy from Azure DevOps to let's say AWS EKS you have to connect to it just like you would to any other Cloud platform in case of multiple platform deployment.


So having in mind the information presented above let's try to answer the question: who is Azure DevOps for?

For the most part, companies which already use the Azure platform or other Microsoft services will lean towards using Azure DevOps as it will be a natural extension to their tool stack. The same situation will be for AWS users who probably will choose AWS DevOps. As for other projects, which already have processes set up for example in open source solutions, moving them all into one integrated service probably won't be profitable. Ultimately, the choice between AWS DevOps and Azure DevOps may depend on factors such as your familiarity with the respective platforms, your team's specific needs, and the cost of each platform.

Blog Comments powered by Disqus.