After our last article on Microsoft Azure DevOps focused on refinement of requirements, sprint execution and collaboration, we now focus on continuous delivery of newly developed increments and testing. In this context we will also discuss the concept of continuous integration and continuous delivery.
Continuous Integration describes a development practice that requires that the developed code is stored regularly (e.g. daily) in a common repository - the relevant module in Azure DevOps is called Repos. A repository and version control system can ensure that several developers can check in code, build artifacts via a build pipeline (Build) and test them automatically. These are usually automated unit and integration tests.
In our scenario, there is a DEV Branch for the current state of development and Feature Branches that are used by 1-n developers to work on a specific feature. For each push request into this branch (a developer checks in the code changes to the feature from his local development environment into the feature branch), a code review can be inserted as a step or automatic unit and integration tests can be defined. In this way, possible errors can be detected early on and corrected directly, even before a coherent feature is rolled out for manual testing in a test environment.
Continuous Delivery describes a method of ensuring that software is in a publishable state throughout its life cycle. Thus, you always have a fast and automated feedback regarding the production readiness of a system. This not only reduces costs, but also time and risk when delivering incremental changes.
But how does Azure DevOps support these methods? In Azure DevOps there is the module Pipelines. With the help of this module, a precise environment scenario can be set up and defined - in our project example we have set up the QA, UAT and PROD environments. If the previously created build in the DEV Branch (from the Feature Branches) was successful, a pull request can be made to the Master Branch, creating a build that can be rolled out to our environments within a release (see left below):
After the build was bug-free, it can be automatically released on any environment. Intermediate gates can also be built in, e.g. for automated or manual validation before deploying to the next environment. The steps within a deployment can be easily configured and parameterized in Azure DevOps:
The deployment status can then be displayed in a release overview:
In summary, the goal of smaller and more frequent releases and their consistency and speed is achieved through a high degree of automation.
After a new version has been deployed on the QA environment, the new functionalities are tested. Up to now, only an automated unit and integration test was carried out within the build, which ensured the technical correctness of a unit or the integration of modules with each other. In the context of DevOps this is also called continuous testing, which provides for the process of executing automated tests as part of the deployment pipeline.
In addition to automated tests, manual testing of the new functions and features is often necessary. This is the case, for example, when the automation of test cases causes high costs. In these cases a structured test management is helpful. Test management is an accompanying measure that covers the entire test process. It includes planning, monitoring and controlling the activities of all test steps. Keeping an overview of all activities, data and status is the art of good test management. For this reason, test management is ideally always tool-supported in practice, as this is the only way to ensure that there is a complete flow of information between all project participants.
In general, testing follows the following steps:
The status progression of a bug from identification to resolution can be mapped in Azure DevOps as follows:
Of course, Azure DevOps also offers the possibility tracking the progress in the course of test planning and execution. For this purpose, the dashboards already presented in a previous article can be used again.
With the Test Plans module, Azure DevOps supports all phases of test management. Tests are divided into so-called test suites, test cases and test steps.
Test Suites are designed to group test cases into separate test scenarios to easily identify which test scenarios have already been successfully run. Test Cases are used to validate individual parts of the app/function deployment for correct execution, correctness and business requirements. To check this, the test steps within a test case are executed and marked as either successful or faulty (bug). The error is explained accordingly so that it can be traced by a developer afterwards.
Azure DevOps is a mature tool that supports modern practices of continuous integration and delivery (CI/CD) of delivery items. Complemented by test management, Azure DevOps offers many helpful features for quality assurance and test case management as well as tracking bugs and bug fixes.
In our next article we will take a closer look at the topic blocks Sprint Review and Retrospective and how Azure DevOps offers an integrated solution here as well.
