What is Azure DevOps?

Azure DevOps is not only a tool but also a cultural and professional movement. In my opinion, Devops are practices that enable automation, communication and integration between software teams and IT teams.

More details about DevOps: https://devopstipstricks.com/what-is-devops-for-beginners/

Azure DevOps comes up with 5 main modules in this approach. These are; Boads, Repos, Pipelines, Tests and Artifacts. In fact, none of these modules are things we haven’t done before and it is not a new technology, but the added value of Azure DevOps here is that we can manage all project components from a single portal. All development steps, kanban board, code repository, automated CI/CD processes, test steps and nouget packages related to the project can be managed through a single portal.

Azure DevOps Components

Azure Boards consists of 5 main components:

1. Thanks to Azure Boards, we can track all the efforts and steps of our project. We can follow classic Agile, Scrum methods or customize it according to our wishes.
2. Azure Repos: Thanks to Repos, we can keep our team’s knowledge base or our codes in the same environment with our project. If we want, we can host our application in a package with the Git feature or with the VSTS feature.
3. Azure Pipelines: Pipelines is perhaps the most important feature of Azure DevOps. With this module, we can set up our CI/CD processes, set up approval mechanisms or run scripts that run automatically.
4. Azure Tests Plans: Thanks to the test module, we can set up test steps in our application. We can try them from an opened browser, make instant bug detection and create work items based on these bugs.
5. Azure Artifacts: Thanks to the Arfitacs module, we can distribute the dependency packages used by our application. After the application is compiled, the dependencies used by the latest version are packaged and distributed in nouget or other package management languages.

Azure DevOps Lifecycle

If we want to develop a project with Azure DevOps, the life cycle of this project will be as above. To explain this visual

Consultants & Developers: Develops the application or project and pushes it to the Repository
Code Repository: Source codes submitted by developers are versioned and kept in the branch structure. If the development is found appropriate, a pull request is made to the master branch.
Commit-Build: After the application is Pull Request, the Build process is performed and the executable package is made.
Test: Automated tests are performed before the executable package is deployed. If all of these tests are successful, the next step is taken
Deploy to Cloud: Our executable package is uploaded to the production environment with the specified deployment model and our new version goes live.
Monitor and Improve: Production environment is monitored and relevant improvements are made according to business needs.

Although the above life cycle shows the repetitive life cycle of DevOps in a very superficial way, different teams or different units may take part in each stage depending on the environment of each company. Even within the same company, it is often possible to do the same process with different tools and teams. But the only thing that does not change is that each process works in an automated way one after the other and the life cycle is in a systematic way independent of people.

Azure DevOps Example

If we want to set up the Azure DevOps service within the company or individually, it will be enough to log in to dev.azure.com and create a project. One of the most prominent aspects of this service is that all features are free for up to 5 users within the same project and after that, it remains free and offers limited access. The image below shows some of the projects in my devops environment.

We enter our project named WebApp Container and a welcome screen appears. There is general information about our project and a wiki area.

You can also see another module on the left side under Artifacts. You can include extensions from Azure DevOps’ marketplace to your project according to your needs. We will make an example of building a new pipeline. For this, we first publish the code to our repository. If we wanted, we could keep the code not here but in any git distribution.

Now that we have our code in our repository, we first set up the CI pipeline that will run on every code submission. For this, we click the New Pipeline button from the Pipelines module.

It asks us to show us the location of our code. Here, if we choose one of the options above, we are building a pipeline in YAML format, if we say classic editor as in the article below, we can build a more visualized pipeline. My recommendation would be to build in YAML format because the yaml file is committed to the git branch and the pipeline file can be versioned in developers regardless of the environment. We continue by selecting our repository. In the next step, it asks which application type to get a build.

Since there is a dockerfile in our files, Docer is at the top as recommended. The pipeline models we see here are actually a template and we can continue by choosing an empty template. However, if we choose Docker, steps will be automatically added to build the Docker image.

The yaml of our CI pipeline is formed as below.

This pipeline currently consists of several steps and performs Docker build and push to ACR. When we run it, we get an output like below.

In 1 minute and 10 seconds, our pipeline is complete and our new image is pushed to the Container Registry. In this way, every time the developer commits his code to the master, he will get an application with a new version.