Run Azure DevOps on premises

It shouldn’t be a surprise that there’s a lot of Azure you can run on premises, thanks to platforms like Azure Stack. But there’s more to on-premises Azure than the familiar platforms and services. There’s also a whole developer infrastructure that plugs into our day-to-day development environments, integrating with Visual Studio to give you the same continuous integration/continuous delivery (CI/CD) environment as cloud platforms like GitHub.

Azure DevOps Server is the replacement for Team Foundation Server, rebranding the on-premises tool and adding on-premises versions of many of the features in the cloud-hosted Azure DevOps Services. If you’re running TFS 2015 or later, you can upgrade, which may be a good option as TFS 2015 is no longer supported and will not get security updates.

A release candidate is now available. If you’ve used earlier versions, there’s one obvious change to the branding: The name no longer includes the year. This aligns it with the cloud Azure DevOps continuous delivery model, dropping the fixed life cycle and adopting what Microsoft calls its “modern life-cycle policy.” This requires you to stay up to date to get support, and there will be no more major named releases.

Requirements for Azure DevOps Server

If you need to keep your code on premises, say, you’re working in a regulated industry or you have privacy and security concerns, it provides the same core services as the cloud-hosted Azure DevOps Services, but instead of Microsoft’s infrastructure, you provide your own servers and storage.

There are two options for on-premises Azure DevOps Server instances, which support two quite different types of organization: a single server install and a multiple-server cluster. The first is best for small projects or independent developers; the second is for larger teams or where you want a single, reliable repository for an organization. Microsoft recommends at least 8 cores, 16GB of RAM, and SSD storage for a single server deployment. Adding Elastic Search requires a second CPU and an additional 8GB of RAM. The more RAM, the larger the organization you can support. A 16GB system will work for up to 250 users, 24GB for 500.

Behind the Azure DevOps Server is SQL Server database. You can start with the Express edition for independent and small team operations, scaling up to Standard or Enterprise versions for larger teams. The minimum supported version for the latest release is SQL Server 2019.

Multiple-server deployments start by splitting storage and the Azure DevOps Server into separate servers, with the possibility of using clustered storage to improve reliability. Other servers can be added to support code search and to run builds. The latest releases require a minimum operating system of Windows Server 2022. If you’re setting up a multiple-server Azure DevOps Server environment, be sure to have your database in place with access for the server.

Working with Azure DevOps Server

Installation is wizard-driven, much like any current Windows Server application, with a Configuration Center application that walks you through the process of setting up the tool and necessary dependencies. Each step has tests that make sure services are correctly configured and ready.

It also helps you manage configurations before installation is complete; once everything is in place and running, you can use the built-in Administration Console to handle further setup. You have the choice of setting up Basic, Advanced, or Azure. The Azure option is for using your own Azure DevOps Server in a virtual machine, connecting to Azure SQL storage.

Once installed, you can start to define the users, groups, and roles in your Azure DevOps organization. If you use Active Directory, it’s a good idea to create new Azure DevOps-specific groups and service accounts and then add users. Keeping development groups separate from other organizational functions gives you more control and avoids the complexity of having more than one service needing the same role-based access controls.

Microsoft recommends having three groups outside of server administrators: one for most users, with access to all projects; another for project managers and architects who can manage projects; and one with restricted permissions that can lock access, for contractors and staff who only need access to limited group projects.

Projects and pipelines

Projects are at the heart of Azure DevOps Server’s workflow. They’re where project administrators detail the scope of the project, and they give you a hub for collaboration around code, much like GitHub or similar social coding platforms. While the look-and-feel is very much Azure DevOps’ own, owing much of its design language to the familiar Azure Portal, the core collaboration methodology is very much like GitHub’s, with a set of Kanban-like boards to manage work tasks plus a code repository. The server also runs CI/CD pipelines, calling a locally hosted instance of the Azure Pipelines runner.

Once triggered, a pipeline behaves as a staged series of jobs. You can have multiple stages in a pipeline, for example, building code, then running tests, and finally deploying it. Each stage has multiple jobs, which are handed over to external applications, for example, using Microsoft’s build tools to compile Windows code. The pipeline collates the job results, checking to see if they have succeeded or failed before either aborting the run or starting the next stage. Jobs can be run in sequence or in parallel, so if you’re building a cross-platform application, it can run Windows, macOS, and Linux builds in parallel.

Building YAML pipelines

Pipelines are defined using YAML and can be managed using the same repository as the code they build. The new YAML pipeline editor replaces the original visual designer. Microsoft hasn’t yet deprecated this Classic Pipeline’s tool, but the writing is clearly on the wall, and the newer YAML editor is now recommended. Tools are provided to migrate existing Classic build pipelines to YAML; there’s no support for migrating release pipelines, so you’ll have to do this manually.

Azure DevOps Server provides its own browser-based editor to help build YAML pipelines, based on the same engine as Visual Studio Code. This has the necessary IntelliSense for code completion, as well as a task assistant that adds building blocks and code for specific tasks, such as calling out to the.NET CLI. You can quickly add commands in the task assistant edit box, and when ready, they are formatted in YAML and added to your pipeline.

The editor also includes tools to validate your YAML before it’s deployed. You can also download the YAML and edit it locally. Variables can manage secrets and other common data, using Azure DevOps rather than a public repository. The switch to YAML allows you to use templates to share common actions between pipelines, with an editor that lets you edit existing templates. If you need a new one, it needs to be created outside the built-in editor.

Pipelines can be cloned, so that one that works for a development build can be copied and used as the basis for a production build pipeline or another similar project. This process only brings across the core YAML code. For security reasons, variables and secrets aren’t transferred and need to be recreated for the new pipeline.

In-cloud and on-premises

By offering much the same feature set as its cloud alternative, Azure DevOps Server lets you bring cloud-hosted CI/CD into your data center with minimal disruption, and Microsoft’s new update model should keep the two variants close to in sync. Although running your own instance does mean more work than simply enabling a new Azure service, there’s still enough automation to allow project managers and development leads to manage and run repositories and pipelines without requiring administrative intervention.

The capability to have both source control and CI/CD pipelines on premises is important as it ensures you’re not reliant on outside resources for your application builds. This approach is essential for regulated industries; there are good reasons to keep as much of the build process inside your firewall as possible, as your software is as much the heart of your business as your staff.