Azure DevOps contains several services that help in the operations of software development. Teams can plan, define, and track their work in Azure Boards. Using Azure Repos, teams can share, collaborate, and track changes to project files. When it comes to automating work, Azure Pipelines allows for building/compilation of code, running tests, or other tasks. Azure Test Plans provides a hub for QA engineers and testers to create test plans, view their progress executing the test plan, view the results, and design, run load tests. Azure Artifacts allows teams to create packages of their code or other files and host it within a feed that other teams or projects can download from. Billing for Azure DevOps is done per user access level with multiple access levels starting from Stakeholder, or free, to Visual Studio Enterprise subscribers.
Setup
Setting up Azure Devops for the first time will require the creation of an organization and a project. An organization can contain many projects but once a project is created it cannot be transferred to another organization so it is important to think about how the organization(s) and projects should be created. It would be wise to discuss with other members of the team, and other teams, to go over scenarios for the best setup for the team(s) and maybe the whole company. Once everything is setup a user will have some leeway in making changes to the organization name and owner as well as changes to the project within their respective settings. There are multiple settings for organizations and projects that have to do with user access, billing, security, pipeline settings such as agents and their pools or groups, etc.
Overview
When a user views a project, that user will be directed to the project’s Summary page within the Overview section which will display info about the project, a readme from a Readme.md file if it exists, the project stats, and the members. There are also a Dashboards page that any user within the team can create, share, and can display multiple widgets containing specific information about the project. The Overview section is rounded out with a Wiki page where the team can store information about the project.
Boards
A project is going to require planning, designing, and a way to track work which can be accomplished in Azure Boards. The Work Items page allows for the creation of work times of multiple types that will fit many different methodologies throughout a project’s lifecycle. Once a work item is created, the user can view it on the Boards page where the work item will be present within the assigned state’s swim lane. On the Boards page, the user can drag the work item to a different swim lane to change its state thus making it a nice place for the team to work. Prioritizing work items can be accomplished from the Backlogs page where work items can also be assigned to sprints. The Sprints page allow a user to plan what work items need to be completed within an iteration or sprint that can last over any time range dictated by the team. If a user needs to view specific work items or find a specific work item, they can use queries to find them. Analytics can be viewed from the Boards, Backlogs, and Sprints pages.
Repos
Part of the project creation will result in the creation of a repository for version control. If files exist in the repository you can view them on the files page otherwise you can clone the repository and begin committing files. Once there are commits a user can view them from the Commits page this helps with viewing the history of changes where a commit can be clicked to view the changes within it. Since a user can create multiple commits before pushing them there is a Pushes page where a user can view the pushes and their grouping of commits. There is also a Branches page that will display all the branches within the repository as well as status of that branch if a pipeline is setup for it and any pull requests for that branch. A Tags page displays all tags within the repository where a user can quickly view the files that belong to that tag. Finally, there is the Pull requests page which can be very helpful during the code review process as a user can create a pull request that, upon a successful review, can result in a branch merge.
Pipelines
The Pipelines page allows the creation of pipelines where multiple tasks can be completed on an agent usually resulting in a package or artifact. Within the pipeline, a user can checkout code from a repository, compile it, run tests against it, package it, save the package to a location as an artifact, or any number of tasks that they would like automated. The Environments page allows the setup of multiple resources, either virtual machines or Kubernetes, to be used by pipelines. The Releases page allows the user to create a release pipeline that is dependent on an artifact. A release is made up of stages that can have pre- and post-deployment conditions and are made up of multiple tasks such as building, testing, packaging, deployment, and a multitude of other tasks. In the Library page, variable groups can be created and secure files uploaded that can be used within a user’s pipelines or releases. Variable groups can be useful when a pipeline or release requires configurations to be changed and provide a way to secure those configurations. The Task groups pages allows a user to reuse a list of tasks from a pipeline or release. A logical set of deployment targets can be grouped within the Deployment groups page for use by the classic release pipelines.
Test Plans
It’s always a good idea to consider if a test plan is required for a project and, if so, what kind of test cases would be needed in order to verify the project. Azure Test Plans allows a user to create a test plan and write up the test cases that make it up. When a test plan is created the test cases can then be assigned to users who can complete the test case, the progress of which can be viewed within a progress report. These test cases can also cause the creation of work items in Azure Boards that will allow the person fixing the issue in the work item to view the test case that caught the failure. Azure Test Plans also will store any test runs that were completed within the Azure Pipelines for later review.
Artifacts
If a team wants to package their project, or a portion thereof, to share with other teams or projects then Azure Artifacts provides a way of doing so. Azure Artifacts allows a team to create and share NuGet, Maven, npm, and Python (pip and twine) packages on a feed. A feed can be scoped to an individual project following the visibility of the project or the entire organization where it will always be private. When it comes to controlling access to functionality, feeds have four levels of access with varying permissions that can be assigned to users.
Billing
Billing for Azure DevOps is done via access levels per user with Stakeholders being the free access level and is limited in functionality. The Basic access level will give more access to functionality and an organization’s first 5 Basic users are free. Basic + Test Plan requires a monthly cost and gives the same access as Basic but with Test Plans. Users that are Visual Studio subscribers will incur no additional charges and not count as Basic users though will receive the same access. A Visual Studio Enterprise or Visual Studio Test Professional subscription is required for Test Plans at no additional cost. Keep in mind these might have changed since the writing of this article.