Planning Your Azure DevOps Organization

In the previous chapters, you learned about many techniques and practices concerning DevOps. In this chapter, we will take a step back and look at how you can build a strong DevOps organization and what you need to think about when doing so. Next, you will learn what this can bring you with regard to security and traceability. From there on, you will learn how you can consolidate your toolchain, standardizing on Azure DevOps.

We will begin by creating an Azure DevOps organization where you will learn which constructs are available to lay out your products and teams in the tool. You will also learn about licensing and the security implications of the different approaches. Next, you will learn about traceability and how that can be used to create a verifiable software development process. Next up is the consolidation of the tools used. As...

Technical requirements

To follow along with the practical parts of this chapter, one of the following is needed:

• A Microsoft Live account, also called a personal account
• A work or school account

Setting up an Azure DevOps organization

To practice with one or more of the technologies and techniques described in the previous chapters, an Azure DevOps organization might have been created specifically for this use, or maybe one was available already that could be used for this purpose. However, creating an organization for a company from scratch takes a little more consideration. Taking the time to properly plan the layout of the organization can save a lot of time later on.

This section describes the components out of which Azure DevOps is built, how you can use this to organize a fitting security model, and licensing options and costs.

How Azure DevOps is organized

The top-level construct in Azure DevOps is called an...

Ensuring traceability

One of the advantages of Azure DevOps over some of the other tools covered in this book is that it is a fully integrated suite of tools, each supporting specific DevOps processes. This end-to-end integration allows for detailed and lengthy traceability, from work described on the board to the related binaries being deployed to an environment.

When working with a set of other tools that support only a part of the DevOps process, integrating them is often possible and, of course, this will result in some traceability. For example, when working with Jira and GitHub, it is possible to relate commits, pull requests, and other changes in GitHub back to work described in Jira. When picking merged changes up in Jenkins to build and deploy the product, there will also be traceability from Jenkins back to GitHub. However, there will be no direct visibility on which...

Consolidating tools

One trend that can be observed in the market is that of traceability and DevOps products that extend their offerings to include more than only source control, only pipelines, or just deployments. Examples are GitHub and GitLab, which are adding new services. More integrated Application Lifecycle Management (ALM) or DevOps suites emerge, while Azure DevOps has been offering this for years now.

However, there are many companies where these integrated suites are not in place. Teams operate in different ecosystems, leading to different tool choices. Or maybe teams just have different preferences or started adopting DevOps practices at different points in time, with other tools to choose from. No matter the reason, there are many companies that have several tools running for the same job.

Unfortunately, several drawbacks are associated with having disconnected...

Accepting there is no end state

It is fair to expect that, at any point in time, there will be one or more improvements that teams want to make to their applications, toolchain, or way of working. To cope with this, it is recommended to not keep changing everything all of the time.

Instead, try to implement changes in batches or a series of well-defined steps. Also, note there is a natural order in things. It is impossible to practice continuous deployment without having a proper continuous integration process first. Also, adopting infrastructure as code will deliver the most value when a continuous deployment process for application code is already in place. Next, automating governance and security measures works best when infrastructure and configuration code is common practice. And once all of these practices have been implemented, new things will come up on the radar—...

Summary

In this chapter, you learned how to configure your Azure DevOps organization and how to create a layout for your products and teams. You learned what the implications are regarding the different configuration options and how to apply those. Next, you learned how you can use Azure DevOps to add traceability to your development process. You learned how to capture ideas and tasks in stories and tasks and how these can be traced all of the way to a deployment and the other way around. The next thing you learned about is how to approach the consolidation of tools used within your organization and when to stop trying to consolidate tools. Finally, you learned that it is important to continuously keep improving.

With the things you learned in this chapter, you are now capable of setting up and configuring Azure DevOps for your team, teams, or organization. You can create a structure...

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. True or False: All data stored in Azure DevOps by users is guaranteed to be contained within one region.
2. Reorder the following Azure DevOps concepts in such a way that each next element acts as a container for the next concept in the list:
   • Work item
   • Organization
   • Region
   • Project
3. True or False: The general recommendation is to create a new project for every application that is developed by your organization.
4. Which two elements limit the actions any user can perform within Azure DevOps?
5. What is the main benefit of using a single tool for application life cycle management/DevOps as opposed to a suite of tools?

Further reading

• More information on Azure DevOps projects and when to create more than one project can be found at https://docs.microsoft.com/en-us/azure/devops/organizations/projects/about-projects?view=azure-devops#when-to-add-another-project.
• More information about the Azure DevOps security model can be found at https://docs.microsoft.com/en-us/azure/devops/organizations/security.
• Up-to-date information on Azure DevOps pricing can be found at https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/.
• More information about the Azure DevOps Server-import service can be found at https://docs.microsoft.com/en-us/azure/devops/migrate/migration-overview?view=azure-devops&viewFallbackFrom=vsts.