YAML and Kubernetes are becoming more important for Microsoft’s online collaborative development tool.
Now that Microsoft owns GitHub, developers often ask if that means the end of the Azure DevOps service which shares a number of features with it: Azure Pipelines and GitHub Actions both let developers manage builds and deployments.
Azure DevOps and GitHub
At Build this year, Microsoft confirmed again that Azure DevOps isn’t going away: because not all code is in GitHub, because Azure needs to have built-in devops tools (which Microsoft itself makes extensive use of internally) and because despite numerous overlaps, they’re actually quite different.
GitHub doesn’t have an equivalent to Azure Boards’ full work item tracking, for example. And while Azure Pipelines is a fully-fledged end-to-end CI/CD pipeline management service with manual and automated approvals and release gates, GitHub Actions is a workflow automation engine that can use almost any event in your GitHub repo to trigger a workflow or a set of tasks, not just a CI/CD trigger. GitHub Actions can also take advantage of GitHub features like CodeQL rules and secret checking. That means the two services are complementary rather than competitive and it often makes sense to use them together. Today you can already mirror code to move it from Azure DevOps into GitHub to take advantage of GitHub’s security scanning or to use GitHub Actions. There are to extensions to make it easier to use GitHub Actions for Azure to build, test, package, release or deploy to various Azure services from Visual Studio Code, the Azure CLI or the Azure Portal.
Both GitHub and Microsoft are working on more integrations: in the future work accounts will allow developers to log into GitHub using Azure AD rather than GitHub accounts, taking advantage of AD security groups, roles and permissions.
With a strong set of features in a mature product, Azure DevOps is getting constant incremental improvements like being able to share service connections between projects or adding attachments like images and GIFs to pull requests, rather than the big announcements we’re seeing for GitHub Action. There’s an increasing focus on making the Azure DevOps visual interface easier to use on mobile devices, even removing some interface options that didn’t work well on mobile. That includes the new UI for multi-stage pipelines in the portal, which is now out of preview and includes several built-in deployment strategies (rolling, canary and blue-green) that you can pick from a dropdown menu.
Yet more YAML
Kubernetes and YAML support has been improving, for teams that want to keep more configuration in code rather than only using the portal. YAML CI/CD features are now GA in Azure Pipelines (you can set a pipeline to do CI, CD or both, using a YAML file), along with multi-stage pipelines, approval gates and resource checks – including making sure a pipeline uses the required template for compliance. Those templates can come from different repos and deployed as necessary.
The YAML support adds doesn’t yet fully match the portal features although parity is planned for the future.
So far the focus is on how you control and secure environments and resources using YAML. Release pipelines are still configured through the visual UI, for example. Microsoft is also working on a migration tool (expected to be available in Q4) for converting build pipelines to YAML (at the moment you can get snippets of YAML for tasks configured in the visual editor, but not the whole configuration).
Currently, you can checkout source code from multiple repos in a YAML pipeline but not cause a pipeline to be automatically triggered when any one of those repos is updated. That’s planned for this quarter, so you will be able to keep YAML pipelines in a separate repo from code, or have a single pipeline to handle multiple microservices, each of which is stored in their own repo.
Monitoring and auditing
Compliance and monitoring gets a boost in several other ways too. Whether you’re using Kubernetes or VMs to deploy, the portal’s resource view lets you track deployments and look back from an application or a Kubernetes object to the pipeline that deployed it and the code commit behind the deployment.
You can also send audit events like resources being deleted, permissions getting changed and branch policy being updated to tools like Azure Sentinel or Splunk, so the security team can monitor changes that might be malicious. Audit streaming is currently in public preview and will be much more convenient than exporting a CSV of events (which are only available on Azure DevOps for the past 90 says).
The audit log will also soon include sign-in attempts and whether developers signed in using a hardware access token, OAuth or other secure method (and when those credentials are created and revoked). That’s important for tracking attacks on your software development process and making sure your software supply chain hasn’t been breached.
Reducing service access is another security improvement. Azure Pipelines can already scope access down to just the repos required for a YAML-based pipeline (so that if the access token leaks it’s doesn’t give access to all your other Azure Repos). And now non-workspace volume mounts of containers in pipelines are becoming read only.
Coming soon to preview
One much-requested feature will be available in preview soon: elastic self-hosted agent pools. When devops teams don’t want to use Microsoft-hosted agents because they want more control over tool specification and lifecycle, capacity or speed, they have to manage the VMs or app services they host themselves, and the infrastructure they’re hosted on, and it’s not always easy to scale up and down as needed. Elastic self-hosted pools run on a VM scale set in your Azure subscription, to your specification, but Azure Pipelines manages the agents for you, injecting the Azure Pipeline agent and increasing or decreasing the VM capacity automatically as required.
In the preview, you can’t run UI tests with elastic self-hosted agent pools, but support for that is planned.
And in Q3 this year, you’ll be able to host those elastic pools on Kubernetes clusters as well. Further down the line, this may also support infrastructure hosted elsewhere (AKS is an obvious option but Azure Stack and other clouds are also possible).
Many recent features from the cloud service will be coming to Azure DevOps Server 2020: we’re now expecting that in late summer or early autumn.
Talk to Grey Matter’s team, Microsoft licensing experts and a GitHub partner, about Azure DevOps to kick start your project: firstname.lastname@example.org.