I have a dream of ONE instrumented pipeline, with ONE build, and MANY deployments for every application. The question I have is how to grant stakeholders access to the pipeline stages and release variables, using  Azure DevOps pipelines.

Goal

We SHIFT LEFT by running builds, unit tests, and scan for vulnerabilities, using a service such as WhiteSource. We want to detect issues and fail early!

We SHIFT RIGHT by using tokenisation, XML transformation, and configuration to deploy environments, quality gates to guard environments, consistent versioning, automated release notes generation, and telemetry observation. We want everyone to have the complete context!

Progressive exposure, using deployment rings and feature flags, allows us to get feedback new features in production, with control over the blast radius. LaunchDarkly is a great Software as a Service solution when looking for feature flag management.

Having ONE pipeline, with ONE build, and flexible deployments, creates consistent, effective, and maintainable pipelines.

PROCESS and PRODUCTS enable PEOPLE!

DevOps is 80% about PEOPLE and TRUST, or the lack thereof

Pipeline

We start by creating a release pipeline with a number of predefined stages, for example development, system test or Q&A, security validation, staging, and production.

An Azure Pipeline creates a new release automatically when it detects new artifacts, generated by continuous integration builds, are available. We can use scheduled, continuous release, and pull request triggers to automate our pipeline. For simplicity, let us assume that DEV and OPS trust each other, allowing us to grant everyone access to everything. Simple!

Using artifact filters, we can allow builds from all branches, including pre-merge validation builds, to be deployed to the development environment. Artifacts from the master trunk and release branches  are allowed to proceed to the System Test, or QA environment, whereas only builds originating from Release folder branches will be allowed to proceed to production. Simple, effective, and continuous!

But, what if there is no trust?

If there is a lack of trust between development and operations, or a mandate to secure environment stages to predefined groups of users, we return to the question that sparked this blog post. How do we secure each pipeline stage and release variables?

We can fine tune access to each pipeline stage. For example grant developers full administrative access to the development stage, and lock down the rest to operations. However, release variables are slighlty more challenging.

Variable Groups

Variable group allows us to store and control values across multiple pipelines. Unlike Release variables, they also have a Security feature, that allows us to fine tune the access to the variable groups and contained variables.

Azure Key Vault

Azure Key Vault allows us to safeguard and manage cryptographic keys, secrets, and other variables. Unlike Release Variables and Variables Groups, secrets can be viewed if you have access, and we can review changes to key values. We can, for example, create an Azure Key Vault per stage environment and lock each vault down as required. Using the Azure Key Vault task, we can fetch the latest values of all or a subset of  secrets from the vault, and set them as hidden variables that can be used in  subsequent tasks of a pipeline.

Community's View

My personal choice is the Azure Key Vault. It is secure, allows us to trace, and restore key values.  

Based on a recent twitter poll, 27% are using out-of-the-box release variables, which shows a positive growth in trust. The majority, 39%, are using the Key Vault to secure release variables.

?

  • What do you think?
  • Do you support the goal of one pipeline, per application?
  • How do you secure your release variables?