Manage your application’s lifecycle in the cloud with Microsoft Azure DevOps
Background: Application Lifecycle Management (ALM)
Before we start, lets have a quick refresher about Application Lifecycle Management (ALM).
Application lifecycle management is the product lifecycle management of computer programs. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management. [Source wikipedia.]
An ALM tool should have the capability to maintain all the aspects of a software lifecycle, such as capturing the ideas, users requirement, planning of work, maintaining source code, deploying code using continuous integration and continuous delivery (CI/CD). It should also provide real time project insights to the key stake holders of a project. We can think of an ALM software as one stop shop for a software project/product management as a whole.
In this post we will take a look at Microsoft’s Azure DevOps offering, it’s capability as an ALM solution and will see how you can use it for your ALM journey.
Intro: Azure DevOps
In a single sentence, Azure DevOps is a suite of offering in the cloud that you need to build your software product/project from beginning to end.
Azure DevOps, formerly known as Visual Studio Team System (VSTS). It helps you to plan your project, manage source code in repositories like Git, TFVC, Subversion, GitHub and deploys the code through the CI/CD pipeline system to cloud or in on-premise resources. Additionally it gives a collaborative platform for developers, business users and test engineers, project managers under one umbrella to real time tracking of work and quick shipment of the product.
Azure DevOps is a browser based application in public cloud with first class support and integration with numerous opensource languages and platforms.
What makes Azure DevOps a ALM solution?
Azure DevOps is made of off six major pillars which made it a perfect ALM solution in the cloud.
Azure Boards is a place to manage and plan all of your work. All ideas and business requirements for your software can be captured here. You can create epics, features, user stories and then estimate them and plan capacity of your team members and start the sprint. Additionally you can have a real time view of the work item progression in Kanban boards, sprint burn down charts.
Azure Repos supports various source control system like Azure Git, Public GitHub, GitHub Enterprise, Microsoft’s own Team foundation version control (TFVC), External Git. You can choose any one of the repositories for your choice for software development and source code. Once development is done developers can create a pull request with their changes, send it for code review and take part of a collaborative development environment.
Azure Pipelines are used for continuous integration and continuous delivery (CI/CD) of your code. It allows you to ship your code faster. Once your code is developed and committed to the repos, a build gets triggered in the build pipeline. This build pipeline gets the latest code from the repos, builds them in the build agent. On a successful build, the build artifacts gets published using Release pipeline in your targeted deployment environment.
Azure Test Plans is for planning and executing your manual, automated and load test cases. Once the build is succeeded test engineers can run a set of tests on the build for verification and validation of the desired functionality. And they can raise and log any defects or observation on failure of any of the planned test scenarios in the Azure Boards.
Azure Artifacts manages your private NuGet, npm, Maven packages in a private feed. You can integrate this feed in your favourite IDE such as Visual Studio or Visual Studio Code and restore the packages from this feed while development. Additionally you can integrate this feed in the build pipeline and restore packages from this private repository. Azure Artifacts helps a lot where there are a lot of shared common packages in use in the application and you want to control standards, version of those cross cutting atrifacts.
Azure Overview gives real time insights of the project such as teams velocity, CI/CD results, number of defects raised vs solved at any point of time to name a few. Executive dashboards can be created with inbuilt capability of it. These dashboard helps greatly for executive status reporting with risk and quality matrices.
Additionally it supports creating Wiki pages for the project. Wiki pages can be used to create any documents/ manual which are relevant for the ongoing or a completed project.
Azure DevOps in action
After knowing about the six pillars of Azure DevOps lets see how all of these helps in ALM with an example. Refer to the Infographic at the start of this post. This describes how an application’s life cycle flows through all the major blocks of Azure DevOps.
In the beginning of the project or product it starts with an idea or some business requirement and after going through multiple steps it takes shape of a usable product. In this example infographic above
- Step #1 Customer comes with requirement.
- Step #2 Business analysts/ Product owner analyses the requirement and starts documenting them in the Azure Boards. They starts creating Epic, Feature and user stories.
- Step #3 Engineering team then starts estimating the work and plan those user stories for sprint.
- Step #3.1 In parallel test engineers starts for Test planning in Test Plans based on the acceptance criteria of the user stories.
- Step #4 Once sprint kicked in — developers starts picking user stories from the backlogs created at step 2 and starts implementing them.
- Step #5 Once developers are done with the development they creates a pull request and sends for code review. Upon satisfaction of the code reviewer, developer commits the code in the Azure Repos.
- Step #6 A build gets triggered in the Build Pipeline as soon as the code gets committed in the Azure Repos using continuous integration (CI). A CI build gets the latest code form the repos, builds them in the build agents, restores any private packages from the feed setup in the Azure Artifacts. It runs unit tests, generates code coverage result and finally generates the build output for deployment. If any one of the steps configured in the build pipeline fails then whole commit gets rejected and developers gets a build failure notification. Developer fixes the build and commits one more time and CI build triggers automatically.
- Step #7 Build output needs to be moved to the deployment environment. In a Release Pipeline source of the build artifacts is the output of the CI build of previous step 6, destination will be the servers where these artifacts needs to be deployed. In this example it is deploying the artifacts to the Azure Cloud App Services and Azure SQL databases for a TESTING environment (step 7.1). A gate or approval mechanism can be set before the deployment happens, this gives control to the approvers to pick and choose which build to be deploy.
- Step #8 Now that build is deployed in TESTING environment, test engineers starts testing and verifying the build quality. They run a set of manual, automated and load tests as planned during the planning phase (step 3.1) in Azure Test Plans. If they observe any defects then they log then in Azure Boards backlog and creates a new bug/issue/observation. Developer picks these defects once these are planned and fed back to the sprint, fixes the defects and commits to the Azure Repos which eventually triggers CI/CD in Azure Pipelines.
- Step #9 If test engineers are satisfied with the build quality and functionality delivered, then this build gets promoted to the upper environment (step 9.1). In this example it is UAT environment for business users to test.
- Step #10 Business users now gets a new build in UAT environment with all the features planned for the current sprint. Business user starts verifying the build and functionality in UAT environment.
- Step #11 If business users finds any defects then they log them into the Azure Boards backlogs as bug/observation. Development and build cycle continues once these defects are planned and fed back to the sprint.
- Step #12 If business users are satisfied with the functionality and the build quality then the build gets promoted to the PRODUCTION environment (step 12.1). Once this is released to production, end users starts using the system. If any issue occurs in the production then it again gets logged in the Azure Boards backlog as an Incident/ Bug/ Issue.
Like this planning, development and build cycle continues towards shipment of the product. In the whole process key stakeholders of the project keeps an eye on Azure Overview dashboards to identify and mitigate any risks.
Closing words to start a new journey
In this post we have covered six major pillars of the Azure DevOps and discussed about how Azure DevOps can be leveraged to manage your applications life cycle. Now to know more about Azure DevOps you should check the links below
- If you want to know more about the pricing check this out.
- To learn more about Azure DevOps check this video.
Oh.. wait, In the meanwhile, you can get started with your free account in Azure DevOps and start exploring. Just log in to https://dev.azure.com with your Microsoft account and start your ALM journey in the cloud with Azure DevOps.
Originally published at subhankarsarkar.com on September 30, 2018.
