1. Infrastructure as Code
1.1. This is a concept that has been enabled by cloud computing
1.1.1. It enables us to specify all the infrastructure of a target environment that will host and run our application, and this specification is made in plain text files that we keep in our version control system alongside our application code
1.1.2. It enables provisioning all the compute, storage and connectivity resources on demand, which we can throw away on demand too
1.1.3. It enables moving from the concept of environments to quality gates
1.1.3.1. Environments no longer need to be these expensively pre-provisioned collections of hardware, supporting software, connections, security, etc.
1.1.3.1.1. They can become "quality gates" by virtue of being created on demand and only needing to exist for as long as it takes to complete some appropriate set of QA tests that certify an application's readiness for deployment to the next "quality gate" on it's route to the final Production release
1.1.4. It improves the traceability of changes by virtue of being held in the version control system
1.1.5. It improves repeatability by virtue of the "create, test, tear down" approach, ensuring that testing always occurs in new, clean "environments"
1.1.6. It improves cost efficiency because the "environment" only needs to exist for the duration of your tests, so you only need to pay for the use of that infrastructure within that test window
1.2. Configuration and secrets
1.2.1. Part of infrastructure as code will include sensitive configuration details such as passwords, connections strings or access tokens
1.2.2. We cannot keep these sensitive values in source control
1.2.3. The idea is to have these secrets defined as variables in Azure DevOps
1.2.3.1. These secret variables can only be created or edited in DevOps by authorised security administrators
1.2.3.2. Regular developers can use these variables when developing pipelines but cannot see their values in Azure DevOps
1.2.4. The release process that runs through Azure DevOps will replace variables with the secrets
1.2.4.1. By virtue of being designated secret variables, the values will not be logged or displayed to the agent terminal
1.2.5. There are pitfalls to secret variables in Azure DevOps that you must be aware of and take care to avoid
1.2.5.1. When setting pipeline variables as secrets, you must be careful about who has access to alter your pipeline
1.2.5.1.1. Developers with access to edit pipelines won't be able to read the secret, but they'll be able to change its value
1.2.5.1.2. Putting secrets into variable groups (under Libraries) enables you to separate such variables and the permission to edit them from the pipelines
1.2.5.2. Some operating systems log command line arguments, so never pass secrets on the command line
1.2.5.2.1. Instead, Microsoft suggests that you map your secrets into environment variables
1.3. Provisioning
1.3.1. For Azure cloud resources, we use ARM templates to provision infrastructure
1.3.2. I saw a Pluralsight demo on how to add ARM template deployment to your build and release pipeline, and the key points observed were as follows:
1.3.2.1. Run through deployment wizard in Azure Portal but instead of deploying, click the button to download as ARM template
1.3.2.1.1. This gives you a zip file that contains two essential files: template.json parameters.json
1.3.2.2. Add a "Copy Files" task to your build pipeline for copying your ARM templates to the artifact staging directory
1.3.2.2.1. The path to the artifact staging directory is available via the built in system variable:
1.3.2.2.2. This task needs to occur before the "Publish Artifact" task
1.3.2.3. Add an artifact to your release pipeline that links to the "Publish Artifact" task output of your build pipeline's "Publish Artifact" task
1.3.2.4. Add "ARM Template Deployment" task to your release pipeline and point it to the linked artifacts, which you should be able to browse and point to the ARM template that has been placed there by the build pipeline's "Publish Artifact" task
1.3.2.4.1. Note: you will need to run the build pipeline before the artifact can be browsed and selected in your ARM Template Deployment task
1.3.2.4.2. You will also need to pick the parameters file as part of the ARM Template Deployment task, and there is an option for overriding any of the parameter values
1.4. Test, Validation and Approval
1.4.1. Remember that an "environment" can be replaced by a "quality gate" thanks to infrastructure as code because it allows us to fully automate the provisioning of all resources, testing, de-provisioning, and even the approval
1.4.2. The idea is to have the release pipeline perform the following steps, all of which can be automated
1.4.2.1. 1. Deploy the newly provisioned resource(s)
1.4.2.2. 2. Run various tests
1.4.2.2.1. For testing web applications, Selenium is a popular UI test automation framework
1.4.2.2.2. The tests are coded right into the Visual Studio solution as a second project together with the .NET web application project
1.4.2.2.3. In a Pluralsight demo, I saw the Selenium project added first to the build pipeline via a Copy Files task
1.4.2.3. 3. Report results
1.4.2.4. 4. De-provision resources
1.4.2.5. 5. Wait on approval
1.4.2.5.1. This is quite often implemented as a manual approval by one or more authorised users but it's also possible to automate this by automatically checking the reported results meet some acceptance threshold
1.5. YAML Based Pipelines
1.5.1. Microsoft introduced YAML based pipelines, which allows you to develop Azure Pipelines entirely in code
1.5.2. These YAML pipelines are represented in plain text files that can be placed in your version control system
1.5.3. The YAML pipelines support the development of pipelines that combine build + release
1.5.4. I watched a Pluralsight demo that included creating a Production Environment and then use the "View YAML" option for the two classic build + release pipelines to copy+paste into a new YAML pipeline and tweak it so that the deployment stage (copied from release pipeline) targets the new environment
1.5.4.1. Note: Environments is one of the tabs available under Pipelines in Azure DevOps
1.5.4.2. Once the pipeline is triggered, it runs the build stage followed by the deploy stage, and you can see the output in the Environments page without having to switch to Azure Portal
1.5.4.3. In the demo, the Production Environment in DevOps showed the successful deployment details, including a running Kubernetes cluster and a load balancer running inside a container on that cluster
1.5.4.3.1. The public IP address of the load balancer was shown here and by simply copying and pasting this into a separate browser tab, the deployed web application could be browsed
1.5.5. When editing YAML pipelines in Azure DevOps, you have access to the same tasks that you can add and configure using the graphical UI and then the result appears as a new task tag in the YAML file editor
1.5.5.1. You also get a hot-linked "Settings" for each task tag in the YAML file editor, and when you click this it takes you to the graphical UI for editing that task
2. Security, Approval and Audit Trails
2.1. Release security generally begins in the Project Settings
2.1.1. In Project Settings | Teams, we can create new teams and add individual users to teams
2.1.2. In Project Settings | Permissions we see any teams we created and all the built in groups, and we can add custom groups too if required
2.2. For individual releases, we can set security by selecting the Security option
2.2.1. We can see here the permissions set for a release per group and per user, and we can change these on a per release basis
2.3. When we edit a release pipeline and select a stage, we can also click the 3 dots to access Security options for that stage
2.3.1. Here we have some different, stage-specific permissions, with inherited permissions for various built in groups
2.4. Audit trail for release pipeline changes
2.4.1. When we edit a release pipeline, we can see an audit trail of changes via the History tab
2.4.1.1. For each individual change, we can click the 3 dots and choose Compare Difference
2.4.1.1.1. So not only can we see who changed the pipeline and when but we can see exactly what was changed
2.5. Agent Pool security
2.5.1. In Project Settings | Agent Pools, we can set Security options here too
2.5.1.1. We can assign users or groups to any of the 4 built in roles, which determine whether or not they can read, create, use or administer agent pools
2.5.2. We can also set security on specific agent pools that have been created
2.6. Audit trail of release process for compliance audits
2.6.1. All of the following are logged:
2.6.1.1. Release runs
2.6.1.1.1. Every step in a release is logged
2.6.1.1.2. Every approval is logged
2.6.1.2. Changes to release definition
2.6.1.3. Access to the Azure DevOps services
2.6.2. The four eyes principle is a commonly adopted one for applying to critical business decisions that can make or break a business
2.6.2.1. Approving releases to a Production environment falls into this category!
2.6.2.2. The definition of the four eyes principle is:
2.6.2.2.1. The Four eyes principle is a requirement that two individuals approve some action before it can be taken. The Four eyes principle is sometimes called the two-man rule or the two-person rule.
2.6.2.3. Azure DevOps supports the implementation of the four eyes principle
2.6.2.3.1. For each release pipeline stage, we can set either pre or post conditions as appropriate, such as adding two named approvers as a pre-condition for the Production stage
2.6.3. We can review the history for any given release and see who approved it and when
3. Builds upon the basics of Azure Pipelines and ARM templates
3.1. Azure Pipelines are part of the Azure DevOps service and I have a mind map for this
3.2. ARM templates are the way that Azure resources are represented as Infrastructure as Code, and the primary way for deploying incremental changes as part of CI/CD, and I have a mind map for it
4. Release Management
4.1. Rather than having the old fashioned idea of a single build server that handles both the build and release, the modern way is to split the two processes
4.1.1. The thinking behind this is that a release is often more complicated than the deployment of a single build artifact
4.1.1.1. For example, not just the build and release of a SQL database project, but also a Data Factory instance, a Databricks workspace, a Synapse Analytics workspace, etc.
4.1.2. Allows us to have a single release process that is based on multiple build artifacts that compose an application
4.2. Another idea is the separation of deployment from release
4.2.1. What this means is the idea of developing software in such a way that you can deploy new features continuously but be able to release those features selectively
4.2.1.1. Selective feature release means being able to release a new feature to some segment of users, not all
4.2.1.2. Deployment in itself should not change anything in the target application for any of the users unless that feature is released to those users by means of a feature toggle mechanism
4.2.1.3. Features released to a small segment of users can be monitored for user feedback and general system stability monitoring to validate that the application continues to work reliably as it did before the new features were released
4.2.2. This makes releases more of a business user function - a kind of toggle-based approach where features can be released when the business is ready and satisfied
4.3. Steps of a release
4.3.1. Build software
4.3.1.1. Validate product quality using automated tests
4.3.2. Deploy software
4.3.2.1. Validate runtime stability using telemetry software
4.3.3. Release feature(s)
4.3.3.1. Validate feature usage
4.4. Azure DevOps Pipelines
4.4.1. Makes a distinction between build and release
4.4.2. Azure Pipelines handle builds and produce artifacts
4.4.3. Azure Release Pipelines have triggers tied to Azure Pipeline artifact production, and they deploy these artifacts to an environment
4.5. Release set-up
4.5.1. Release pipeline definition
4.5.1.1. Defines the tasks of a release process
4.5.2. Release agent
4.5.2.1. Software dedicated to executing the release pipeline runs on a machine that may be hosted (by Microsoft in the cloud) or self hosted (by you, on-prem or via a private VM in Azure)
4.5.2.2. The release agents are the same as the build agents in Azure DevOps
4.5.2.2.1. The agent software supports the functionality for both build and release tasks
4.6. Artifacts, stages and gates
4.6.1. A release is a collection of artifacts in your DevOps CI/CD processes
4.6.1.1. An artifact is a deployable component of your application
4.6.1.2. Azure Pipelines can deploy artifacts that are produced by a wide range of artifact sources
4.6.1.2.1. Azure Pipelines are simply one such source, as these are designed for build processes, and Azure Release Pipelines can be tied to these pipelines and triggered by a Publish Artifacts task
4.6.1.2.2. Other CI/CD systems such as Jenkins and TeamCity and produce artifacts that trigger Azure Release Pipelines
4.6.1.2.3. Version control systems can also be used to hold artifacts and trigger on commit
4.6.1.2.4. You can also use repositories such as Azure Artifacts or a NuGet repository to store your artifacts, and updates to the artifacts held in those repositories can trigger Azure Release Pipelines
4.6.1.2.5. For containerized apps, we can use container image repositories for the artifact source
4.6.1.3. A release can be composed of one or more build artifacts
4.6.2. Stages organise the deployment tasks on a journey towards the final ("general availability") Production release for new features
4.6.2.1. Often stages will be thought of as environments, such as Dev, QA, Pre Prod and Prod
4.6.2.2. Stages can also be dedicated to validation
4.6.3. Gates are check points that attach to the stages of a release pipeline
4.6.3.1. Gates go hand in hand with approvers
4.6.3.1.1. Approvers require authorised users to manually approve a designated release stage before the release agent will execute it
4.6.3.1.2. Gates check for conditions that need to be satisfied before a stage is allowed to be executed by the release agent
4.7. Jobs and tasks
4.7.1. An Azure Pipeline consists of one or more jobs
4.7.2. In Azure Release Pipelines, jobs are added to stages
4.7.2.1. Note that Azure Pipelines (which are designed to produced build artifacts) do not have the concept of stages
4.7.3. We can choose from 1 of 3 types of job, depending on whether we are using classic pipelines or YAML pipelines
4.7.3.1. Agent (pool) jobs
4.7.3.1.1. These jobs run on an agent in an agent pool, and they are the most common
4.7.3.2. Server jobs
4.7.3.2.1. a.k.a. "agentless" jobs; run on the Azure DevOps Server
4.7.3.3. Deployment group jobs
4.7.3.3.1. Classic pipelines only; these run on machines in a deployment group
4.7.3.4. Container jobs
4.7.3.4.1. YAML pipelines only; these run in a container on an agent in an agent pool
4.7.4. Once we choose a job type, we are presented with a whole bunch of available built-in tasks for the job type
4.7.4.1. For required tasks that are not built-in, we can browse the Marketplace
4.8. Release variables
4.8.1. We can create custom variables in both Azure Pipelines and Azure Release Pipelines
4.8.2. We can combine custom variables with variable groups, each of which can be associated with a specific environment (e.g. a Dev variable group, a QA variable group, etc.)
4.8.3. In addition to custom variables, we have many built-in variables available
4.8.4. We reference variables using the following syntax:
4.8.4.1. $(variablename)
4.8.5. We can also designate variables as secrets, which prevents their value from being output in any of the agent job logs or interactively to the terminal
4.9. Continuous deployment triggers
4.9.1. Allow you to create a release every time a new build artifact is available
4.9.2. These triggers attach to artifacts in an Azure Release Pipeline
4.9.2.1. This feature is currently (Mar 2021) available only to build from Azure DevOps, TFS and Git-based repositories
4.10. Agents and Pipelines
4.10.1. Every Azure DevOps account includes a free tier that allows you to run 1 Microsoft hosted pipeline job allowed to run for up to a certain number of minutes monthly, and 1 self-hosted pipeline job allowed to run for unlimited minutes
4.10.1.1. At time of writing the limit on a Microsoft host pipeline job is 1800 minutes (30 hours) per month
4.10.2. Microsoft charges for the Azure Pipelines service via the concept of parallel jobs
4.10.2.1. When you define a pipeline, you can define it as a collection of jobs
4.10.2.2. When a pipeline runs, you can run multiple jobs as part of that pipeline
4.10.2.3. Each running job consumes a parallel job that runs on an agent
4.10.2.4. When there aren't enough parallel jobs available for your organization, the jobs are queued up and run one after the other
4.10.2.5. In Azure Pipelines, you can run parallel jobs on Microsoft-hosted infrastructure or your own (self-hosted) infrastructure
4.10.2.6. You purchase parallel jobs via Azure DevOps Organization Settings | Pipelines | Parallel Jobs
4.10.2.6.1. Here you can see that the service is practically free for public projects and you pay for private projects
4.10.2.6.2. This is where you go to purchase more parallel jobs for your private projects
4.10.3. An agent is computing infrastructure with installed agent software that runs one job at a time
4.10.3.1. Jobs can be run directly on the host machine of the agent or in a container
4.10.3.2. There are two types of agent available: Microsoft-hosted agents Self-hosted agents
4.10.3.2.1. If your pipelines are in Azure Pipelines, then you've got a convenient option to run your jobs using a Microsoft-hosted agent
4.10.3.2.2. An agent that you set up and manage on your own to run jobs is a self-hosted agent
4.10.3.3. Agents run both build pipelines and release pipelines
4.11. Hybrid release management
4.11.1. Microsoft-hosted agents have no line of sight access to target on-prem environments, so we must use self-hosted agents to deploy artifacts to on-prem targets
4.12. Deployment groups
4.12.1. Deployment groups are only available with Classic release pipelines
4.12.1.1. Note that YAML pipelines have a different concept known as deployment jobs, which utilise the Environments feature in Azure Pipelines
4.12.1.1.1. Like Deployment Groups are for classic pipelines only, Environments are for YAML pipelines only, and I think (broadly speaking at least) they can be considered to provide an equivalent function in that both are used as a mechanism for seeing deployment outcomes to target environments from within the Azure DevOps UI
4.12.2. A deployment group is a logical set of deployment target machines that have agents installed on each one
4.12.2.1. Think of each deployment group as representing target machines for a particular environment (Dev, QA, Pre Prod, Prod, etc.)
4.12.2.2. Typically, deployment groups are used for on-prem hosting
4.12.2.2.1. You could also install deployment group agents onto Azure hosted VMs if you want
4.12.2.3. The key difference here is that the agent is running on the end target for the artifact deployment and it must run as a system service
4.12.2.3.1. The agent running as a system service means that the agent software has no access to the network
4.12.3. I watched a demo of an on-prem machine getting the deployment group agent installed and then a release pipeline that included two parallel stages: one that ran an Azure deployment using a Microsoft hosted agent and one that ran an on-prem IIS deployment using the deployment group agent