Bloque2 - Az 400t00a Enu Trainerhandbook PDF Free

MCT USE ONLY.
STUDENT USE PROHIBITED 200 Module 6 Managing Application Config and Secrets
ties. The OWASP organization (Open Web Application Security Project) lists injections in their OWASP Top
10 2017 document as the number one threat to web application security.
In this tutorial we'll simulation sql injection attack…
Getting Started
●● Use the SQL Injection ARM template here1 to provision a web app and a sql database with known
sql injection vulnerability
●● Ensure you can browse to the ‘Contoso Clinic’ web app provisioned in your sql injection resource
group
How it works
1. Navigate to the Patients view and in the search box type "'" and hit enter. You'll see an error page
with SQL exception indicating that the search box is feeding the text into a SQL statement
The helpful error message is enough to guess that the text in the search box is being appended into the
sql statement.
2. Next try passing SQL statement 'AND FirstName = 'Kim'-- in the search box. You'll see that the
results in the list below are filtered down to only show the entry with firstname Kim
1 https://azure.microsoft.com/en-us/resources/templates/101-sql-injection-attack-prevention/
MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Security 201
3. You can try to order the list by SSN by using this statement in the search box 'order by SSN--
4. Now for the finale run this drop statement to drop the table that holds the information being dis-
played in this page… 'AND 1=1; Drop Table Patients --. Once the operation is complete, try
and load the page. You'll see that the view errors out with an exception indicating that the dbo.
patients table cannot be found
There's more
The Azure security centre team has other playbooks2 you can look at to learn how vulnerabilities are
exploited to trigger a virus attack and a DDoS attack.
2 https://azure.microsoft.com/en-gb/blog/enhance-your-devsecops-practices-with-azure-security-center-s-newest-playbooks/
MCT USE ONLY. STUDENT USE PROHIBITED 202 Module 6 Managing Application Config and Secrets
Implement Secure and Compliant Develop-

ment Process
Threat Modeling
Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engi-
neering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures
that could affect your application. You can use threat modeling to shape your application's design, meet
your company's security objectives, and reduce risk. The tool with non-security experts in mind, making
threat modeling easier for all developers by providing clear guidance on creating and analyzing threat
models.
There are five major threat modeling steps:

●● Defining security requirements.
●● Creating an application diagram.
●● Identifying threats.
●● Mitigating threats.
●● Validating that threats have been mitigated.
Threat modeling should be part of your routine development lifecycle, enabling you to progressively
refine your threat model and further reduce risk.
Microsoft Threat Modeling Tool

The Microsoft Threat Modeling Tool makes threat modeling easier for all developers through a standard
notation for visualizing system components, data flows, and security boundaries. It also helps threat
modelers identify classes of threats they should consider based on the structure of their software design.
The tool has been designed with non-security experts in mind, making threat modeling easier for all
developers by providing clear guidance on creating and analyzing threat models.
The Threat Modeling Tool enables any developer or software architect to:
●● Communicate about the security design of their systems.
●● Analyze those designs for potential security issues using a proven methodology.
Implement Secure and Compliant Development Process 203
●● Suggest and manage mitigations for security issues.

For more information, you can see:
●● Threat Modeling Tool feature overview3
●● Microsoft Threat Modeling Tool4
Demonstration Threat Modeling

Security cannot be a separate department in a silo. Security has to be part of DevOps, together they are
called DevSecOps. The biggest weakness is not knowing the weakness in your solution. To re-mediate
this, Microsoft has created a threat modelling tool, that helps you understand potential security vulnera-
bilities in your solution.
The Threat Modelling Tool is a core element of the Microsoft Security Development Life cycle (SDL). It
allows software architects to identify and mitigate potential security issues early, when they are relatively
easy and cost-effective to resolve. As a result, it greatly reduces the total cost of development. The tool
has been designed with non-security experts in mind, making threat modelling easier for all developers
by providing clear guidance on creating and analysing threat models.
The tool enables anyone to:
●● Communicate about the security design of their systems
●● Analyse those designs for potential security issues using a proven methodology
●● Suggest and manage mitigation's for security issues
In this tutorial, we'll see how easy is it to use Threat Modelling tool to see potential vulnerabilities in your
infrastructure solution that one should be thinking about when provisioning and deploying the Azure
resources and the application solution into the solution…
Getting Started
●● Download and install the Threat Modelling tool5
How to do it
1. Launch the Microsoft Threat Modelling Tool and choose the option to Create a Model…
3 https://docs.microsoft.com/en-us/azure/security/azure-security-threat-modeling-tool-feature-overview
4 https://blogs.msdn.microsoft.com/secdevblog/2018/09/12/microsoft-threat-modeling-tool-ga-release/
5 https://aka.ms/threatmodelingtool
2. From the right panel search and add Azure App Service Web App, Azure SQL Database, link
them up to show a request and response flow as demonstrated below…
3. From the toolbar menu select View -> Analysis view, the analysis view will show you a full list of
threats categorised by severity.
4. To generate a full report of the threats, from the toolbar menu select Reports -> Create full report,
select a location to save the report.
A full report is generated with details of the threat along with the SLDC phase it applies to as well as
possible mitigation and links to more details…
There's more
You can find a full list of threats used in the threat modelling tool here6
Key Validation Points

Continuous security validation should be added at each step from development through production to
help ensure the application is always secure. The goal of this approach is to switch the conversation with
the security team from approving each release to approving the CI/CD process and having the ability to
monitor and audit the process at any time. When building greenfield applications, the diagram below
highlights the key validation points in the CI/CD pipeline. Depending on your platform and where your
application is at in its lifecycle, you may need to consider implementing the tools gradually. Especially if
your product is mature and you haven't previously run any security validation against your site or appli-
cation.
6 https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
IDE / Pull Request

Validation in the CI/CD begins before the developer commits his or her code. Static code analysis tools in
the IDE provide the first line of defense to help ensure that security vulnerabilities are not introduced into
the CI/CD process. The process for committing code into a central repository should have controls to
help prevent security vulnerabilities from being introduced. Using Git source control in Azure DevOps
with branch policies provides a gated commit experience that can provide this validation. By enabling
branch policies on the shared branch, a pull request is required to initiate the merge process and ensure
that all defined controls are being executed. The pull request should require a code review, which is the
one manual but important check for identifying new issues being introduced into your code. Along with
this manual check, commits should be linked to work items for auditing why the code change was made
and require a continuous integration (CI) build process to succeed before the push can be completed.
CI (Continuous Integration)
The CI build should be executed as part of the pull request (PR-CI) process and once the merge is
complete. Typically, the primary difference between the two runs is that the PR-CI process doesn't need
to do any of the packaging/staging that is done in the CI build. These CI builds should run static code
analysis tests to ensure that the code is following all rules for both maintenance and security. Several
tools can be used for this, such as one of the following:
●● SonarQube
●● Visual Studio Code Analysis and the Roslyn Security Analyzers
●● Checkmarx - A Static Application Security Testing (SAST) tool
●● BinSkim - A binary static analysis tool that provides security and correctness results for Windows
portable executables
●● and many more
Many of the tools seamlessly integrate into the Azure Pipelines build process. Visit the Visual Studio
Marketplace for more information on the integration capabilities of these tools.
In addition to code quality being verified with the CI build, two other tedious or ignored validations are
scanning 3rd party packages for vulnerabilities and OSS license usage. Often when we ask about 3rd
party package vulnerabilities and the licenses, the response is fear or uncertainty. Those organizations
that are trying to manage 3rd party packages vulnerabilities and/or OSS licenses, explain that their
process for doing so is tedious and manual. Fortunately, there are a couple of tools by WhiteSource
Software that can make this identification process almost instantaneous. The tool runs through each build
and reports all of the vulnerabilities and the licenses of the 3rd party packages. WhiteSource Bolt is a new
option, which includes a 6-month license with your Visual Studio Subscription. Bolt provides a report of
these items but doesn't include the advanced management and alerting capabilities that the full product
offers. With new vulnerabilities being regularly discovered, your build reports could change even though
your code doesn't. Checkmarx includes a similar WhiteSource Bolt integration so there could be some
overlap between the two tools. See Manage your open source usage and security as reported by your
CI/CD pipeline7 for more information about WhiteSource and the Azure Pipelines integration.
Infrastructure Vulnerabilities
In addition to validating the application, the infrastructure should also be validated to check for any
vulnerabilities. When using the public cloud such as Azure, deploying the application and shared infra-
structure is easy, so it is important to validate that everything has been done securely. Azure includes
many tools to help report and prevent these vulnerabilities including Security Center and Azure Policies.
Also, we have set up a scanner that can ensure any public endpoints and ports have been whitelisted or
else it will raise an infrastructure issue. This is run as part of the Network pipeline to provide immediate
verification, but it also needs to be executed each night to ensure that there aren't any resources publicly
exposed that should not be.
For more information, see also Secure DevOps Kit (AzSK) CICD Extensions for Azure8.
Application Deployment to Dev and Test

Once your code quality is verified, and the application is deployed to a lower environment like develop-
ment or QA, the process should verify that there are not any security vulnerabilities in the running
application. This can be accomplished by executing automated penetration test against the running
7 https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/06/08/manage-your-open-source-usage-and-security-as-reported-by-
your-cicd-pipeline/
8 https://marketplace.visualstudio.com/items?itemName=azsdktm.AzSDK-task
application to scan it for vulnerabilities. There are different levels of tests that are categorized into passive
tests and active tests. Passive tests scan the target site as is but don't try to manipulate the requests to
expose additional vulnerabilities. These can run fast and are usually a good candidate for a CI process
that you want to complete in a few minutes. Whereas the Active Scan can be used to simulate many
techniques that hackers commonly use to attack websites. These tests can also be referred to dynamic or
fuzz tests because the tests are often trying a large number of different combinations to see how the site
reacts to verify that it doesn't reveal any information. These tests can run for much longer, and typically
you don't want to cut these off at any particular time. These are better executed nightly as part of a
separate Azure DevOps release.
One tool to consider for penetration testing is OWASP ZAP. OWASP is a worldwide not-for-profit
organization dedicated to helping improve the quality of software. ZAP is a free penetration testing tool
for beginners to professionals. ZAP includes an API and a weekly docker container image that can be
integrated into your deployment process. Refer to the oswa zap vsts extension9 repo for details on how
to set up the integration. Here we're going to explain the benefits of including this into your process.
The application CI/CD pipeline should run within a few minutes, so you don't want to include any
long-running processes. The baseline scan is designed to identify vulnerabilities within a couple of
minutes making it a good option for the application CI/CD pipeline. The Nightly OWASP ZAP can spider
the website and run the full Active Scan to evaluate the most combinations of possible vulnerabilities.
OWASP ZAP can be installed on any machine in your network, but we like to use the OWASP Zap/Weekly
docker container within Azure Container Services. This allows for the latest updates to the image and also
allows being able to spin up multiple instances of the image so several applications within an enterprise
can be scanned at the same time. The following figure outlines the steps for both the Application CI/CD
pipeline and the longer running Nightly OWASP ZAP pipeline.
9 https://github.com/deliveron/owasp-zap-vsts-extension
Results and Bugs

Once the scans have completed, the Azure Pipelines release is updated with a report that includes the
results and bugs are created in the team's backlog. Resolved bugs will close if the vulnerability has been
fixed and move back into in-progress if the vulnerability still exists.
The benefit of using this is that the vulnerabilities are created as bugs that provide actionable work that
can be tracked and measured. False positives can be suppressed using OWASP ZAP's context file, so only
vulnerabilities that are true vulnerabilities are surfaced.
Even with continuous security validation running against every change to help ensure new vulnerabilities
are not introduced, hackers are continuously changing their approaches, and new vulnerabilities are
being discovered. Good monitoring tools allow you to help detect, prevent, and remediate issues discov-
ered while your application is running in production. Azure provides a number of tools that provide
detection, prevention, and alerting using rules such as OWASP Top 1010 / modSecurity and now even
using machine learning to detect anomalies and unusual behavior to help identify attackers.
Minimize security vulnerabilities by taking a holistic and layered approach to security including secure
infrastructure, application architecture, continuous validation, and monitoring. DevSecOps practices
enable your entire team to incorporate these security capabilities throughout the entire lifecycle of your
application. Establishing continuous security validation into your CI/CD pipeline can allow your applica-
tion to stay secure while you are improving the deployment frequency to meet needs of your business to
stay ahead of the competition.
10 https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
Rethinking Application Config Data

Rethinking Application Config Data
Configuration information in files
The majority of application runtime environments include configuration information that's held in files
deployed with the application. In some cases, it's possible to edit these files to change the application
behavior after it's been deployed. However, changes to the configuration require the application be
redeployed, often resulting in unacceptable downtime and other administrative overhead.
Local configuration files also limit the configuration to a single application, but sometimes it would be
useful to share configuration settings across multiple applications. Examples include database connection
strings, UI theme information, or the URLs of queues and storage used by a related set of applications.
It's challenging to manage changes to local configurations across multiple running instances of the
application, especially in a cloud-hosted scenario. It can result in instances using different configuration
settings while the update is being deployed. In addition, updates to applications and components might
require changes to configuration schemas. Many configuration systems don't support different versions
of configuration information.
Example
It’s 2:00 AM, Adam is done making all changes to his super awesome code piece, the tests are all running
fine, he hit commit -> push -> all commits pushed successfully to git. Happily, he drives back home. Ten
mins later he gets a call from the SecurityOps engineer, – Adam did you push the Secret Key to our public
repo?
YIKES!! that blah.config file Adam thinks, how could I have forgotten to include that in .gitignore, the
nightmare has already begun ….
We can surely try to blame Adam here for committing the sin of checking in sensitive secrets and not
following the recommended practices of managing configuration files, but the bigger question is that if
the underlying toolchain had abstracted out the configuration management from the developer, this
fiasco would have never happened!
History
The virus was injected a long time ago…
Since the early days of .NET, there has been the notion of app.config and web.config files which provide a
playground for developers to make their code flexible by moving common configuration into these files.
When used effectively, these files are proven to be worthy of dynamic configuration changes. However a
lot of time we see the misuse of what goes into these files. A common culprit is how samples and
documentation have been written, most samples out in the web would usually leverage these config files
for storing key elements such as ConnectionStrings, and even password. The values might be obfuscated
but what we are telling developers is that “hey, this is a great place to push your secrets!”. So, in a world
where we are preaching using configuration files, we can’t blame the developer for not managing the
governance of it. Don’t get me wrong; I am not challenging the use of Configuration here, it is an abso-
lute need of any good implementation, I am instead debating the use of multiple json, XML, yaml files in
maintaining configuration settings. Configs are great for ensuring the flexibility of the application, config
files, however, in my opinion, are a pain to manage especially across environments.
Rethinking Application Config Data 211
A ray of hope: The DevOps movement

In recent years, we have seen a shift around following some great practices around effective DevOps and
some great tools (Chef, Puppet) for managing Configuration for different languages. While these have
helped to inject values during CI/CD pipeline and greatly simplified the management of configuration,
the blah.config concept has not completely moved away. Frameworks like ASP.NET Core support the
notion of appSettings.json across environments, the framework has made it very effective to use these
across environments through interfaces like IHostingEnvironment and IConfiguration but we can do
better.
Separation of Concerns
One of the key reasons we would want to move the configuration away from source control is to deline-
ate responsibilities. Let’s define some roles to elaborate this, none of these are new concepts but rather a
high-level summary:
●● Configuration Custodian: Responsible for generating and maintaining the life cycle of configuration
values, these include CRUD on keys, ensuring the security of secrets, regeneration of keys and tokens,
defining configuration settings such as Log levels for each environment. This role can be owned by
operation engineers and security engineering while injecting configuration files through proper
DevOps processes and CI/CD implementation. Note that they do not define the actual configuration
but are custodians of their management.
●● Configuration Consumer: Responsible for defining the schema (loose term) for the configuration
that needs to be in place and then consuming the configuration values in the application or library
code. This is the Dev. And Test teams, they should not be concerned about what the value of keys are
rather what the capability of the key is, for example, a developer may need different ConnectionString
in the application but does not need to know the actual value across different environments.
●● Configuration Store: The underlying store that is leveraged to store the configuration, while this can
be a simple file, but in a distributed application, this needs to be a reliable store that can work across
environments. The store is responsible for persisting values that modify the behavior of the applica-
tion per environment but are not sensitive and does not require any encryption or HSM modules.
●● Secret Store: While you can store configuration and secrets together, it violates our separation of
concern principle, so the recommendation is to leverage a separate store for persisting secrets. This
allows a secure channel for sensitive configuration data such as ConnectionStrings, enables the
operations team to have Credentials, Certificate, Token in one repository and minimizes the security
risk in case the Configuration Store gets compromised.
External Configuration Store pattern

Store the configuration information in external storage, and provide an interface that can be used to
quickly and efficiently read and update configuration settings. The type of external store depends on the
hosting and runtime environment of the application. In a cloud-hosted scenario it's typically a cloud-
based storage service, but could be a hosted database or other system.
The backing store you choose for configuration information should have an interface that provides
consistent and easy-to-use access. It should expose the information in a correctly typed and structured
format. The implementation might also need to authorize users’ access in order to protect configuration
data, and be flexible enough to allow storage of multiple versions of the configuration (such as develop-
ment, staging, or production, including multiple release versions of each one).
Many built-in configuration systems read the data when the application starts up, and cache the data in
memory to provide fast access and minimize the impact on application performance. Depending on the
type of backing store used, and the latency of this store, it might be helpful to implement a caching
mechanism within the external configuration store. For more information, see the Caching Guidance. The
figure illustrates an overview of the External Configuration Store pattern with optional local cache.
This pattern is useful for:

●● Configuration settings that are shared between multiple applications and application instances, or
where a standard configuration must be enforced across multiple applications and application
instances.
●● A standard configuration system that doesn't support all of the required configuration settings, such
as storing images or complex data types.
●● As a complementary store for some of the settings for applications, perhaps allowing applications to
override some or all of the centrally-stored settings.
●● As a way to simplify administration of multiple applications, and optionally for monitoring use of
configuration settings by logging some or all types of access to the configuration store.
Integrating Azure Key Vault with Azure Pipeline

Applications contain many secrets, such as connection strings, passwords, certificates, and tokens, which
if leaked to unauthorized users can lead to a severe security breach. This can result in serious damage to
the reputation of the organization and in compliance issues with different governing bodies. Azure Key
Vault allows you to manage your organization's secrets and certificates in a centralized repository. The
secrets and keys are further protected by Hardware Security Modules (HSMs). It also provides versioning
of secrets, full traceability, and efficient permission management with access policies.
For more information on Azure Key Vault, visit What is Azure Key Vault11.
11 https://docs.microsoft.com/en-us/azure/key-vault/key-vault-overview
Manage Secrets, Tokens, and Certificates 213
Manage Secrets, Tokens, and Certificates

Manage Secrets, Tokens & Certificates
Azure Key Vault helps solve the following problems:
●● Secrets Management - Azure Key Vault can be used to Securely store and tightly control access to
tokens, passwords, certificates, API keys, and other secrets.
●● Key Management - Azure Key Vault can also be used as a Key Management solution. Azure Key Vault
makes it easy to create and control the encryption keys used to encrypt your data.
●● Certificate Management - Azure Key Vault is also a service that lets you easily provision, manage,
and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for
use with Azure and your internal connected resources.
●● Store secrets backed by Hardware Security Modules - The secrets and keys can be protected either
by software or FIPS 140-2 Level 2 validates HSMs.
Why use Azure Key Vault?

##Centralize application secrets
Centralizing storage of application secrets in Azure Key Vault allows you to control their distribution. Key
Vault greatly reduces the chances that secrets may be accidentally leaked. When using Key Vault, applica-
tion developers no longer need to store security information in their application. This eliminates the need
to make this information part of the code. For example, an application may need to connect to a data-
base. Instead of storing the connection string in the app codes, store it securely in Key Vault.
Your applications can securely access the information they need by using URIs that allow them to retrieve
specific versions of a secret after the application’s key or secret is stored in Azure Key Vault. This happens
without having to write custom code to protect any of the secret information.
Securely store secrets and keys

Secrets and keys are safeguarded by Azure, using industry-standard algorithms, key lengths, and hard-
ware security modules (HSMs). The HSMs used are Federal Information Processing Standards (FIPS) 140-2
Level 2 validated.
Access to a key vault requires proper authentication and authorization before a caller (user or application)
can get access. Authentication establishes the identity of the caller, while authorization determines the
operations that they are allowed to perform.
Authentication is done via Azure Active Directory. Authorization may be done via role-based access
control (RBAC) or Key Vault access policy. RBAC is used when dealing with the management of the vaults
and key vault access policy is used when attempting to access data stored in a vault.
Azure Key Vaults may be either software- or hardware-HSM protected. For situations where you require
added assurance you can import or generate keys in hardware security modules (HSMs) that never leave
the HSM boundary. Microsoft uses Thales hardware security modules. You can use Thales tools to move a
key from your HSM to Azure Key Vault.
Finally, Azure Key Vault is designed so that Microsoft does not see or extract your data.
Monitor access and use

Once you have created a couple of Key Vaults, you will want to monitor how and when your keys and
secrets are being accessed. You can do this by enabling logging for Key Vault. You can configure Azure
Key Vault to:
●● Archive to a storage account.
●● Stream to an event hub.
●● Send the logs to Log Analytics.
You have control over your logs and you may secure them by restricting access and you may also delete
logs that you no longer need.
Simplified administration of application secret

When storing valuable data, you must take several steps. Security information must be secured, it must
follow a lifecycle, it must be highly available. Azure Key Vault simplifies a lot of this by:
●● Removing the need for in-house knowledge of Hardware Security Modules
●● Scaling up on short notice to meet your organization’s usage spikes.
●● Replicating the contents of your Key Vault within a region and to a secondary region. This ensures
high availability and takes away the need of any action from the administrator to trigger the fail over.
●● Providing standard Azure administration options via the portal, Azure CLI and PowerShell.
●● Automating certain tasks on certificates that you purchase from Public CAs, such as enrollment and
renewal.
In addition, Azure Key Vaults allow you to segregate application secrets. Applications may access only the
vault that they are allowed to access, and they be limited to only perform specific operations. You can
create an Azure Key Vault per application and restrict the secrets stored in a Key Vault to a specific
application and team of developers.
Integrate with other Azure services

As a secure store in Azure, Key Vault has been used to simplify scenarios like Azure Disk Encryption, the
always encrypted functionality in SQL server and Azure SQL Database, Azure web apps. Key Vault itself
can integrate with storage accounts, event hubs and log analytics.
DevOps Inner and Outer Loop

While you can store configuration and secrets together, it violates our separation of concern principle, so
the recommendation is to leverage a separate store for persisting secrets. This allows a secure channel for
sensitive configuration data such as ConnectionStrings, enables the operations team to have Credentials,
Certificate, Token in one repository and minimizes the security risk in case the Configuration Store gets
compromised.
The below diagram shows how these roles play together in a DevOps Inner loop and Outer loop. The
inner loop is focused on the developer teams iterating over their solution development; they consume
the configuration published by the outer loop. The Ops Engineer govern the Configuration management
and push changes into Azure KeyVault and Kubernetes that are further isolated per environment.
Kubernetes and Azure Key Vault

So we have talked a lot about governance elements and the need to move out of configuration files, lets
now use some of the magic available in Kubernetes and Azure Key Vault to implement this. In particular,
we would be using the following capabilities of these technologies:
●● Azure Key Vault Secret store
●● Kubernetes ConfigMaps
●● Kubernetes Secrets
Why not just use Kubernetes you may ask?

That’s a valid question since Kubernetes supports both a ConfigMap store and Secret store. Remember
our principle around the separation of concerns and how we can ensure enhanced security by separating
out configuration from secrets. Having secrets in the same cluster as the configuration store can make
them prone to higher risks. An additional benefit is Maintainability. Azure Key Vault gives the ability to
provide a distributed “Secure Store as a Service” option that provides not just secret management but
also Certificates and Key management as part of the service. The SecOps engineers can lock down access
to the store without need of cluster admins permissions which allows for clear delineation of responsibili-
ties and access.
The Scenario
We will be building a Vehicle microservice which provides CRUD operations for sending vehicle data to a
CosmosDB document store. The sample micro-service needs to interact with the Configuration stores to
get values such as connectionstring, database name, collection name, etc. We interact with Azure Key
Vault for this purpose. Additionally, the application needs the Authentication token for Azure Key Vault
itself, these details along with other Configuration will be stored in Kubernetes.
Mapping the above diagram to our roles and responsibilities earlier:

The Ops engineer/scripts are the Configuration Custodian and they are the only ones who work in the
outer loop to manage all the configuration. They would have CI/CD scripts that would inject these
configurations or use popular framework tools to enable the insertion during the build process.
The Vehicle API is the ASP.NET Core 2.0 application and is the Configuration Consumer here; the consum-
er is interested in getting the values without really worrying about what the value is and which environ-
ment it belongs to. The ASP.NET Core framework provides excellent support for this through its Configu-
ration extensibility support. You can add as many providers as you like and they can be bound an
IConfiguration object which provides access to all the configuration. In the below code snippet, we
provide the configuration to be picked up from environment variables instead of a configuration file. The
ASP.NET Core 2.0 framework also supports extensions to include Azure Key Vault as a configuration
provider, and under the hood, the Azure Key Vault client allows for secure access to the values required
by the application.
// add the environment variables to config
config.AddEnvironmentVariables();
// add azure key vault configuration using environment variables

var buildConfig = config.Build();
// get the key vault uri

var vaultUri = buildConfig["kvuri"].Replace("{vault-name}", buildConfig["vault"]);
// setup KeyVault store for getting configuration values
config.AddAzureKeyVault(vaultUri, buildConfig["clientId"], buildConfig["clientSecret"]);
AzureKeyVault is the Secret Store for all the secrets that are application specific. It allows for the creation
of these secrets and also managing the lifecycle of them. It is recommended that you have a separate
Azure KeyVault per environment to ensure isolation. The following command can be used to add a new
configuration into KeyVault:
#Get a list of existing secrets
az keyvault secret list --vault-name -o table
#add a new secret to keyvault

az keyvault secret set -n MySecret --value MyValue --description "my custom value" --vault-name
Kubernetes is the Configuration Store and serves multiple purposes here:

1. Creation of the ConfigMaps and Secret: Since we are injecting the Azure KeyVault authentication
information using Kubernetes, the Ops engineer will provide these values using two constructs
provided in the Kubernetes infrastructure. ConfigMaps and Secrets. The following shows how to add
config maps and secrets from the Kubernetes command line:
kubectl create configmap vault --from-literal=vault=
kubectl create configmap kvuri --from-literal=kvuri=https://{vault-name}.vault.azure.net/
kubectl create configmap clientid --from-literal=clientId=
kubectl create secret generic clientsecret --from-literal=clientSecret=
The clientsecret is the only piece of secure information we store in Kubernetes, all the application specific
secrets are stored in Azure KeyVault. This is comparatively safer since the above scripts do not need to go
in the same git repo. (so we don’t check them in by mistake) and can be managed separately. We still
control the expiry of this secret using Azure KeyVault, so the Security engineer still has full control over
access and permissions.
1. Injecting Values into the Container: During runtime, Kubernetes will automatically push the above
values as environment variables for the deployed containers, so the system does not need to worry
about loading them from a configuration file. The Kubernetes configuration for the deployment looks
like below. As you would notice, we only provide a reference to the ConfigMaps and Secret that have
been created instead of punching in the actual values.
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: vehicle-api-deploy #name for the deployment
labels:
app: vehicle-api #label that will be used to map the service, this tag is very important
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
containers:
- name: vehicleapi #name for the container configuration
image: <yourdockerhub>/<youdockerimage>:<youdockertagversion> # **CHANGE THIS: the tag
for the container to be deployed
imagePullPolicy: Always #getting latest image on each deployment
ports:
- containerPort: 80 #map to port 80 in the docker container

env: #set environment variables for the docker container using configMaps and Secret Keys
- name: clientId
valueFrom:
configMapKeyRef:
name: clientid
key: clientId
- name: kvuri
valueFrom:
configMapKeyRef:
name: kvuri
key: kvuri
- name: vault
valueFrom:
configMapKeyRef:
name: vault
key: vault
- name: clientsecret
valueFrom:
secretKeyRef:
name: clientsecret
key: clientSecret
imagePullSecrets: #secret to get details of private repo, disable this if using public docker repo
- name: regsecret
Implement Tools for Managing Security and Compliance in a Pipeline 219
Implement Tools for Managing Security and

Compliance in a Pipeline
SonarCloud
Technical debt can be classified as the measure between the codebase's current state and an optimal
state. Technical debt saps productivity by making code hard to understand, easy to break, and difficult to
validate, in turn creating unplanned work, ultimately blocking progress. Technical debt is inevitable! It
starts small and grows over time through rushed changes, lack of context, and lack of discipline. Organi-
zations often find that more than 50% of their capacity is sapped by technical debt. The hardest part of
fixing technical debt is knowing where to start. SonarQube is an open source platform that is the de facto
solution for understanding and managing technical debt. In this recipe, we'll learn how to leverage
SonarQube in a build pipeline to identify technical debt.
Getting ready
SonarQube is an open platform to manage code quality. Originally famous in the Java community,
SonarQube now supports over 20 programming languages. The joint investments made by Microsoft and
SonarSource make SonarQube easier to integrate in Pipelines and better at analyzing .NET-based
applications. You can read more about the capabilities offered by SonarQube here: https://www.
sonarqube.org/. SonarSource, the company behind SonarQube offers a hosted SonarQube environment
called as SonarCloud.
Implement Continuous Security Validation

Today developers don't hesitate to use components that are available in public package sources (such as
npm or NuGet). With the aim of faster delivery and better productivity, using open source software (OSS)
components is encouraged across many organisations. However, as the dependency on these third-party
OSS components increases, the risk of security vulnerabilities or hidden license requirements also
increases compliance issues.
For a business, this is critical, as issues related to compliance, liabilities and customer personally identifia-
ble information (PII) can cause a great deal of privacy and security concerns. Identifying such issues early
on in the release cycle gives you an advanced warning and allows you enough time to fix the issues.
There are many tools such as WhiteSource, Veracode, and Checkmarx that are available, can scan for
these vulnerabilities within the build and release pipelines.
Securing Infrastructure with AzSk

With the adoption of infrastructure as code and development teams taking on more of the Ops activities,
organisations using Azure for enterprise hosting are practically at risk of breach with every new release
they roll out to these environments… In this tutorial we’ll walk through AzSDK Security Verification Tests
that can be setup in the CI/CD pipeline using Azure DevOps to automate the inspection of your infra-
structure in Azure and block releases that can potentially compromise your infrastructure.
The DevOps way of working coupled with the use of cloud technologies has practically removed the
biggest barriers from the software delivery life-cycle… Development teams don’t care about security as
much as they should. It’s hard to blame the development teams though, the tools used by security are
not easy to understand… The reports are long and hard to interpret… The approach of compliance driven
security doesn’t practically fit into the fast pace of software delivery we are used to today.
DevSecOps helps bring a fresh perspective by introducing a culture of making everyone accountable for
security, using automation to move the process of inspection left and overall looking at security with a
360 lens.
Anyone doing cloud at scale is likely to have multiple Azure subscriptions with hundreds of resource
groups in Azure dedicated to the application in question. Resource Groups comprising of resources such
as Web App’s, Azure Functions, Blob Storage, Redis Cache, App Insights, Service Bus, SQL warehouse
among some other Azure resource types. The ratio of security consultants to the number of releases
makes it practically impossible for security to inspect the changes to these resource types to guarantee
compliance of best practices.
Getting started
●● Start by installing the AzSDK extension from the Azure DevOps marketplace12
How to do it
The AzSk extension gives you the ability to both scan ARM templates to identify shortcoming in your
ARM templates and also gives you the ability to scan actual Azure resources provisioned in an Azure
subscription for compliance to best practices. We'll cover both in this tutorial.
Scanning Azure Resource Manager (ARM) Templates for

best practices
1. Create a build definition that is mapped to the git repository where you store your ARM templates
2. Next add the AzSK ARM Template Checker task to the build pipeline
12 https://marketplace.visualstudio.com/items?itemName=azsdktm.AzSDK-task
3. Next, configure the task - To start scanning, you just need to provide the root folder where you have
ARM templates (and optionally mark it to scan recursively).
4. Run the build and let the build complete. You will see glimpse of the scan in the build output itself.
5. Once the build completes, you will find that task has attached all the results to the build log. You will
be surprised to see the issues you find in your ARM templates.
6. Occasionally you will find issues which you have decided as safe to ignore. The task allows you to skip
such failures from the scan so that you will not get alerted as a security issue or cause in build failures.
The way you configure this is simple - Use the generated csv file and keep only entries you need to
ignore from the scan and commit to your repository as a csv file. Then specify this file in the task as
below.
The task currently scans App Service, Storage, SQL, CDN, Traffic Manager, Document DB, Redis Cache,
and Data Lake services only.
Scanning Azure Resources for best practices

●● Create a new release Azure pipeline, add an environment
●● In the newly added environment add the azSdk task and configure the Azure DevOps SPN for the
Azure subscription, specify the name of the Azure resource group you wish to inspect as well as the
Azure subscription id the resource group resides in.
●● Run the release pipeline and wait for the release to complete… The default security policies are
evaluated, you have the option of customizing or creating your subset… If the setup isn’t compliant
the release pipeline will fail by default…
Now review the detailed logs from the inspection…
The logs give you the full picture! The extension gives you a criticality rating and also tells you if the issue
can be auto fixed, a description and recommendation for the specific line item as well…
Summary
Pushing Security left does not mean using the old ways of security compliance checks earlier in the
life-cycle, instead it is an opportunity to leverage the DevOps mindset to innovate and automate the
security inspection to allow development teams to release features with confidence.
Azure Policy and Governance

If you don’t have standards in IT, things can get out of control and there’s no change in cloud. In fact,
there’s more of a need for governance than ever, if you don’t have it in cloud it could cause allot of
issues, excessive costs, issues supporting and a bad cloud experience to name a few. Azure Policy is
essentially designed to help set those standards on Azure use (using policies), making sure it’s used in the
right way highlighting issues (using compliance) and help fix those issues (using remediation).
You can manually create policies (to check Azure resources are configured in a certain way) or you can
use the growing number of pre-built policies. In this tutorial we'll look at a simple Azure Policy to define
allowed Azure regions for resource provisioning.
How to do it
1. Launch the Azure Portal and create a new resource group called az-rg-labs-azurepolicy-001
2. From within Azure Portal, open Policy, from the left pane click on Definitions.
Definitions are effectively the rules you want to impose. You can use the built in policies, duplicate and
edit them, or create your own from various templates like those on GitHub13
13 https://github.com/Azure/azure-policy
3. You can see the definition is a JSON file that needs a list of allowed locations and will cause a deny.
You could duplicate this definition and add more checks if needed but we’ll just assign it. Click Assign.
4. When assigning the policy, a scope needs to be selected… There are 3 options, as listed below, choose
Resource Group.
●● Management Group
●● Subscription
●● Resource Group
5. When assigning the policy, in the basics section change the assignment name and add a description.
6. To test this policy, in the resource group az-rg-labs-azurepolicy-001 try to create a resource
with location other than the allowed location.
There's more
Policies in Azure are a great way to scale enterprise policies for provisioning infrastructure across your
estate. You can now learn more about policies here14. Policies are part of Azure governance which now
also supports blue prints15 and Resource Graphs16.
14 https://docs.microsoft.com/en-us/azure/governance/policy/overview
15 https://azure.microsoft.com/en-gb/services/blueprints/
16 https://azure.microsoft.com/en-gb/features/resource-graph/
Lab
Integrating Azure Key Vault with Azure DevOps
In this lab, Integrating Azure KeyVault with Azure DevOps17, we'll cover:
●● Create a key vault, from the Azure portal, to store a MySQL server password
●● Configure permissions to let a service principal to read the value
●● Retrieve the password in an Azure pipeline and passed on to subsequent tasks
17 https://www.azuredevopslabs.com/labs/vstsextend/azurekeyvault/
Module Review and Takeaways 229
Module Review and Takeaways

Module Review Questions
Suggested answer
What is OWASP ZAP and how can it be used?
Suggested answer
What are the five stages of threat modeling?
Suggested answer
Why would you use WhiteSource Bolt?
Suggested answer
What is the Azure Key Vault and why would use it?
Answers
What is OWASP ZAP and how can it be used?
OWASP ZAP can be used for penetration testing. Testing can be active or passive. Conduct a quick baseline
scan to identify vulnerabilities. Conduct nightly more intensive scans.
What are the five stages of threat modeling?
Define security requirements. Create an application diagram. Identify threats. Mitigate threats. Validate that
threats have been mitigated.
Why would you use WhiteSource Bolt?
Use WhiteSource Bolt to automatically detect alerts on vulnerable open source components, outdated librar-
ies, and license compliance issues in your code.
What is the Azure Key Vault and why would use it?
Azure Key Vault is a cloud key management service which allows you to create, import, store & maintain
keys and secrets used by your cloud applications. The applications have no direct access to the keys, which
helps improving the security & control over the stored keys & secrets. Use the Key Vault to centralize
application and configuration secrets, securely store secrets and keys, and monitor access and use.
Module 7 Managing Code Quality and Securi-
ty Policies
Module Overview
Module Overview
Technical Debt refers to the trade-off between decisions that make something easy in the short term and
the ones that make it maintainable in the long term. Companies constantly need to trade off between
solving the immediate, pressing problems and fixing long-term issues. Both code quality and security are
mostly overlooked by software development teams as not their problem to solve! Part of the solution to
this problem is to create a quality-focused culture that encourages shared responsibility and ownership
for both code quality and security compliance. Azure DevOps has great tooling and ecosystem to
improve code quality and apply automated security checks. After completing this module, students will
be able to:
Learning Objectives
After completing this module, students will be able to:
●● Manage code quality including: technical debt SonarCloud, and other tooling solutions
●● Manage security policies with open source and OWASP
MCT USE ONLY. STUDENT USE PROHIBITED 232 Module 7 Managing Code Quality and Security Policies
Managing Code Quality

Code Quality Defined
The quality of code shouldn't be measured subjectively. A developer writing code would rate the quality
of their code high, but that's not a geat way to measure code quality. Different teams may use different
definitions, based on context. Code that is considered high quality may mean one thing for an automo-
tive developer. And it may mean another for a web application developer. The quality of the code is
important, as it impacts the overall software quality.
A study on “Software Defect Origins and Removal Methods” found that individual programmers are less
than 50% efficient at finding bugs in their own software. And most forms of testing are only 35% efficient.
This makes it difficult to determine quality.
There are five key traits to measure for higher quality.
Reliability
Reliability measures the probability that a system will run without failure over a specific period of opera-
tion. It relates to the number of defects and availability of the software.
Number of defects can be measured by running a static analysis tool. Software availability can be meas-
ured using the mean time between failures (MTBF). Low defect counts are especially important for
developing a reliable codebase.
Maintainability
Maintainability measures how easily software can be maintained. It relates to the size, consistency,
structure, and complexity of the codebase. And ensuring maintainable source code relies on a number of
factors, such as testability and understandability.
You can’t use a single metric to ensure maintainability. Some metrics you may consider to improve
maintainability are the number of stylistic warnings and Halstead complexity measures. Both automation
and human reviewers are essential for developing maintainable codebases.
Testability
Testability measures how well the software supports testing efforts. It relies on how well you can control,
observe, isolate, and automate testing, among other factors.
Testability can be measured based on how many test cases you need to find potential faults in the
system. Size and complexity of the software can impact testability. So, applying methods at the code level
— such as cyclomatic complexity — can help you improve the testability of the component.
Portability
Portability measures how usable the same software is in different environments. It relates to platform
independency.
There isn’t a specific measure of portability. But there are several ways you can ensure portable code. It’s
important to regularly test code on different platforms, rather than waiting until the end of development.
It’s also a good idea to set your compiler warning levels as high as possible — and use at least two
compilers. Enforcing a coding standard also helps with portability.
Managing Code Quality 233
Reusability
Reusability measures whether existing assets — such as code — can be used again. Assets are more
easily reused if they have characteristics such as modularity or loose coupling.
Reusability can be measured by the number of interdependencies. Running a static analyzer can help you
identify these interdependencies.
Quality Metrics
While there are various quality metrics, a few of the most important ones are listed below.
Defect Metrics
The number of defects — and severity of those defects — are important metrics of overall quality.
Complexity Metrics
Complexity metrics can help in measuring quality. Cyclomatic complexity measures of the number of
linearly independent paths through a program’s source code. Another way to understand quality is
through calculating Halstead complexity measures. These measure:
●● Program vocabulary
●● Program length
●● Calculated program length
●● Volume
●● Difficulty
●● Effort
Code analysis tools can be used to check for considerations such as security, performance, interoperabili-
ty, language usage, globalization, and should be part of every developer’s toolbox and software build
process. Regularly running a static code analysis tool and reading its output is a great way to improve as
a developer because the things caught by the software rules can often teach you something.
Measuring and Managing Quality Metrics

One of the promises of DevOps is to deliver software both faster and with higher quality. Previously,
these two metrics have been almost opposites. The faster you went, the lower the quality. The higher the
quality, the longer it took. But DevOps processes can help you to find problems earlier, and this usually
means that they take less time to fix.
Common quality-related metrics

We've previously talked about some general project metrics and KPIs. The following is a list of metrics
that directly relate to the quality of both the code being produced, and of the build and deployment
processes.
●● Failed Builds Percentage - Overall, what percentage of builds are failing?
●● Failed Deployments Percentage - Overall, what percentage of deployments are failing?
●● Ticket Volume - What is the overall volume of customer and/or bug tickets?
●● Bug Bounce Percentage - What percentage of customer or bug tickets are being re-opened?
●● Unplanned Work Percentage - What percentage of the overall work being performed is unplanned?
Technical Debt Defined

Technical debt is a term that describes the future cost that will be incurred by choosing an easy solution
today instead of using better practices because they would take longer to complete.
The term technical debt was chosen for its comparison to financial debt. It's common for people in
financial debt to make decisions that seem appropriate or the only option at the time, but in so doing,
interest accrues. The more interest that accrues, the harder it is for them in the future and the less options
that are available to them later. With financial debt, soon interest accrues on interest, creating a snowball
effect. Similarly, technical debt can build up to the point where developers are spending almost all their
time sorting out problems and doing rework, either planned or unplanned, rather than adding value.
So, how does this happen? The most common excuse is tight deadlines. When developers are forced to
create code quickly, they'll often take shortcuts. As an example, instead of refactoring a method to
include new functionality, let's just copy to create a new version of it. Then I only test my new code and
can avoid the level of testing that might be required if I change the original method because it's used by
other parts of the code. The problem is, now I have two copies of the same code that I need to modify in
the future instead of one, and I run the risk of the logic diverging. There are many causes. For example,
there might simply be a lack of technical skills and maturity among the developers or no clear product
ownership or direction. The organization might not have coding standards at all. So, the developers
didn't even know what they should be producing. The developers might not have clear requirements to
target. Well, they might be subject to last minute requirement changes. Necessary refactoring work might
be delayed. There might not be any code quality testing, manual or automated. In the end, it just makes it
harder and harder to deliver value to customers in a reasonable time frame and at a reasonable cost.
Technical debt is one of the main reasons that projects fail to meet their deadlines.
Sources and Impacts of Technical Debt

Over time, it accrues in much the same way that monetary debt does. Common sources of technical debt
are:
●● Lack of coding style and standards.
●● Lack of or poor design of unit test cases.
●● Ignoring or not understanding object orient design principles.
●● Monolithic classes and code libraries.
●● Poorly envisioned use of technology, architecture and approach. (Forgetting that all attributes of the
system, affecting maintenance, user experience, scalability, and others, need to be considered).
●● Over-engineering code (adding or creating code that is not needed, adding custom code when
existing libraries are sufficient, or creating layers or components that are not needed).
●● Insufficient comments and documentation.
●● Not writing self-documenting code (including class, method and variable names that are descriptive
or indicate intent).
●● Taking shortcuts to meet deadlines.
●● Leaving dead code in place.
✔️ Note: Over time, technical debt must be paid back. Otherwise, the team's ability to fix issues, and to
implement new features and enhancements will take longer and longer, and eventually become cost-pro-
hibitive.
Using Automated Testing to Measure Technical

Debt
We have seen that technical debt adds a set of problems during development and makes it much more
difficult to add additional customer value.
Having technical debt in a project saps productivity, frustrates development teams, makes code both
hard to understand and fragile, increases the time to make changes, and to validate those changes.
Unplanned work frequently gets in the way of planned work.
Longer term, it also saps the organization's strength. Technical debt tends to creep up on an organiza-
tion. It starts small, and grows over time. Every time a quick hack is made, or testing is circumvented
because changes needed to be rushed through, the problem grows worse and worse. Support costs get
higher and higher, and invariably, a serious issue arises.
Eventually, the organization cannot respond to its customers' needs in a timely and cost efficient way.
Automated Measurement for Monitoring

One key way to minimize the constant acquisition of technical debt, is to use automated testing and
assessment.
In the demos that follow, we'll take a look at one of the common tools that is used to assess the debt:
SonarCloud. (The original on-premises version was SonarQube).
There are other tools available and we will discuss a few of them. Later, in the next hands-on lab, you will
see how to configure your Azure Pipelines to use SonarCloud, how to understand the analysis results, and
finally how to configure quality profiles to control the rule sets that are used by SonarCloud when
analyzing your projects.
For more information, see SonarCloud1.
Discussion - Code Quality Tooling

#Discussion - Code Quality Tooling
Azure DevOps can be integrated with a wide range of existing tooling that is used for checking code
quality during builds. Which code quality tools do you currently use (if any)? What do you like or don't
like about the tools?
Measuring and Managing Technical Debt

It is important to integrate the assessment and measurement of technical debt and of code quality
overall, as part of your Continuous Integration and Deployment pipelines in Azure DevOps.
In the Continuous Integration course in this series, we showed how to add support for SonarCloud into
an Azure DevOps pipeline. After it is added and a build performed, you can see an analysis of your code:
1 https://sonarcloud.io/about
If you drill into the issues, you can then see what the issues are, along with suggested remedies, and
estimates of the time required to apply a remedy.
Integrating Other Code Quality Tools

There are many tools that can be used to assess aspects of your code quality and technical debt.
NDepend
For .NET developers, a common tool is NDepend.
NDepend is a Visual Studio extension that assesses the amount of technical debt that a developer has
added during a recent development period, typically in the last hour. With this information, the developer
might be able to make the required corrections before ever committing the code. NDepend lets you
create code rules that are expressed as C# LINQ queries but it has a large number of built-in rules that
detect a wide range of code smells.
Resharper Code Quality Analysis

Resharper can make a code quality analysis from the command-line, and can be set to automatically fail
builds when code quality issues are found. Rules can be configured for enforcement across teams.
Search in Azure DevOps

To find other code quality tools that are easy to integrate with Azure DevOps, search for the word Quality
when adding a task into your build pipeline.

●● NDepend2
●● Visual Studio marketplace3
●● Resharper Code Quality Analysis4
Planning Effective Code Reviews

Most developers would agree that code reviews can improve the quality of the applications they produce,
but only if the process for the code reviews is effective.
2 https://www.ndepend.com
3 https://marketplace.visualstudio.com/items?itemName=ndepend.ndependextension&targetId=2ec491f3-0a97-4e53-bfef-20bf80c7e1ea
4 https://marketplace.visualstudio.com/items?itemName=alanwales.resharper-code-analysis
It's important, up front, to agree that everyone is trying to achieve better code quality. Achieving code
quality can seem challenging because there is no one single best way to write any piece of code, at least
code with any complexity.
Everyone wants to do good work and to be proud of what they create. This means that it's easy for
developers to become over-protective of their code. The organizational culture must let all involved feel
that the code reviews are more like mentoring sessions where ideas about how to improve code are
shared, than interrogation sessions where the aim is to identify problems and blame the author.
The knowledge sharing that can occur in mentoring-style sessions can be one of the most important
outcomes of the code review process. It often happens best in small groups (perhaps even just two
people), rather than in large team meetings. And it's important to highlight what has been done well, not
just what needs to be improved.
Developers will often learn more in effective code review sessions than they will in any type of formal
training. Reviewing code should be seen as an opportunity for all involved to learn, not just as a chore
that must be completed as part of a formal process.
It's easy to see two or more people working on a problem and think that one person could have com-
pleted the task by themselves. That's a superficial view of the longer-term outcomes. Team management
needs to understand that improving the code quality reduces the cost of code, not increases it. Team
leaders need to establish and foster an appropriate culture across their teams.
Managing Security Policies 239
Managing Security Policies

Inspecting and Validating Code Bases for Com-
pliance
Security for applications is extremely important today. Every day, news services worldwide seem to carry
stories about some company systems that have been breached. More importantly, private company and
customer data has been disclosed. This has been happening for a long time. In many cases, it wasn't
visible to the public. Often, private information was disclosed, and yet the people affected were not even
notified. Governments across the world are frequently enacting legislation to require information about
breaches to become public and to require notifications to those affected.
So, what are the issues? Clearly, we need to protect information from being disclosed to people that
should not have access to it. But more importantly, we need to ensure that the information isn't altered
or destroyed when it shouldn't be, and we need to make sure it is destroyed when it's supposed to be.
We need to make sure we properly authenticate who is accessing the data and that they have the correct
permissions to do so. Through historical or archival data or logs, we need to be able to find evidence
when something has gone wrong.
There are many aspects to building and deploying secure applications.
●● First, there is a general knowledge problem. Many developers and other staff assume they understand
security, but they don't. Cybersecurity is a constantly evolving discipline. A program of ongoing
education and training is essential.
●● Second, we need to ensure that the code is created correctly and securely implements the required
features, and we need to make sure that the features were designed with security in mind in the first
place.
●● Third, we need to ensure that the application complies with the rules and regulations that it is re-
quired to meet. We need to test for this while building the code and retest periodically even after
deployment.
It's commonly accepted that security isn't something you can just add to an application or a system later.
Secure development must be part of every stage of the software development life cycle. This is even
more important for critical applications and those that process sensitive or highly confidential informa-
tion. Application security concepts haven't been a focus for developers in the past. Apart from the
education and training issues, it's because their organizations have emphasized fast development of
features. With the introduction of DevOps practices however, security testing is much easier to integrate.
Rather than being a task performed by security specialists, security testing should be part of the day-to-
day delivery processes. Overall, when the time for rework is taken into account, adding security to your
DevOps practices can reduce the overall time taken to develop quality software.
Planning to Implement OWASP Secure Coding

Practices
The starting point for secure development is to use secure coding practices. The Open Web Application
Security Project (OWASP)5 is a global charitable organization focused on improving the security of
software. OWASP's stated mission is to make software security visible, so that individuals and organiza-
tions are able to make informed decisions. They offer impartial and practical advice.
5 http://owasp.org
OWASP regularly publish a set of Secure Coding Practices. Their guidelines currently cover advice in the
following areas:
●● Input Validation
●● Output Encoding
●● Authentication and Password Management
●● Session Management
●● Access Control
●● Cryptographic Practices
●● Error Handling and Logging
●● Data Protection
●● Communication Security
●● System Configuration
●● Database Security
●● File Management
●● Memory Management
●● General Coding Practices
To learn about common vulnerabilities, and to see how they appear in applications, OWASP also publish-
es an intentionally vulnerable web application called The Juice Shop Tool Project6. It includes vulnerabil-
ities from all of the OWASP Top 107.
In 2002, Microsoft underwent a company-wide re-education and review phase to focus on producing
secure application code. The book, Writing Secure Code by David LeBlanc, Michael Howard8, was
written by two of the people involved and provides detailed advice on how to write secure code.
●● The OWASP foundation9
●● OWASP Secure Coding Practices Quick Reference Guide10
●● OWASP Code Review guide11
●● OWASP Top Ten12
Inspecting and Validating Code Bases for Com-

pliance
Automated Code Security Analysis
There are many tools for automating code security analysis. They include the following:
6 https://www.owasp.org/index.php/OWASP_Juice_Shop_Project
7 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
8 https://www.booktopia.com.au/ebooks/writing-secure-code-david-leblanc/prod2370006179962.html
9 http://owasp.org
10 https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
11 https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf
12 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Managing Security Policies 241
Micro Focus Fortify13 provides build tasks that can be used in Azure DevOps continuous integration
builds to identify vulnerabilities in source code. It offers two styles of analysis.
●● Fortify Static Code Analyzer (SCA) searches for violations of security-specific coding rules and
guidelines. It works in a variety of languages.
●● Fortify on Demand is a service for checking application security. The outcomes of an SCA scan are
audited by a team of security experts, including the use of Fortify WebInspect for automated dynamic
scanning.
Checkmarx CxSAST14 is a solution for Static Source Code Analysis (SAST) and Open Source Analysis
(OSA) designed for identifying, tracking and fixing technical and logical security flaws.
It is designed to integrated into Azure DevOps pipelines and allows for early detection and mitigation of
crucial security flaws. To improve performance, it is capable of incremental scanning (ie: just checking the
code recently altered or introduced).
BinSkim15 is a static analysis tool that scans binary files. BinSkim replaces an earlier Microsoft tool called
BinScope. In particular, it checks that the executable produced (ie: a Windows PE formatted file) has
opted into all of the binary mitigations offered by the Windows Platform, including:
●● SafeSEH is enabled for safe exception handling
●● ASLR is enabled so that memory is not laid out in a predictable fashion
●● Stack Protection is enabled to prevent overflow
OWASP Zed Attack Proxy Scan. Also known as OWASP ZAP Scan is an open-source web application
security scanner that is intended for users with all levels of security knowledge. It can be used by profes-
sional penetration testers.
Open Source Licensing Challenges

For more information, see Common Vulnerabilities and Exposures16.
Discussion - Security Policy Tooling

Azure DevOps can be integrated with a wide range of existing tooling that is used for checking security
policy during builds.
Which security policy tools do you currently use (if any)? What do you like or don't like about them?
13 https://marketplace.visualstudio.com/items?itemName=fortifyvsts.hpe-security-fortify-vsts
14 https://marketplace.visualstudio.com/items?itemName=checkmarx.cxsast
15 https://blogs.msdn.microsoft.com/secdevblog/2016/08/17/introducing-binskim/
16 https://cve.mitre.org/about/
Lab
Managing Technical Debt with Azure DevOps
and SonarCloud
In this hands-on lab, Managing Technical Debt with Azure DevOps and SonarCloud17, you will learn
how to manage and report on technical debt using SonarCloud integration with Azure DevOps.
You will perform the following tasks:
●● Integrate SonarCloud with Azure DevOps and run an analysis
●● Analyze the results
●● Configure a quality profile to control the rule set used for analyzing your project
✔️ Note: You must have already completed the Lab Environment Setup in the Welcome section.
17 https://www.azuredevopslabs.com/labs/azuredevops/sonarcloud/

Suggested answer
You want to run a penetration test against your application. Which tool could you use?
Suggested answer
What is code smells? Give an example of a code smell.
Suggested answer
You are using Azure Repos for your application source code repository. You want to create an audit of open
source libraries that you have used. Which tool could you use?
Suggested answer
Name three attributes of high quality code.
Suggested answer
You are using Azure Repos for your application source code repository. You want to perform code quality
checks. Which tool could you use?
Answers
You want to run a penetration test against your application. Which tool could you use?
OWASP ZAP. OWASP ZAP is designed to run penetration testing against applications. Bolt is used to
analyze open source library usage. The two Sonar products are for code quality and code coverage analysis.
What is code smells? Give an example of a code smell.
Code smells are characteristics in your code that could possibly be a problem. Code smells hint at deeper
problems in the design or implementation of the code. For example, code that works but contains many
literal values or duplicated code.
You are using Azure Repos for your application source code repository. You want to create an audit of
open source libraries that you have used. Which tool could you use?
WhiteSource Bolt is used to analyze open source library usage. OWASP ZAP is designed to run penetration
testing against applications. The two Sonar products are for code quality and code coverage analysis.
Name three attributes of high quality code.
High quality code should have well-defined interfaces. It should be clear and easy to read so self-document-
ing is desirable, as is short (not long) method bodies.
You are using Azure Repos for your application source code repository. You want to perform code quality
checks. Which tool could you use?
SonarCloud is the cloud-based version of the original SonarQube, and would be best for working with code
in Azure Repos.
Module 8 Implementing a Container Build
Strategy
Module Overview
Module Overview
Containers are the third model of compute, after bare metal and virtual machines – and containers are
here to stay. Docker gives you a simple platform for running apps in containers, old and new apps on
Windows and Linux, and that simplicity is a powerful enabler for all aspects of modern IT. Containers
aren’t only faster and easier to use than VMs; they also make far more efficient use of computing hard-
ware.
Learning Objectives
●● Implement a container strategy including how containers are different from virtual machines and how
microservices use containers
●● Implement containers using Docker
MCT USE ONLY. STUDENT USE PROHIBITED 246 Module 8 Implementing a Container Build Strategy
Managing Code Quality

Overview of Containers
If you’re a programmer or techie, chances are you’ve at least heard of Docker: a helpful tool for packing,
shipping, and running applications within “containers.” It’d be hard not to, with all the attention it’s
getting these days — from developers and system admins alike. Just to reiterate, there is a difference
between containers and docker. A container is a thing that runs a little program package, while Docker is
the container runtime and orchestrator.
What are containers and why do you need them?

Containers are a solution to the problem of how to get software to run reliably when moved from one
computing environment to another. This could be from a developer's laptop to a test environment, from
a staging environment into production, and perhaps from a physical machine in a data center to a virtual
machine in a private or public cloud.
Problems arise when the supporting software environment is not identical. Let's take an example, say you
are going to develop using Python 3, but when it gets deployed to production it's going to run on
Python 2.7, this is likely to cause several issues. It's just not limited to software environment, you are likely
to encounter issues in production if there are differences in the networking stack between the two
environments.
How do containers solve this problem?

Put simply, a container consists of an entire runtime environment: an application, plus all its dependen-
cies, libraries and other binaries, and configuration files needed to run it, bundled into one package. By
containerizing the application platform and its dependencies, differences in OS distributions and underly-
ing infrastructure are abstracted away.
What's the difference between containers and virtualiza-

tion?
Containers and VMs are similar in their goals: to isolate an application and its dependencies into a
self-contained unit that can run anywhere.
Moreover, containers and VMs remove the need for physical hardware, allowing for more efficient use of
computing resources, both in terms of energy consumption and cost effectiveness.
The main difference between containers and VMs is in their architectural approach. Let’s take a closer
look.
Virtual Machines
A VM is essentially an emulation of a real computer that executes programs like a real computer. VMs run
on top of a physical machine using a “hypervisor”. As you can see in the diagram, VMs package up the
virtual hardware, a kernel (i.e. OS) and user space for each new VM.
Container
Unlike a VM which provides hardware virtualization, a container provides operating-system-level virtual-
ization by abstracting the “user space”. This diagram shows you that containers package up just the user
space, and not the kernel or virtual hardware like a VM does. Each container gets its own isolated user
space to allow multiple containers to run on a single host machine. We can see that all the operating
system level architecture is being shared across containers. The only parts that are created from scratch
are the bins and libs. This is what makes containers so lightweight.
What other benefits do containers offer?

A container may be only tens of megabytes in size, whereas a virtual machine with its own entire operat-
ing system may be several gigabytes in size. Because of this, a single server can host far more containers
than virtual machines.
Another major benefit is that virtual machines may take several minutes to boot up their operating
systems and begin running the applications they host, while containerized applications can be started
almost instantly. That means containers can be instantiated in a “just in time” fashion when they are
needed and can disappear when they are no longer required, freeing up resources on their hosts.
A third benefit is that containerization allows for greater modularity. Rather than run an entire complex
application inside a single container, the application can be split in to modules (such as the database, the
application front end, and so on). This is the so-called microservices approach. Applications built in this
way are easier to manage because each module is relatively simple, and changes can be made to mod-
ules without having to rebuild the entire application. Because containers are so lightweight, individual
modules (or microservices) can be instantiated only when they are needed and are available almost
immediately.
Discussion - Containers vs Virtual Machines

In your development environment, do you currently use virtualization of any type? Do you prefer to
deploy containers or entire virtual machines?
Docker Containers and Development
Docker is a software containerization platform with a common toolset, packaging model, and deploy-
ment mechanism, which greatly simplifies containerization and distribution of applications that can be
run anywhere. This ubiquitous technology not only simplifies management by offering the same manage-
ment commands against any host, it also creates a unique opportunity for seamless DevOps.
From a developer’s desktop to a testing machine, to a set of production machines, a Docker image can
be created that will deploy identically across any environment in seconds. This is a massive and growing
ecosystem of applications packaged in Docker containers, with DockerHub, the public containerized-ap-
plication registry that Docker maintains, currently publishing more than 180,000 applications in the public
community repository. Additionally, to guarantee the packaging format remains universal, Docker
organized the Open Container Initiative (OCI), aiming to ensure container packaging remains an open
and foundation-led format.
As an example of the power of containers, a SQL Server Linux instance can be deployed using a Docker
image in seconds.
For more information, see:
●● Docker Ebook, Docker for the Virtualization Admin1
●● Mark Russinovich blog post on Containers: Docker, Windows, and Trends2
1 https://goto.docker.com/docker-for-the-virtualization-admin.html
2 https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/
Microservices and containers
The most immediately lucrative use for containers has been focused on simplifying DevOps with easy
developer-to-test-to-production flows for services deployed in the cloud or on-premises. But there is
another fast-growing scenario where containers are becoming very compelling.
Microservices is an approach to application development where every part of the application is deployed
as a fully self-contained component, called a microservice, that can be individually scaled and updated.
Example Scenario
Imagine that you are part of a software house that produces a large monolithic financial management
application that you are migrating to a series of microservices. The existing application would include the
code to update the general ledger for each transaction, and it would have this code in many places
throughout the application. If the schema of the general ledger transactions table is modified, this would
require changes throughout the application.
By comparison, the application could be modified to make a notification that a transaction has occurred.
Any microservice that is interested in the transactions could subscribe. In particular, a separate general
ledger microservice could subscribe to the transaction notifications, and then perform the general ledger
related functionality. If the schema of the table that holds the general ledger transactions is modified,
only the general ledger microservice should need to be updated.
If a particular client organization wants to run the application and not use the general ledger, that service
could just be disabled. No other changes to the code would be required.
Scale
In a dev/test environment on a single system, while you might have a single instance of each microser-
vice, in production you might scale out to different numbers of instances across a cluster of servers
depending on their resource demands as customer request levels rise and fall. If different teams produce
them, the teams can also independently update them. Microservices is not a new approach to program-
ming, nor is it tied explicitly to containers, but the benefits of Docker containers are magnified when
applied to a complex microservice-based application. Agility means that a microservice can quickly scale
out to meet increased load, the namespace and resource isolation of containers prevents one microser-
vice instance from interfering with others, and use of the Docker packaging format and APIs unlocks the
Docker ecosystem for the microservice developer and application operator. With a good microservice
architecture, customers can solve the management, deployment, orchestration and patching needs of a
container-based service with reduced risk of availability loss while maintaining high agility.
Azure Container-Related Services

Azure provides a wide range of services that help you to work with containers. These are the key services
that are involved:
Azure Container Instances (ACI)3
Running your workloads in Azure Container Instances (ACI), allows you to focus on creating your applica-
tions rather than focusing on provisioning and management of the infrastructure that will run the
applications.
ACIs are simple and fast to deploy, and when you are using them, you gain the security of hypervisor
isolation for each container group. This ensures that your containers aren't sharing an operating system
kernel with other containers.
Azure Kubernetes Service (AKS)4
Kubernetes has quickly become the de facto standard for container orchestration. This services lets you
easily deploy and manage Kubernetes, to scale and run applications, while maintaining strong overall
security.
This service started life as Azure Container Services (ACS) and at release supported Docker Swarm and
Mesos/Mesosphere DC/OS for managing orchestrations. These original ACS workloads are still supported
in Azure but Kubernetes support was added. This quickly became so popular that Microsoft changed the
acryonym for Azure Container Services to AKS, and later changed the name of the service to Azure
Kubernetes Service (also AKS).
Azure Container Registry (ACR)5
This service lets you store and manage container images in a central registry. It provide you with a Docker
private registry as a first-class Azure resource.
All types of container deployments, including DC/OS, Docker Swarm, Kubernetes are supported and the
registry is integrated with other Azure services such as the App Service, Batch, Service Fabric and others.
Importantly, this allows your DevOps team to manage the configuration of apps without being tied to the
configuration of the target hosting environment.
Azure Service Fabric6
Azure Service Fabric allows you to build and operate always-on, scalable, distributed apps. It simplifies
the development of microservice-based applications and their life cycle management including rolling
updates with rollback, partitioning, and placement constraints. It can host and orchestrate containers,
including stateful containers.
Azure App Service7
3 https://azure.microsoft.com/en-us/services/container-instances/
4 https://azure.microsoft.com/en-us/services/kubernetes-service/
5 https://azure.microsoft.com/en-us/services/container-registry/
6 https://azure.microsoft.com/en-us/services/service-fabric/
7 https://azure.microsoft.com/en-us/services/app-service/
Azure Web Apps provides a managed service for both Windows and Linux based web applications, and
provides the ability to deploy and run containerized applications for both platforms. It provides options
for auto-scaling and load balancing and is easy to integrate with Azure DevOps.
Dockerfile Core Concepts

Dockerfiles are text files that contain the commands needed by docker build to assemble an image.
Here is an example of a very basic Dockerfile:
FROM ubuntu
LABEL maintainer="greglow@contoso.com"
ADD appsetup /
RUN /bin/bash -c 'source $HOME/.bashrc; \
echo $HOME'
CMD ["echo", "Hello World from within the container"]
Note the following in this example.

The first line refers to the parent image that this new image will be based upon. Generally, all images will
be based off another existing image. In this case, the Ubuntu image would be retrieved from either a
local cache or from DockerHub. An image that doesn't have a parent is called a base image. In that rare
case, the FROM line can be omitted, or FROM scratch can be used instead.
The second line indicates the email address of the person who maintains this file. Previously, there was a
MAINTAINER command but that has been deprecated and replaced by a label.
The third line adds a file into the root folder of the image. It can also add an executable.
The fourth and fifth lines are part of a RUN command. Note the use of the backslash to continue the
fourth line onto the fifth line, for readability. This is equivalent to having written this instead:
RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME'
The RUN command is run when the image is being created by docker build. It is generally used to
configure items within the image.
By comparison, the last line represents a command that will be executed when a new container is created
from the image ie: it is run after container creation.
Dockerfile reference8
Multiple Stage Builds

It's important when building images, to keep the image size as small as possible. Every additional instruc-
tion that is added to the Dockerfile adds what is referred to as a layer. Each layer often contains artifacts
that are not needed in the final image and should be cleaned up before moving to the next layer. Doing
this has been tricky.
Docker 17.05 added a new feature that allowed the creation of multi-stage builds. This helps with being
able to optimize the files, improves their readability, and makes them easier to maintain.
Here is an example of a multi-stage file that was created by Visual Studio 2017:
8 https://docs.docker.com/engine/reference/builder/
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base

WORKDIR /app
EXPOSE 6636
EXPOSE 44320
FROM microsoft/dotnet:2.1-sdk AS build

WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app
FROM build AS publish

RUN dotnet publish "WebApplication1.csproj" -c Release -o /app
FROM base AS final

WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction
starts a new stage. The stages are numbered in order, starting with stage 0. To make the file easier to
maintain without needing to constantly change numbers that reference, note how each stage has been
named (or aliased) by using an AS clause.
Each FROM instruction can have a different parent (ie: base). This allows the developer to control what is
copied from one stage to another, and avoids the need for intermediate images.
Another advantage of named stages is that they are easier to refer to in external commands. For example,
not all stages need to be built each time. You can see that in the following Docker CLI command:
$ docker build --target publish -t gregsimages/popkorn:latest .
The –target option tells docker build that it needs to create an image up to the target of publish, which
was one of the named stages.
Considerations for Multiple Stage Builds

Adopt Container Modularity
Try to avoid creating overly complex container images that couple together a number of applications.
Instead, use multiple containers and try to keep each container to a single purpose. The website and the
database for a web application should likely be in separate containers.
There are always exceptions to any rule but breaking up application components into separate containers
increases the chances of being able to reuse containers. It also makes it more likely that you could scale
the application. For example, in the web application mentioned, you might want to add replicas of the
website container but not for the database container.
Avoid Unnecessary Packages

To help with minimizing image sizes, it is also important avoid including packages that you suspect might
be needed but aren't yet sure if they are needed. Only include them when they are needed.
Choose an Appropriate Base

While optimizing the contents of your Dockerfiles is important, it is also very important to choose the
appropriate parent (base) image. Start with an image that only contains packages that are required.
Avoid Including Application Data

While application data can be stored in the container, doing this will make your images larger. You should
consider using docker volume support to maintain the isolation of your application and its data. Vol-
umes are persistent storage mechanisms that exist outside the lifespan of a container.
For more information, see Use multiple stage builds9.
Demonstration - Create an Azure Container Reg-

istry
What is Azure Container Registry?
Azure Container Registry is a managed, private Docker registry service based on the open-source Docker
Registry 2.0. You can use Azure container registries to store and manage your private Docker container
images and related artifacts. Azure container registries can be used with your existing container develop-
ment and deployment pipelines. Azure Container Registry task in Azure DevOps can be used to build
container images in Azure. These tasks can be used to build images on demand and fully automate build
workflows with triggers such as source code commits and base image updates.
Create an Azure Container Registry

The Azure Portal offers a great experience for creating a new container registry. In this section, we'll go
through the steps of creating a new registry via the Azure CLI.
Create a resource group

Create a resource group with the az group create command. An Azure resource group is a logical
container into which Azure resources are deployed and managed. The following example creates a
resource group named myResourceGroup in the eastus location.
az group create --name myResourceGroup --location eastus
Create a container registry

The following example will create a basic registry called myaz400containerregistry in the resource group
we created in the previous step.
9 https://docs.docker.com/develop/develop-images/multistage-build/
az acr create --resource-group myResourceGroup --name myaz400containerregistry --sku Basic
The response from this command, returns the loginserver which has the fully qualified url of the
registry.
{
"adminUserEnabled": false,
"creationDate": "2020-03-08T22:32:13.175925+00:00",
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/
providers/Microsoft.ContainerRegistry/registries/myaz400containerregistry",
"location": "eastus",
"loginServer": "myaz400containerregistry.azurecr.io",
"name": "myaz400containerregistry",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"status": null,
"storageAccount": null,
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}
Log in to registry
Before pushing and pulling container images, you must log in to the registry. To do so, use the az acr
login command.
az acr login --name <acrName>
Push image to registry

To push an image to an Azure Container registry, you must first have an image. If you don't yet have any
local container images, run the following docker pull command to pull an existing image from Docker
Hub. For this example, pull the hello-world image.
docker pull hello-world
Before you can push an image to your registry, you must tag it with the fully qualified name of your ACR
login server. The login server name is in the format ‘registry-name’.azurecr.io (all lowercase), for example,
myaz400containerregistry.azurecr.io.
docker tag hello-world <acrLoginServer>/hello-world:v1
Finally, use docker push to push the image to the ACR instance. Replace acrLoginServer with the login
server name of your ACR instance. This example creates the hello-world repository, containing the
hello-world:v1 image.
docker push <acrLoginServer>/hello-world:v1
After pushing the image to your container registry, remove the hello-world:v1 image from your local
Docker environment.
docker rmi <acrLoginServer>/hello-world:v1
List container images

The following example lists the repositories in your registry:
az acr repository list --name <acrName> --output table
Run image from registry

You can pull and run the hello-world:v1 container image from your container registry by using docker
run:
docker run <acrLoginServer>/hello-world:v1
Clean up resources
When no longer needed, you can use the az group delete command to remove the resource group, the
container registry, and the container images stored there.
az group delete --name myResourceGroup
Demonstration - Add Docker Support to an Ex-

isting Application
Add Docker Support to an Existing Application
Visual Studio 2017 and later versions support building, debugging, and running containerized ASP.NET
Core apps targeting .NET Core. Both Windows and Linux containers are supported.
To containerize an ASP.NET Core project, the project must target .NET Core. Both Linux and Windows
containers are supported.
When adding Docker support to a project, choose either a Windows or a Linux container. The Docker
host must be running the same container type. To change the container type in the running Docker
instance, right-click the System Tray's Docker icon and choose Switch to Windows containers… or Switch
to Linux containers….
Follow the steps here on Microsoft Docs for a walkthrough on how to add docker support to an
existing application10.
10 https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/visual-studio-tools-for-docker?view=aspnetcore-3.1
Lab 257
Lab
Modernizing Your Existing ASP.NET Apps with
Azure
In this hands-on lab, Modernizing your existing ASP.NET Apps with Azure11,you will learn how to
modernize an existing ASP.NET application with migration to Docker images managed by the Azure
Container Registry.
You will perform the following tasks:
●● Migrate the LocalDB to SQL Server in Azure
●● Using the Docker tools in Visual Studio 2017, add Docker support for the application
●● Publish Docker Images to Azure Container Registry (ACR)
●● Push the new Docker images from ACR to Azure Container Instances (ACI)
11 https://www.azuredevopslabs.com/labs/vstsextend/aspnetmodernize/

Suggested answer
You are reviewing an existing Dockerfile. How would you know if it's a multi-stage Dockerfile?
Suggested answer
You are designing a multi-stage Dockerfile. How can one stage refer to another stage within the Dockerfile?
Suggested answer
What is the line continuation character in Dockerfiles?
Suggested answer
You are using Azure to manage your containers. Which container orchestration styles are supported?
Suggested answer
When the Open Container Initiative defined a standard container image file format, which format did they
choose as a starting point?
Answers
You are reviewing an existing Dockerfile. How would you know if it's a multi-stage Dockerfile?
Multi-stage Docker files are characterized by containing more than one starting point provided as FROM
instructions.
You are designing a multi-stage Dockerfile. How can one stage refer to another stage within the Docker-
file?
The FROM clause in a multi-stage Dockerfile can contain an alias via an AS clause. The stages can refer to
each other by number or by the alias names.
What is the line continuation character in Dockerfiles?
Lines can be broken and continued on the next line of a Dockerfile by using the backslash character.
You are using Azure to manage your containers. Which container orchestration styles are supported?
Swarm, DC/OS, and AKS are supported.
When the Open Container Initiative defined a standard container image file format, which format did they
choose as a starting point?
The OCI used the Docker format as a starting point.

Module 9 Manage Artifact Versioning, Securi-
ty, and Compliance
Module Overview
Module Overview
Welcome to this module about managing artifact versioning, security, and compliance. In this module, we
will talk about how you can secure your packages and feeds and check security requirements on the
packages used in developing your software solutions. Also we will cover how to make sure the packages
used are compliant to the standard and requirements that exist in your organization from a licensing and
security vulnerability perspective.
Learning objectives
At the end of this module, students will be able to:
●● Inspect open source software packages for security and license complaince to align with corporate
standards
●● Configure build pipeline to access package security and license rating
●● Configure secure access to package feeds
●● Inspect codebase to identify code dependencies that can be converted to packages
●● Identify and recommend standardized package types and versions across the solution
●● Refactor existing build pipelines to implement version strategy that publishes packages
●● Manage security and compliance
MCT USE ONLY. STUDENT USE PROHIBITED 262 Module 9 Manage Artifact Versioning, Security, and Compliance
Package Security
Package Feeds
Package feeds are a trusted source of packages. The packages that are offered will be consumed by other
code bases and used to build software that needs to be secure. Imagine what would happen if a package
feed would offer malicious components in its packages. Each consumer would be affected when installing
the packages onto its development machine or build server. This also happens at any other device that
will run the end product, as the malicious components will be executed as part of the code. Usually the
code runs with high priviliges, giving a substantial security risk if any of the packages cannot be trusted
and might contain unsafe code.
Therefore, it is essential that package feeds are secured for access by authorized accounts, so only
verified and trusted packages are stored there. Noone should be able to push packages to a feed without
the proper role and permissions. This prevents others from pushing malicious packages. It still assumes
that the persons who are allowed to push packages will only add safe and secure packages. Especially in
the open source world this is performed by the community. A package source can further guard its feed
with the use of security and vulnerability scan tooling. Additionally, consumers of packages can use
similar tooling to perform the scans themselves.
Another aspect of security for package feeds is about public or private availability of the packages. The
feeds of public sources are usually available for anonymous consumption. Private feeds on the other
hand have restricted access most of the time. This applies to consumption and publishing of packages.
Private feeds will allow only users in specific roles or teams access to its packages.
Package compliance
Nowadays companies have obligations towards their customers and employees to make sure that the
services they offer with software and IT are compliant to rules and regulations. In part the rules and
regulations come from governments, certification and standards institutes. They might also be self
imposed rules and regulations from the company or organization itself. This could include rules about
how open source is used, which license types are allowed and a package version policy.
When development teams are empowered to make their own choices for the use of packages it becomes
very important that they are choosing the right type of packages. In this case that would imply that the
packages are allowed from a licensing perspective and follow the chosen ruleset to be compliant with the
applicable policies. It involves practices, guidelines, hosting, additional work and introduction of tooling
that will help to make sure that compliancy is part of the software development process when it comes to
producing and consuming packages.
The compliancy of packages should be guaranteed and provable. The software development processes
should take this into account in an integral fashion. We will look at open source software and licensing in
the next chapters, and see how we can leverage Azure DevOps and other tools and services to implement
a policy for security and compliancy for closed and open source alike.
Securing access to package feeds

Package feeds need to have secure access for a variety of reasons. The access should involve allowing:
●● Restricted access for consumption
Whenever a package feed and its packages should only be consumed by a certain audience, it is
required to restrict access to it. Only those allowed access will be able to consume the packages from
the feed.
Package Security 263
●● Restricted access for publishing

Secure access is required to restrict who can publish so feeds and their packages cannot be modified
by unauthorized or untrusted persons and accounts.
Roles
Azure Artifacts has four different roles for package feeds. These are incremental in the permissions they
give.
The roles are in incremental order:
●● Reader: Can list and restore (or install) packages from the feed
●● Collaborator: Is able to save packages from upstream sources
●● Contributor: Can push and unlist packages in the feed
●● Owner: has all available permissions for a package feed
When creating an Azure Artifacts feed, the Project Collection Build Service is given contribu-
tor rights by default. This organization-wide build identity in Azure Pipelines is able to access the feeds it
needs when running tasks. If you changed the build identity to be at project level, you will need also give
that identity permissions to access the feed.
Any contributors to the team project are also contributors to the feed. Project Collection Administrators
and administrators of the team project, plus the creator of the feed are automatically made owners of the
feed. The roles for these users and groups can be changed or removed.
Permissions
The feeds in Azure Artifacts require permission to the various features it offers. The list of permissions
consists of increasing priviliged operations.
The list of priviliges is as follows:
For each permission you can assign users, teams and groups to a specific role, giving the permissions
corresponding to that role. You need to have the Owner role to be able to do so. Once an account has
access to the feed from the permission to list and restore packages it is considered a Feed user.
Just like permissions and roles for the feed itself, there are additional permissions for access to the
individual views. Any feed user has access to all the views, whether the default views of @Local, @Release
or @Prerelease, or newly created ones. During creation of a feed you can choose whether the feed is
visible to people in your Azure DevOps organization or only specific people.
See also:
Secure and share packages using feed permissions1
Credentials
Azure DevOps users will authenticate against Azure Active Directory when accessing the Azure DevOps
portal. After being successfully authenticated, they will not have to provide any credentials to Azure
Artifacts itself. The roles for the user, based on its identity, or team and group membership, are for
authorization. When access is allowed, the user can simply navigate to the Azure Artifacts section of the
team project.
The authentication from Azure Pipelines to Azure Artifacts feeds is taken care of transparently. It will be
based upon the roles and its permissions for the build identity. The previous section on Roles covered
some details on the required roles for the build identity.
The authentication from inside Azure DevOps does not need any credentials for accessing feeds by itself.
However, when accessing secured feeds outside Azure Artifacts, such as other package sources, you most
1 https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions
Package Security 265
likely have to provide credentials to authenticate to the feed manager. Each package type has its own
way of handling the credentials and providing access upon authentication. The command-line tooling will
provide support in the authentication process.
For the build tasks in Azure Pipelines, you will provide the credentials via a Service connection.
Open source software

How software is built
Let's look at using open-source software in building software.
Using open-source software

Packages contain components that are built from source code. Open source code is publicly available for
inspection, reuse and contribution. Most commonly open source projects indicate how the sources can
be used and distributed afterwards. A license agreement accompanies the source code and specifies what
can and cannot be done.
In the previous module we covered how modern software is built by using components. These compo-
nents are created in part by the team that is writing the entire software solution. Some dependencies are
on components created and made available by other teams, third party companies and the community.
The packages that contain the components are a fomalized way for ditribution.
On average the software solution being built is around 80% based on components that exist and are
maintained outside of the project. The rest of the solution consists of your code with business logic and
specifics for the functional requirements, plus “glue” code that binds together the components and your
code.
The components can be a commercial offering or free of charge. A considerable part of the publically
available and free components are community efforts to offer reusable components for everyone to use
and build software. The persons creating and maintaining these components often also make the source
code available. This is considered to be open-source code as opposed to closed source. Closed source
means that the source code is not available, even though components are available.
What is open-source software?

Wikipedia defines open-source software as follows:
"Open-source software (OSS) is a type of computer software in which source code is released under a license
in which the copyright holder grants users the rights to study, change, and distribute the software to anyone
and for any purpose."
The related open source software development is a collaborative form of software development, involv-
ing multiple contributors. Together they create and maintain software and source code using open
sources. The use of open-source software is widely adopted now.
Microsoft itself has also embraced open-source software in its own software and the development
platforms they offer. The .NET platforms, such as the original .NET Framework and even more so .NET
Core, use several components that are created by the open source community and not Microsoft itself. In
ASP.NET and ASP.NET Core, many of the frontend development libraries are open-source components,
such as jQuery, Angular and React. Instead of creating new components themselves, the teams at Micro-
soft are leveraging the open-source components and take a dependency on them. The teams are also
contributing and investing to the open source components and projects, joining in on the collaborative
effort.
Besides adopting external open-source software Microsoft has also made significant parts of their
software available as open-source. .NET is a perfect example of how Microsoft has changed its posture
towards open-source. It has made the codebase for the .NET Framework and .NET Core available, as well
as many other components. The .NET Foundation aims to advocate the needs, evangelize the benefits of
the .NET platform. and promote the use of .NET open source for developers.
Open source software 267
For more information, see the .NET foundation website2.
Challenge to corporates
All in all, modern software development, including the Microsoft developer platform and ecosystem
implies the use of open-source components. This has implications for companies that build software,
either commercially or for internal use. The inclusion of software components that are not build by the
companies themselves, means that there is no full control over the sources.
Others being responsible for the source code that is used in components used within a company, means
that you have to accept the risks involved with it. The source code could:
●● Be of low quality
This would impact maintainability, reliability and performance of the overall solution
●● Have no active maintenance
The code would not evolve over time, or be alterable without making a copy of the source code,
effectively forking away from the origin.
●● Contain malicious code
The entire system that includes and uses the code will be compromised. Potentially the entire compa-
ny's IT and infrastructure is affected.
●● Have security vulnerabilities
The security of a software system is as good as its weakest part. Using source code with vulnerabilities
makes the entire system susceptible to attack by hackers and misuse.
●● Have unfavorable licensing restrictions
The effect of a license can affect the entire solution that uses the open-source software.
The companies will have to make a trade-off: its developers want to be able to use open-source software
components, allowing them to speed up development and use modern frameworks, libraries and practic-
es. On the other hand, giving the developers and projects the freedom to include open-source software
should not put the company at risk. The challenges to the company are in finding a way to keep the
developers empowered and free to choose technology to use, while making sure the risks for the compa-
ny are managed as well as possible.
Other challenges comes from companies that offer open-source software to the public. These challenges
include having a business model around the open-source, when to publish open-source code and how to
deal with community contributions. The fact that your source code is open, doesn't imply that anyone can
make changes to it. There can be contributions from community collaboration, but a company does not
necessarily have to accept it. This is referred to as closed open-source. Suggestions for change are
welcome, but the maintainers are the one that carry out the actual changes.
Licenses and vulnerabilities

Open-source software and the related source code is accompanied by a license agreement. The license
describes the way the source code and the components built from it can be used and how any software
created with it should deal with it.
According to the open source definition of OpenSource.org a license should not:
●● Discriminate against persons or groups
●● Discriminate against fields of endeavour
2 http://www.dotnetfoundation.org
●● Be specific to a product
●● Restrict other software
●● and more - See the Open Source Definition3
To cover the exact terms of a license several types exist. Each type has its own specifics and implications,
which we will cover in the next part.
Even though open-source software is generally developed by multiple contributors from the community,
it does not guarantee that the software is secure and without vulnerabilities. Chances are they are
discovered by being inspected by multiple reviewers, but the discovery might not be immediate or before
being consumed by others.
Since the source code is open-source, people with malicious intent can also inspect the code for vulnera-
bilities and exploit these when possible. In that regard, it is both a blessing and a curse that open-source
software has source code available for others.
Open-source package licensing

In the current and previous module we have talked about software components from the perspective of
packages. Packages are the formalized ways to distribute software components. The licensing types and
concerns about vulnerabilities extend to the packages, as these contain the components.
Types of licenses
There are multiple licenses used in open-source and they are different in nature. The license spectrum is a
chart that shows licenses from the perspective of the developer and the implications of use for down-
stream requirements that are imposed on the overall solution and source code.
On the left side there are the “attribution” licenses. They are permissive in nature and allow practically
every type of use by the software that consumes it. An example is building commercially available
software including the components or source code under this license. The only restriction is that the
original attribution to the authors remains included in the source code or as part of the downstream use
of the new software.
3 http://opensource.org/osd
Open source software 269
The right side of the spectrum shows the “copyleft” licenses. These licenses are considered viral in nature,
as the use of the source code and its components, and distribution of the complete software, implies that
all source code using it should follow the same license form. The viral nature is that the use of the
software covered under this license type forces you to forward the same license for all work with or on
the original software.
The middle of the spectrum shows the “downstream” or "weak copyleft" licenses. It also requires that
when the covered code is distributed, it must do so under the same license terms. Unlike the copyleft
licenses this does not extend to improvements or additions to the covered code.
License implications and rating

Any form of software that uses code or components must take into account the license type that is
covered. For companies it becomes important to know the types of licenses for components and packag-
es that developers choose to use. When these include even one viral license, it requires that all software
must be using the same license. Any intellectual property you might have, must be made public and
open-source according to the terms of the viral license type. This has tremendous impact on the source
code of the project and consequently for the company that produces it.
License rating
Licenses can be rated by the impact that they have. When a package has a certain type of license, the use
of the package implies keeping to the requirements of the package. The impact the license has on the
downstream use of the code, components and packages can be rated as High, Medium and Low, de-
pending on the copy-left, downstream or attribution nature of the license type.
For compliancy reasons, a high license rating can be considered a risk for compliancy, intellectual proper-
ty and exclusive rights.
Package security
The use of components creates a software supply chain. The resultant product is a composition of all its
parts and components. This applies to the security level of the solution as well. Therefore, similar to
license types it is important to know how secure the components being used are. If one of the compo-
nents used is not secure, then the entire solution isn't either. We will talk more on package security and
vulnerabilities in the next chapter.
Integrating license and vulnerability scans

Artifact repositories
Let's learn about artifact repositories and their use, plus tooling to help in identifying security vulnerabili-
ties and license and compliancy issues.
Looking at package management and the challenges of keeping control of licenses and vulnerabilities,
every feed and its packages that is consumed is a potential risk. Normally, the build tooling will interact
with internal and potentially external package feeds. Upstream sources can be a way to avoid direct
access to external feeds.
If each developer, team and build process would be able to connect directly to external feeds, it is hard to
perform package management from the perspective of licensing and security vulnerabilities.
Artifact repositories are used to store software artifacts in a centralized, internal place or flow, much like
package feeds. The repository becomes the single source of packages for the entire organization,
facilitating an overview of the packages in use by each of the consumers.
Tools for assessing package security and license

rating
There are several tools available from third parties to help in assessing the security and license rating of
software packages that are in use.
One approach by these tools is to provide the centralized artifact repository as discussed in the previous
section. Scanning can be done at any particular time, inspecting the packages that are part of the
repository.
The second approach is to use tooling that scans the packages as they are used in a build pipeline.
During the build process, the tool can scan the packages by the particular build, giving instantaneous
feedback on the packages in use.
Inspect packages in delivery pipeline

There is tooling available to perform security scans on packages, components and source code while
running a delivery pipeline. Ogten such tooling will use the build artifacts during the build process and
perform scans.
The tooling can take either of the approaches of working on a local artifact repository or the intermediary
build output. Some examples for each are products like:
Tool Type
Artifactory Artifact repository
SonarCube Artifact repository
WhiteSource (Bolt) Build scanning
Configure pipeline
The configuration of the scanning for license types and security vulnerability in the pipeline is done by
using appropriate build tasks in your DevOps tooling. For Azure DevOps these are build pipeline tasks.
WhiteSource is a third party product that offers both a paid and free version to use in Azure Pipelines.
The tool uses the local build artifacts on the build server and runs directly from there. It will scan for the
Integrating license and vulnerability scans 271
various package types used in the build and analyze those found. This requires external connectivity. The
results of the analysis are returned in the build results as part of the step for the task.
Demonstration Whitesource Bolt

To correctly interpret the results of scanning tools, you need to be aware of some aspects:
●● False positives
It is important to verify the findings to be real positives in terms of the scan results. The tooling is an
automated way to scan and might be misinterpreting certain vulnerabilities. In the triaging of the find-
ing in the scan results, you should be aware that some findings might not be correct. Such results are
called false positives, established by human interpretation and expertise. One must not declare
a result a false positive too easily. On the other hand, scan results are not guaranteed to be 100%
accurate.
●● Security bug bar
Most likely there will be many security vulnerabilities detected. Some of these false positives,
but still a lot of findings. Quite often there are more findings than can be handled or mitigated, given
a certain amount of time and money. In such cases it is important that there is a security bug bar, indi-
cating the level of vulnerabilities that must be fixed before the security risks are acceptable enough to
take the software into production. The bug bar makes sure that it is clear what must be taken care of,
and what might be done if there is time and resources left.
The WhiteSource Bolt tooling gives aggregated reporting that can be found under the Pipelines section.
It shows three different sections:
●● Security vulnerabilities
The results from the scan are usually distinguishing between various levels of severity. The severity is a
good candidate for establishing the bug bar. For example, the security bug bar could be set to not
allow any findings on High or Medium vulnerability level before releasing software to production.
●● License risks and compliancy
A list of license types that are used. The higher the risk level of the licenses in use that are identified,
the bigger chance of compliancy issues.
●● Outdated libraries
Libraries that are not using the latest version. Although these do not pose a security risk (yet), they
might cause maintenance problems and introduce other risks for the software that uses these librar-
ies, components and packages they come in.
The results of the scan tooling will be the basis for selecting what work remains to be done before
software is considered stable and done. By setting a security bug bar in the Definition of Done and
specifying the allowed license ratings, one can use the reports from the scans to find the work for the
development team.
Implement a versioning strategy

Introduction to versioning
Software changes over time. The requirements for the software do not stay the same. The functionality it
offers and how it is used will grow, change and adopt based on feedback. The hosting of an application
might evolve as well, with new operating systems, new frameworks and versions thereof. The original
implementation might contain flaws and bugs. Whatever reason for change, it is unlikely that software is
stable and doesn't need to change. Since the software you build takes dependencies on other compo-
nents, the same holds true for the components and packages you build or use while building your
software.
In order to keep track of which piece of software is currently being used, correct versioning becomes
essential to maintaining a codebase. Versioning is also relevant for dependency management, as it relates
to the versions of the packages and the components within. Each dependency is clearly identified by its
name and version. It allows keeping track of the exact packages being used. Each of the packages has its
own lifecycle and rate of change.
Immutable packages
As packages get new versions, your codebase can choose when to use a new version of the packages it
consumes. It does so by specifying the specific version of the package it requires. This implies that
packages themselves should always have a new version when they change. Whenever a package is
published to a feed it should not be allowed to change any more. If it were, it would be at the risk of
introducing potential breaking changes to the code. In essence, a published package is considered to be
immutable. Replacing or updating an existing version of a package is not allowed. Most of the package
feeds do not allow operations that would change an existing version. Regardless of the size of the change
a package can only be updated by the introduction of a new version. The new version should indicate the
type of change and impact it might have.
See also Key concepts for Azure Artifacts4.
Versioning of artifacts
It is proper software development practices to indicate changes to code with the introduction of an
increased version number. However small or large a change, it requires a new version. A component and
its package can have independent versions and versioning schemes.
The versioning scheme can differ per package type. Typically, it uses a scheme that can indicate the type
of change that is made. Most commonly this involves three types of changes:
●● Major change
Major indicates that the package and its contents have changed significantly. It often occurs at the
introduction of a complete new version of the package. This can be at a redesign of the component.
Major changes are not guaranteed to be compatible and usually have breaking changes from older
versions. Major changes might require a substantial amount of work to adopt the consuming code-
base to the new version.
●● Minor change
Minor indicates that the package and its contents have substantial changes made, but are a smaller
4 https://docs.microsoft.com/en-us/azure/devops/artifacts/artifacts-key-concepts#immutability
Implement a versioning strategy 273
increment than a major change. These changes can be backward compatible from the previous
version, although they are not guaranteed to be.
●● Patch
A patch or revision is used to indicate that a flaw, bug or malfunctioning part of the component has
been fixed. Normally, this is a backward compatible version compared to the previous version.
How artifacts are versioned technically varies per package type. Each type has its own way of indicating
the version in metadata. The corresponding package manager is able to inspect the version information.
The tooling can query the package feed for packages and the available versions.
Additionally, a package type might have its own conventions for versioning as well as a particular version-
ing scheme.
See also Publish to NuGet feeds5
Semantic versioning
One of the predominant ways of versioning is the use of semantic versionsing. It is not a standard per se,
but does offer a consistent way of expressing intent and semantics of a certain version. It describes a
version in terms of its backward compatibility to previous versions.
Semantic versioning uses a three part version number and an additional label. The version has the form
of Major.Minor.Patch, corresponding to the three types of changes covered in the previous section.
Examples of versions using the semantic versioning scheme are 1.0.0 and 3.7.129. These versions do
not have any labels.
For prerelease versions it is customary to use a label after the regular version number. A label is a textual
suffix separated by a hyphen from the rest of the version number. The label itself can be any text describ-
ing the nature of the prerelease. Examples of these are rc1, beta27 and alpha, forming version
numbers like 1.0.0-rc1 as a prerelease for the upcoming 1.0.0 version.
Prereleases are a common way to prepare for the release of the label-less version of the package. Early
adopters can take a dependency on a prerelease version to build using the new package. In general it is
not a good idea to use prerelease version of packages and their components for released software.
It is good to anticipate on the impact of the new components by creating a separate branch in the
codebase and use the prerelease version of the package. Changes are that there will be incompatible
changes from a prerelease to the final version.
See also Semantic Versioning 2.0.06.
Release views
When building packages from a pipeline, the package needs to have a version before the package can be
consumed and tested. Only after testing is the quality of the package known. Since package versions
cannot and should not be changed, it becomes challenging to choose a certain version beforehand.
Azure Artifacts recognizes a quality level of packages in its feeds and the difference between prerelease
and release versions. It offers different views on the list of packages and their versions, separating these
based on their quality level. It fits well with the use of semantic versioning of the packages for predictabil-
ity of the intent of a particular version, but is additional metadata from the Azure Artifacts feed called a
descriptor.
5 https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/nuget#package-versioning
6 https://semver.org/
Feeds in Azure Artifacts have three different views by default. These view are added at the moment a new
feed is created. The three views are:
●● Release
The @Release view contains all packages that are considered official releases.
●● Prerelease
The @Prerelease view contains all packages that have a label in their version number.
●● Local
The @Local view contains all release and prerelease packages as well as the packages downloaded
from upstream sources.
Using views
You can use views to offer help consumers of a package feed to filter between released and unreleased
versions of packages. Essentially, it allows a consumer to make a conscious decision to choose from
released packages, or opt-in to prereleases of a certain quality level.
By default the @Local view is used to offer the list of available packages. The format for this URI is:
https://pkgs.dev.azure.com/{yourteamproject}/_packaging/{feedname}/nuget/v3/index.json
When consuming a package feed by its URI endpoint, the address can have the requested view included.
For a specific view, the URI includes the name of the view, which changes to be:
https://pkgs.dev.azure.com/{yourteamproject}/_packaging/{feedname}@{Viewname}/nuget/v3/index.json
The tooling will show and use the packages from the specified view automatically.
Tooling may offer an option to select prerelease versions, such as shown in this Visual Studio 2017 NuGet
dialog. This does not relate or refer to the @Prerelease view of a feed. Instead, it relies on the presence
of prerelease labels of semantic versioning to include or exclude packages in the search results.
See also:
●● Views on Azure DevOps Services feeds7
●● Communicate package quality with prerelease and release views8
Promoting packages
Azure Artifacts has the notion of promoting packages to views as a means to indicate that a version is of
a certain quality level. By selectively promoting packages you can plan when packages have a certain
quality and are ready to be released and supported by the consumers.
You can promote packages to one of the available views as the quality indicator. The two views Release
and Prerelease might be sufficient, but you can create more views when you want finer grained quality
levels if necessary, such as alpha and beta.
Packages will always show in the Local view, but only in a particular view after being promoted to it.
Depending on the URL used to connect to the feed, the available packages will be listed.
7 https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/views
8 https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/views
Upstream sources will only be evaluated when using the @Local view of the feed. Views Afer they have
been downloaded and cached in the @Local view, you can see and resolve the packages in other views
after they have promoted to it.
It is up to you to decide how and when to promote packages to a specific view. This process can be
automated by using a Azure Pipelines task as part of the build pipeline.
Packages that have been promoted to a view will not be deleted based on the retention policies.
Demonstration Promoting a Package

Prerequisite: Have acces to an existing Azure DevOps project and the connected package feed from the
previous demo
Steps to demonstrate the views that exist on package

feeds in Azure Artifacts
1. Go to dev.azure.com and open your team project.
2. Open Artifacts and select the feed PartsUnlimited.Security.
3. Go to Settings and click Feed Settings.
4. Open the Views tab. By default there will be three views. Local: includes all packaages in the feed and
all cached from upstream sources. Prerelease and Release. In the Default view column is a check
behind Local. This is the default view that will always be used.
Steps to use the release view instead

1. Open Visual Studio and open NuGet Package Manager.
2. Click the settings wheel and check the source adress for the PartsUnlimited feed. If you want to use a
different view than the local view, you need to include that in the Source url of your feed, by adding
@Release.
3. Add @Release to the source url ../PartsUnlimited@Release/nuget/.. and click Update.
4. Refresh the Browse tab. You will see there are No packages found in the Release feed. Before any
packages will appear, you need to promote them.
Steps to promote packages to particular views

1. Go back to your feed in Azure Artifacts.
2. Click on the created Nuget Package PartsUnlimited.Security.
3. Click Promote.
4. Select the feed you want to use, in this case PartsUnlimited@Release and Promote.
5. Go back to the Overview. If we look again at our package in the feed, you will notice there is now a
Release tag associated with this particular package.
6. Go back to Visual Studio, NuGet Package Manager.
7. Refresh the Browse tab. You will see that your version is promoted to this view.
8. Select PartsUnlimited.Security and click Update and OK. The latest version of this package is now
used.
Best practices for versioning

There are a number of best practices to effectively use versions, views and promotion flow for your
versioning strategy. Here are a couple of suggestions:
●● Have a documented versioning strategy
●● Adopt SemVer 2.0 for your versioning scheme
●● Each repository should have a unique feed
●● When creating a package, also publish it to the unique feed
It is good to adopt a best practices yourself and share these in your development teams. It can be made
part of the Definition of Done for work items that relate to publishing and consuming packages from
feeds.
See also Best practices for using Azure Artifacts9.
Demonstration Pushing from the Pipeline

Prerequisite: In your Azure DevOps PartsUnlimited project, prepare two builds pipelines (used in previous
demos)
1. Build pipeline PartsUnlimited Security Package.
●● .NET Core build task (Restore, build, push)

●● enable CI trigger
2. Build pipeline PartsUnlimited E2E.
●● ASP.net web application type

●● NuGet restore task
Steps to build and push the Nuget package

1. Edit the build pipeline PartsUnlimited Security Package.
●● dotnet restore
●● dotnet build
●● dotnet push
●● Use the command nuget push and specify path **/*.nupkg

●● Select target feed PartsUnlimited
2. Start a new build and select agent pool.
The build has succeeded, but you will see the final step dotnet push fails. The reason for this failure can
be found in the log information.
3. Open the log information.
9 https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/best-practices
It shows the feed already contains the PartsUnlimited.Security 1.0.0. We go back to the Visual Studio
project to see what is happening.
4. Open the source code for the PartsUnlimited package in Visual Studio in a separate solution.
●● Open the Project Properties

●● Go to the package tab
Look at Package version, we see that the version is still 1.0.0. Packages are immutable. As soon as a
package is published to a feed there can never be another package with the exact same version. We need
to upgrade the version to a new one that uses the major, minor and the changed patch version.
5. Change the patch version: 1.0.1. Make a small edit to the code for illustrative purposes, and check in
the new code.
6. Change the exception type check in, commit and push the new code. We go back to the Azure
Devops pipeline. Since there is a trigger on the code we just changed, the build will automatically
start.
7. Go back to build pipeline for PartsUnlimited Security Package.
As you see the build is triggered and completed successfully. Including the push to the NuGet feed. Since
there was no version conflict, we were able to successfully push the new version to the feed.
8. Open Artifacts and show the feed.
Since there was a successful build for the entire web application, you can see that the PartsUnlimited feed
now also includes all the downloaded upstream packages from the NuGet.org source.
9. Scroll down and click on the PartsUnlimited.Security 1.0.1 package. By clicking on it we can inspect
the details and the versions.
10. Edit the build pipeline PartsUnlimited E2E.
11. Click NuGet restore.
There is a second pipeline that builds the complete web application. It is an ASP.net web application
build. The NuGet restore task is configured to also consume packages from the PartsUnlimited feed.
Because PartsUnlimited has an upstream source for NuGet.org we do not have to Use packaged from
NuGet.org explicitly. You can uncheck this box.
Lab
Manage Open Source Security and License with
WhiteSource
In this lab, Managing Open-source security and license with WhiteSource10, you will use WhiteSource
Bolt with Azure DevOps to automatically detect alerts on vulnerable open source components, outdated
libraries, and license compliance issues in your code. You will be using WebGoat, a deliberately insecure
web application, maintained by OWASP designed to teach web application security lessons. You will learn
how to:
●● Detect and remedy vulnerable open source components.
●● Generate comprehensive open source inventory reports per project or build.
●● Enforce open source license compliance, including dependencies’ licenses.
●● Identify outdated open source libraries with recommendations to update.
✔️ Note: You must have already completed the prerequisite labs in the Welcome section.
10 https://www.azuredevopslabs.com/labs/vstsextend/WhiteSource/

Suggested answer
What issues are often associated with the use of open source libraries?
Suggested answer
How can an open source library cause licensing issues if it is free to download?
Suggested answer
What is the minimum feed permission that will allow you to list available packages and to install them?
Suggested answer
What is open source software?
Suggested answer
How can you restrict which files are uploaded in a universal package feed?
Answers
What issues are often associated with the use of open source libraries?
Bugs, security vulnerabilities, and licensing issues
How can an open source library cause licensing issues if it is free to download?
Each library has usage restrictions as part of the licensing. These restrictions might not be compatible with
your intended application use.
What is the minimum feed permission that will allow you to list available packages and to install them?
Reader
What is open source software?
A type of software where users of code are permitted to study, change, and distribute the software. The open
source license type can limit the actions (such as sale provisions) that can be taken.
How can you restrict which files are uploaded in a universal package feed?
By using an .artifactignore file

Module 10 Design a Release Strategy
Module Overview
Module Overview
Welcome to this module about designing a release strategy. In this module, we will talk about Continu-
ous Delivery in general. In this introduction, we will cover the basics. I'll explain the concepts of Continu-
ous Delivery, Continuous Integration and Continuous Deployment and also the relation to DevOps, and
we will discuss why you would you need Continuous Delivery and Continuous Deployment. After that, we
will talk about releases and deployments and the differences between those two.
Once we have covered these general topics, we will talk about release strategies and artifact sources, and
walk through some considerations when choosing and defining those. We will also discuss the considera-
tions for setting up deployment stages and your delivery and deployment cadence, and lastly about
setting up your release approvals.
After that, we will cover some ground to create a high-quality release pipeline and talk about the quality
of your release process and the quality of a release and difference between those two. We will take a look
at how to visualize your release process quality and how to control your release using release gates as a
mechanism. Finally, we will look at how to deal with release notes and documentation.
After these introductions, we will take a brief look at deployment patterns. We will cover modern deploy-
ment patterns like canary releases, but we will also take a quick look at the traditional deployment
patterns, like DTAP environments.
Finally, we take a look at choosing the right release management tool. There are a lot of tools out there.
We will cover the components that you need to take a look at if you are going to choose the right release
management tool product or company.
Learning objectives
At the end of this module, students will be able to:
●● Differentiate between a release and a deployment
●● Define the components of a release pipeline
MCT USE ONLY. STUDENT USE PROHIBITED 282 Module 10 Design a Release Strategy
●● Explain things to consider when designing your release strategy

●● Classify a release versus a release process, and outline how to control the quality of both
●● Describe the principle of release gates and how to deal with release notes and documentation
●● Explain deployment patterns, both in the traditional sense and in the modern sense
●● Choose a release management tool
Introduction to Continuous Delivery 283
Introduction to Continuous Delivery

Traditional IT
We will talk about Continuous Delivery and why this is something you should consider.
We will first talk about Continuous Delivery in general. What is Continuous Delivery, what does it mean,
what problems does it solve, and why should you care?
A few years ago, IT was a facilitating department. IT was there to support the business users, and because
time had proven that developed software had bad quality by default, software changes were a risk. The
resolution for this “quality problem” was to keep changes under strict control. The department that
became responsible for controlling the changes became the IT(-Pro) department. In the past but also
today, the IT(-Pro) department is responsible for the stability of the systems, while the development
department is responsible for creating new value.
This split brings many companies in a difficult situation. Development departments are motivated to
deliver value as soon as possible to keep their customers happy. On the other hand, IT is motivated to
change nothing, because change is a risk and they are responsible for eliminating the risks and keeping
everything stable. And what do we get out of this? Long release cycles.
Silo-Based Development
Long release cycles, a lot of testing, code freezes, night and weekend work and a lot of people involved,
ensure that everything works. But the more we change, the more risk it entails, and we are back at the
beginning. On many occasions resulting in yet another document or process that should be followed.
This is what I call silo-based development.
If we look at this picture of a traditional, silo-based value stream, we see Bugs and Unplanned work,
necessary updates or support work and planned (value adding) work, all added to the backlog of the
teams. When everything is planned and the first “gate” can be opened, everything drops to the next
phase. All the work, and thus all the value moves in piles to the next phase. It moves from Plan phase to a
Realize phase where all the work is developed, tested and documented, and from here, it moves to the
release phase. All the value is released at the same time. As a result, the release takes a long time.
Moving to Continuous Delivery

But times have changed, and we need to deal with a new normal. Our customers demand working
software, and they wanted it yesterday. If we cannot deliver, they go to a competitor. And competition is
fierce. With the internet, we always have global competition. With competitors on our whole stack but
also with competitors that deliver a best of breed tool for one aspect of the software we built. We need
to deliver fast, and the product we make must be good. And we should do this with our software produc-
tion being cheap and quality being high. To achieve this, we need something like Continuous Delivery.
We need to move towards a situation where the value is not piled up and released all at once, but where
value flows through a pipeline. Just like in the picture, a piece of work is a marble. And only one piece of
work can flow through the pipeline at once. So work has to be prioritized in the right way. As you can see
the pipeline has green and red outlets. These are the feedback loops or quality gates that we want to
have in place.
A feedback loop can be different things:
●● A unit test to validate the code
●● An automated build to validate the sources
●● An automated test on a Test environment
●● Some monitor on a server
●● Usage instrumentation in the code
If one of the feedback loops is red, the marble cannot pass the outlet and it will end up in the Monitor
and Learn tray. This is where the learning happens. The problem is analyzed and solved so that the next
time a marble passes the outlet, it is green.
Every single piece of work flows through the pipeline until it ends up in the tray of value. The more that is
automated the faster value flows through the pipeline.
Companies want to move toward Continuous Delivery. They see the value. They hear their customers.
Companies want to deliver their products as fast as possible. Quality should be higher. The move to
production should be faster. Technical Debt should be lower.
A great way to improve your software development practices was the introduction of Agile and Scrum.
Last year around 80% of all companies claimed that they adopted Scrum as a software development
practice. By using Scrum, many teams can produce a working piece of software after a sprint of maybe 2
or 3 weeks. But producing working software is not the same as delivering working software. The result is
that all “done” increments are waiting to be delivered in the next release, which is coming in a few
months.
What we see now, is that Agile teams within a non-agile company are stuck in a delivery funnel. The
bottleneck is no longer the production of working software, but the problem has become the delivery of
working software. The finished product is waiting to be delivered to the customers to get business value,
but this does not happen. Continuous Delivery needs to solve this problem.
What is Continuous Delivery?

Now that we know a bit more about the necessity to move towards Continuous Delivery, it is good to
spend some time on the definition of Continuous Delivery and how this relates to DevOps.
Continuous Delivery (CD) is a set of processes, tools and techniques for the rapid, reliable and continuous
development and delivery of software.
This means that Continuous Delivery goes beyond the release of software through a pipeline. The
pipeline is a crucial component and also the main focus of this course, but Continuous Delivery is more.
To explain this a bit more, look at the eight principles of Continuous Delivery:
1. The process for releasing/deploying software must be repeatable and reliable.
2. Automate everything!
3. If something is difficult or painful, do it more often.
4. Keep everything in source control.
5. Done means “released.”
6. Build quality in!
7. Everybody has responsibility for the release process.
8. Improve continuously.
If we want to fulfill these 8 principles, we can see that an automated pipeline does not suffice. In order to
deploy more often, we need to reconsider our software architecture (monoliths are hard to deploy), our
testing strategy (manual tests do not scale very well), our organization (separated business and IT
departments do not work smoothly), and so forth.
This course will focus on the release management part of Continuous Delivery, but be aware of the other
changes you might encounter. Find the next bottleneck in your process, solve it and learn from it, and
repeat this forever.
How does this all relate to DevOps? If we look at the definition of DevOps from Donovan Brown:
"DevOps is the union of people, process, and products to enable Continuous Delivery of value to our end
users."
Looking at this definition, Continuous Delivery is an enabler for DevOps. DevOps focuses on organiza-
tions and bringing people together to Build and Run their software products.
Continuous Delivery is a practice. Being able to deliver software on-demand. Not necessarily a 1000 times
a day. Deploying every code change to production is what we call Continuous Deployment.
To be able to do this we need automation, we need a strategy, and we need pipelines. And this is what
we will cover in the rest of this module.
Releases and Deployments

One of the essential steps in moving software more quickly to production is by changing the way we
deliver the software to production. In our industry, it is widespread that we have teams that need to do
overtime in the weekend to install and release new software. This is mainly caused by the fact that we
have two parts of the release process bolted together. The moment we deploy the new software, we also
release new features to the end users.
The best way to move your software to production safely while maintaining stability is by separating
these two concerns. So we separate deployments from our release. This can also be phrased as separat-
ing your functional release from your technical release (deployment).
What is a release and what is a deployment

When we talk about releases and deployments, we see that commonly used tools deal a bit differently
with the terminology as we did in the previous chapter. To make sure you both understand the concepts
and the technical implementation in many tools, you need to know how tool vendors define the differ-
ence between a release and a deployment.
A release is a package or container that holds a versioned set of artifacts specified in a release pipeline in
your CI/CD process. It includes a snapshot of all the information required to carry out all the tasks and
actions in the release pipeline, such as the stages (or environments), the tasks for each one, the values of
task parameters and variables, and the release policies such as triggers, approvers, and release queuing
options. There can be multiple releases from one release pipeline (or release process).
Deployment is the action of running the tasks for one stage, which results in a tested and deployed
application, and other additional activities that are specified for that stage. Initiating a release starts each
deployment based on the settings and policies defined in the original release pipeline. There can be
multiple deployments of each release even for one stage. When a deployment of a release fails for a
stage, you can redeploy the same release to that stage.
See also Releases in Azure Pipelines1.
Separating technical and functional release

When we want to get started with separating the technical and functional release, we need to start with
our software itself. The software needs to be built in such a way that new functionality or features can be
hidden from end-users while it is running.
A common way to do this, is the use of Feature Toggles. The simplest form of a Feature Toggle is an if
statement that either executes or does not execute a certain piece of code. By making the if-statement
1 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/releases?view=vsts
configurable you can implement the Feature Toggle. We will talk about Feature Toggles in Module 3 in
more detail.
See also: Explore how to progressively expose your features in production for some or all users2.
Once we have prepared our software, we need to make sure that the installation will not expose any new
or changed functionality to the end user.
When the software has been deployed, we need to watch how the system behaves. Does it act the same
as it did in the past?
If it is clear that the system is stable and operates the same as it did before, we can decide to flip a switch.
This might reveal one or more features to the end user, or change a set of routines that are part of the
system.
The whole idea of separating deployment from release (exposing features with a switch) is compelling
and something we want to incorporate in our Continuous Delivery practice. It helps us with more stable
releases and better ways to roll back when we run into issues when we have a new feature that produces
problems.
We switch it off again and then create a hotfix. By separating deployment from the release of a feature,
you create the opportunity to deploy any time of the day, since the new software will not affect the
system that already works.
Discussion
What are your bottlenecks?
Have a discussion about the need for Continuous Delivery in your organization and what blocks the
implementation.
Topics you might want to discuss are:
●● Does your organization need Continuous Delivery?
●● Do you use Agile/Scrum?
●● Is everybody involved or only the Dev departments?

●● Can you deploy your application multiple times per day? Why or why not?
●● What is the main bottleneck for Continuous Delivery in your organization?
●● The Organization
●● Application Architecture
●● Skills
●● Tooling
●● Tests
●● other things?
2 https://docs.microsoft.com/en-us/azure/devops/articles/phase-features-with-feature-flags?view=vsts
Release strategy recommendations

Introduction and Overview
Different components make up a release pipeline. In short, a release pipeline takes an artifact and moves
this artifact through different stages, so it can eventually be installed on a production environment.
Let us quickly walk through all the components step by step.

The first component in a release pipeline is an artifact. Artifacts can come from different sources. The
most common source is a package from a build pipeline. Another commonly seen artifact source is for
example source control. Furthermore, a release pipeline has a trigger: the mechanism that starts a new
release.
A trigger can be:
●● A manual trigger, where people start to release by hand
●● A scheduled trigger, where a release is triggered based on a specific time, or
●● A continuous deployment trigger, where another event triggers a release. For example, a completed
build.
Another vital component of a release pipeline are stages or sometimes called environments. This is where
the artifact will be eventually installed. For example, the artifact contains the compiled website, and this
will be installed on the web server or somewhere in the cloud. You can have many stages (environments),
and part of the release strategy is to find out what the appropriate combination of stages is.
Another component of a release pipeline is approval. In many cases, people want to sign off a release
before it is installed on the environment. In more mature organizations, this manual approval process can
be replaced by an automatic process that checks the quality before the components move on to the next
stage.
Finally, we have the tasks within the various stages. The tasks are the steps that need to be executed to
install, configure, and validate the installed artifact.
Release strategy recommendations 289
In this part of the module, we will walk through all the components of the release pipeline in detail and
talk about what to consider for each component.
The components that make up the release pipeline or process are used to create a release. There is a
difference between a release and the release pipeline or process.
The release pipeline is the blueprint through which releases are done. We will cover more of this when
discussing the quality of releases and releases processes.
See also Release pipelines3.
Artifacts and Artifact sources

What is an artifact? An artifact is a deployable component of your application. These components can
then be deployed to one or more environments. In general, the idea about build and release pipelines
and Continuous Delivery is to build once and deploy many times. This means that an artifact will be
deployed to multiple environments. To achieve this, this implies that the artifact is a stable package. The
only thing that you want to change when you deploy an artifact to a new environment is the configura-
tion. The contents of the package should never change. This is what we call immutability4. We should be
100% sure that the package that what we build, the artifact, remains unchanged.
How do we get an artifact? There are different ways to create and retrieve artifacts, and not every method
is appropriate for every situation.
The most common and most used way to get an artifact within the release pipeline is to use a build
artifact. The build pipeline compiles, tests, and eventually produces an immutable package, which is
stored in a secure place (storage account, database etc.).
The release pipeline then uses a secure connection to this secured place to get the build artifact and
perform additional actions to deploy this to an environment. The big advantage of using a build artifact is
3 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/?view=vsts
4 https://docs.microsoft.com/en-us/azure/devops/artifacts/artifacts-key-concepts?view=vsts
that the build produces a versioned artifact. The artifact is linked to the build and gives us automatic
traceability. We can always find the sources that produced this artifact.
Another possible artifact source is version control. We can directly link our version control to our release
pipeline. The release is then related to a specific commit in our version control system. With that, we can
also see which version of a file or script is eventually installed. In this case, the version does not come
from the build, but from version control. A consideration for choosing a version control artifact instead of
a build artifact can be that you only want to deploy one specific file. If no additional actions are required
before this file is used in the release pipeline, it does not make sense to create a versioned package
containing one that file. Helper scripts that perform actions to support the release process (clean up,
rename, string actions) are typically good candidates to get from version control.
Another possibility of an artifact source can be a network share containing a set of files. However, you
should be aware of the possible risk. The risk is that you are not 100% sure that the package that you are
going to deploy is the same package that was put on the network share. If other people can access the
network share as well, the package might be compromised. For that reason, this option will not be
sufficient to prove integrity in a regulated environment (banks, insurance companies).
Last but not least, container registries are a rising star when it comes to artifact sources. Container
registries are versioned repositories where container artifacts are stored. By pushing a versioned contain-
er to the content repository, and consuming that same version within the release pipeline, it has more or
less have the same advantages as using a build artifact stored in a safe location.
Considerations for choosing the right artifact

source
When you use a release pipeline to deploy your packages to production you need to have some tracea-
bility. That means you want to know where the package that you are deploying originates from. It is
essential to understand that the sources that you built and checked into your version control are precisely
the same as the sources that you are going to deploy to the various environments that are going to be
used by your customers. Primarily when you work in a regulated environment like a bank or an insurance
company, auditors ask you to provide traceability to sources that you deployed to prove the integrity of
the package.
Another crucial aspect of your artifacts is auditability. You need to know who changed that line of code
and who triggered the build that produces the artifact that is being deployed.
A useful mechanism to make sure you can provide the right traceability and auditability is using immuta-
ble packages. That is not something that you can buy, but something that you need to implement
yourself. By using a build pipeline that produces a package which is stored in a location that cannot be
accessed by humans, you ensure the sources are unchanged throughout the whole release process. This
is an essential concept of release pipelines.
You identify an immutable package by giving it a version so that you can refer to it in a later stage.
Versioning strategy is a complex concept and is not in the scope of this module, but by having a unique
identification number or label attached to the package, and making sure that this number or label cannot
be changed or modified afterwards, you ensure traceability and auditability from source code to produc-
tion.
Read more about Semantic Versioning5.
5 https://semver.org/
Choosing the right artifact source is tightly related to the requirements you have regarding traceability
and auditability. If you need an immutable package (containing multiple files) that can never be changed
and be traced, a build artifact is the best choice. If it is one file, you can directly link to source control.
You can also point at a disk or network share, but this implies some risk concerning auditability and
immutability. Can you ensure the package never changed?
See also Release artifacts and artifact sources6.
Demonstration Selecting an Artifact Source

In this demonstration, you will investigate Artifact Sources.
Note: Before starting this demonstration, make sure you have performed the steps in the prerequisites
section.
Steps
Let's take a look at how to work with one or more artifact sources in the release pipeline.
1. In the Azure DevOps environment, open the Parts Unlimited project, then from the main menu, click
Pipelines, then click Releases.
2. In the main screen area, click New pipeline.
6 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=vsts
3. In the Select a template pane, note the available templates, but then click the Empty job option at
the top. This is because we are going to focus on selecting an artifact source.
4. In the Artifacts section, click +Add an artifact.
5. Note the available options in the Add an artifact pane, and click the option to see more artifact
types, so that you can see all the available artifact types:
While we're in this section, let's briefly look at the available options.
6. Click Build and note the parameters required. This option is used to retrieve artifacts from an Azure
DevOps Build pipeline. Using it requires a project name, and a build pipeline name. (Note that
projects can have multiple build pipelines). This is the option that we will use shortly.
7. Click Azure Repository and note the parameters required. It requires a project name and also asks
you to select the source repository.
8. Click GitHub and note the parameters required. The Service is a connection to the GitHub repository.
It can be authorized by either OAuth or by using a GitHub personal access token. You also need to
select the source repository.
9. Click TFVC and note the parameters required. It also requires a project name and also asks you to
select the source repository.
Note: A release pipeline can have more than one set of artifacts as input. A common example is a situation
where as well as your project source, you also need to consume a package from a feed.
10. Click Azure Artifacts and note the parameters required. It requires you to identify the feed, package
type, and package.
11. Click GitHub Release and note the parameters required. It requires a service connection and the
source repository.
Note: we will discuss service connections later in the course.

12. Click Azure Container Registry and note the parameters required. Again, this requires a secure
service connection, along with details of the Azure Resource Group that the container registry is
located in. This allows you to provide all your Docker containers directly into your release pipeline.
13. Click Docker Hub and note the parameters required. This option would be useful if your containers
are stored in Docker Hub rather than in an Azure Container Registry. After choosing a secure service
connection, you need to select the namespace and the repository
14. Last but not least, click Jenkins and note the parameters required. You do not need to get all your
artifacts from Azure. You can retrieve them from a Jenkins build. So if you have a Jenkins Server in
your infrastructure, you can use the build artifacts from there, directly in your Azure DevOps pipelines.
Configuring the Build Artifact

Let's return to adding our Build output as the artifact source.
15. Click the Build source type again. Note that the Project should show the current project. From the
Source (build pipeline) drop down list, select Parts Unlimited-ASP.NET-CI. Take note of the default
values for the other options, and then click Add.
We have now added the artifacts that we will need for later walkthroughs.
16. To save the work, click Save, then in the Save dialog box, click OK.
Deployment Stages
A stage or deployment stage is a logical and independent entity that represents where you want to
deploy a release generated from a release pipeline. Sometimes a stage is called an environment. For
example Test or Production. But it does not neccesarily reflect the lifecycle of a product. It can represent
any physical or real stage that you need. For example, the deployment in a stage may be to a collection
of servers, a cloud, or multiple clouds. In fact, you can even use a stage to represent shipping the soft-
ware to an app store, or the manufacturing process of a boxed product, or a way to group a cohort of
users for a specific version of an application.
You must be able to deploy to a stage independently of other stages in the pipeline. There should be no
dependency between stages in your pipeline. For example, your pipeline might consist of two stages A
and B, and your pipeline could deploy Release 2 to A and Release 1 to B. If you make any assumptions in
B about the existence of a certain release in A, the two stages are not independent.
Here are some suggestions and examples for stages:
●● Dev, QA, Prod - As new builds are produced, they can be deployed to Dev. They can then be promot-
ed to QA, and finally to Prod. At any time, each of these stages may have a different release (set of
build artifacts) deployed to them. This is a good example of the use of stages in a release pipeline.
●● Customer adoption rings (for example, early adopter ring, frequent adopter ring, late adopter ring)
- You typically want to deploy new or beta releases to your early adopters more often than to other
users. Therefore, you are likely to have different releases in each of these rings. This is a good example
of the use of stages in a pipeline.
●● Database and web tiers of an application - These should be modeled as a single stage because you
want the two to be in sync. If you model these as separate stages, you risk deploying one build to the
database stage and a different build to the web tier stage.
●● Staging and production slots of a web site - There is clearly an interdependence between these two
slots. You do not want the production slot to be deployed independently of the build version currently
deployed to the staging slot. Therefore, you must model the deployment to both the staging and
production slots as a single stage.
●● Multiple geographic sites with the same application - In this example, you want to deploy your
website to many geographically distributed sites around the globe and you want all of them to be the
same version. You want to deploy the new version of your application to a staging slot in all the sites,
test it, and - if all of them pass - swap all the staging slots to production slots. In this case, given the
interdependence between the sites, you cannot model each site as a different stage. Instead, you
must model this as a single stage with parallel deployment to multiple sites (typically by using jobs).
●● Multiple test stages to test the same application - Having one or more release pipelines, each with
multiple stages intended to run test automation for a build, is a common practice. This is fine if each
of the stages deploys the build independently, and then runs tests. However, if you set up the first
stage to deploy the build, and subsequent stages to test the same shared deployment, you risk
overriding the shared stage with a newer build while testing of the previous builds is still in progress.
Considerations for setting up Deployment Stag-

es
Now that we know what stage is and have some idea of what is commonly used as a stage, we need to
review a few considerations around choosing the right stages. In most cases, organizations prefer the
traditional approach when it comes to setting up the staging strategy. With the traditional method, you
can think of setting up an environment for Dev, for Test, and Production. On many occasions, there is even
an additional stage, Staging or Acceptance.
Even when companies use a cloud strategy, they still apply the general sense of environments. When
applications are deployed to a cloud instead of a server in a data centre, you have the possibility to
rethink your strategy around stages. For example, a stage is not necessarily a long-lived entity. When we
talk about Continuous Delivery, where we might deploy our application multiple times a day, we may
assume that the application is also tested every time the application is deployed. The question that we
need to ask ourselves is, do we want to test in an environment that is already in use, or do we want a
testing environment that is clean from the start?
On many occasions both scenarios are valid. Sometimes you want to start from scratch, and sometimes
you want to know what happens if you refresh the environment. In a DevOps world, we see infrastructure
as just another piece of software (Infrastructure as Code). Using Cloud technology combined with
Infrastructure as Code gives us new possibilities when it comes to environments. We are not limited to a
fixed number of environments anymore. Instead, we can spin up environments on demand. When we
want to test something, we spin up a new environment, deploy our code and run our tests. When we are
done, we can clean up the environment. Traditional labels for environments, therefore, do not apply
anymore. Let's take Test as an example. Maybe we have different test environments, one for load testing,
one for integration testing, one for system testing and one for functional testing. The sky is the limit!
Depending on the needs of the organization and the DevOps teams, the number of stages and the
purpose of stages vary. Some organizations stick to the DTAP (Dev, Test, Acceptance, Production) where
others deploy directly to production with temporary stages in between.
Important things to consider are there for
●● Is your stage long lived or short lived?
●● What is the purpose of this specific stage?
●● Who is going to use it?
●● Is your target application overwriting an existing one would always be a fresh install?
●● Do you need a new stage for bug fixes?
●● Do you need an isolated environment with encrypted data or disconnected from a network?
●● Can you afford downtime?
●● Who is the owner of the stage? Who can apply changes?
These and maybe other considerations need to play a crucial role in defining the number of stages and
the purpose of stages.
Everything you need to know about Deployment stages in combination with Azure DevOps you can find
on the Microsoft Docs7
Discussion
What deployment stages would you define for your or-
ganization?
Have a discussion about what deployment stages you recognise in your organization?
Consider the following things:
●● Is your stage long lived or short lived?
●● What is the purpose of this specific stage?
●● Who is going to use it?
7 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/environments?view=vsts
●● Is your target application overwriting an existing one would always be a fresh install?
●● Do you need a new stage for bug fixes?
●● Do you need an isolated environment with encrypted data or disconnected from a network?
●● Can you afford downtime?
●● Who is the owner of the stage? Who can apply changes?
Demonstration Setting Up Stages

In this demonstration, you will investigate Stages.
Note: Before starting this walkthrough, make sure you have performed the steps in the prerequisites section
and the previous walkthrough.
Steps
Let's now take a look at the other section in the release pipeline that we have created: Stages.
1. Click on Stage 1 and in the Stage properties pane, set Stage name to Development and close the
pane.
Note: stages can be based on templates. For example, you might be deploying a web application using
node.js or Python. For this walkthrough, that won't matter because we are just focussing on defining a
strategy.
2. To add a second stage, click +Add in the Stages section and note the available options. You have a
choice to create a new stage, or to clone an existing stage. Cloning a stage can be very helpful in
minimizing the number of parameters that need to be configured. But for now, just click New stage.
3. When the Select a template pane appears, scroll down to see the available templates. For now, we
don't need any of these, so just click Empty job at the top, then in the Stage properties pane, set
Stage name to Test, then close the pane.
4. Hover over the Test stage and notice that two icons appear below. These are the same options that
were available in the menu drop down that we used before. Click the Clone icon to clone the stage to
a new stage.
5. Click on the Copy of Test stage and in the stage properties pane, set Stage name to Production and
close the pane.
We have now defined a very traditional deployment strategy. Each of the stages contains a set of tasks,
and we will look at those tasks later in the course.
*Note: The same artifact sources move through each of the stages.
The lightning bolt icon on each stage shows that we can set a trigger as a predeployment condition. The
person icon on both ends of a stage, show that we can have pre and post deployment approvers.
Concurrent stages
You'll notice that at present we have all the stages one after each other in a sequence. It is also possible
to have concurrent stages. Let's see an example.
6. Click the Test stage, and on the stage properties pane, set Stage name to Test Team A and close the
pane.
7. Hover over the Test Team A stage, and click the Clone icon that appears, to create a new cloned
stage.
8. Click the Copy of Test Team A stage, and on the stage properties pane, set Stage name to Test
Team B and close the pane.
9. Click the Pre-deployment conditions icon (i.e. the lightning bolt) on Test Team B to open the
pre-deployment settings.
10. In the Pre-deployment conditions pane, note that the stage can be triggered in three different ways:
The stage can immediately follow Release. (That is how the Development stage is currently configured). It
can require manual triggering. Or, more commonly, it can follow another stage. At present, it is following
Test Team A but that's not what we want.
11. From the Stages drop down list, chose Development and uncheck Test Team A, then close the pane.
We now have two concurrent Test stages.
Stage vs Environment
You may have wondered why these items are called Stages and not Environments.
In the current configuration, we are in fact using them for different environments. But this is not always
the case. Here is a deployment strategy based upon regions instead:
Azure DevOps pipelines are very configurable and support a wide variety of deployment strategies. The
name Stages is a better fit than Environment even though the stages can be used for environments.
For now, let's give the pipeline a better name and save the work.
12. At the top of the screen, hover over the New release pipeline name and when a pencil appears, click
it to edit the name. Type Release to all environments as the name and hit enter or click elsewhere on
the screen.
13. For now, save the environment based release pipeline that you have created by clicking Save, then in
the Save dialog box, click OK.
Delivery and Deployment Cadence, Schedules

and Triggers
When you have a clear view of your different stages, you need to think about when you want to deploy
to these stages. Then there is a difference between a release and a deployment, as we discussed earlier.
The moment you create the release (the package that holds a versioned set of artifacts), can differ from
the moment you deploy to an environment.
But both the release and stages make use of triggers. There are three types of triggers we recognize.
Continuous deployment Trigger

You can set up this trigger on your release pipeline. Once you do that, every time a build completes, your
release pipeline will trigger, and a new release will be created.
Scheduled Triggers
This speaks for itself, but what it allows you to, is to set up time-based manner to start a new release. For
example every night at 3:00 AM or at 12:00 PM. You can have one or multiple schedules per day, but it
will always run on this specific time.
Manual trigger
With a manual trigger, a person or system triggers the release based on a specific event. When it is a
person, it probably uses some UI to start a new release. When it is an automated process most likely,
some event will occur, and by using the automation engine, which is usually part of the release manage-
ment tool, you can trigger the release from another system.
As we mentioned in the introduction, Continuous Delivery is not only about deploying multiple times a
day, it is about being able to deploy on demand. When we define our cadence, questions that we should
ask ourselves are:
●● Do we want to deploy our application?
●● Do we want to deploy multiple times a day
●● Can we deploy to a stage? Is it used?
For example, when a tester is testing an application during the day might not want to deploy a new
version of the app during the test phase.
Another example, when your application incurs downtime, you do not want to deploy when users are
using the application.
The frequency of deployment, or cadence, differs from stage to stage. A typical scenario that we often
see is that continuous deployment happens to the development stage. Every new change ends up there
once it is completed and builds. Deploying to the next phase does not always occur multiple times a day
but only during the night.
When you are designing your release strategy, choose your triggers carefully and think about the re-
quired release cadence.
Some things we need to take into consideration are
●● What is your target environment?
●● Is it used by one team or is it used by multiple teams?
●● If a single team uses it, you can deploy frequently. Otherwise, you need to be a bit more careful.
●● Who are the users? Do they want a new version multiple times a day?
●● How long does it take to deploy?
●● Is there downtime? What happens to performance? Are users impacted?
Some tools make a difference between a release and deployment. This is what we talked about in the
introduction. You have to realise that a Trigger for the release pipeline only creates a new release. In most
cases, you also need to set up triggers for the various stages as well to start deployments. For example,
you can set up an automatic deployment to the first stage after the creation of a release. And, after that,
when the deployment to the first stage is successful, start the deployment to the next stage(s).
For more information, see also:
●● Release triggers8
●● Stage Triggers9
Demonstration Selecting Delivery and Deploy-

ment Cadence
In this demonstration, you will investigate Delivery Cadence.
✔️ Note: Before starting this walkthrough, make sure you have performed the steps in the prerequisites
section and the previous walkthroughs.
Steps
Let's now take a look at when our release pipeline is used to create deployments. Mostly, this will involve
the use of triggers.
When we refer to a deployment, we are referring to each individual stage, and each stage can have its
own set of triggers that determine when the deployment occurs.
1. Click the lightning bolt on the _Parts Unlimited-ASP.NET-CI artifact.
8 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=vsts
9 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=vsts#env-triggers
2. In the Continuous deployment trigger pane, click the Disabled option to enable continuous deploy-
ment. It will then say Enabled.
Once this is selected, every time that a build completes, a deployment of the release pipeline will start.
✔️ Note: You can filter which branches affect this, so for example you could choose the master branch or
a particular feature branch.
Scheduled Deployments
You might not want to have a deployment commence every time a build completes. That might be very
disruptive to testers downstream if it was happening too often. Instead, it might make sense to set up a
deployment schedule.
3. Click on the Scheduled release trigger icon to open its settings.
4. In the Scheduled release trigger pane, click the Disabled option to enable scheduled release. It will
then say Enabled and additional options will appear.
You can see in the screenshot above that a deployment using the release pipeline would now occur each
weekday at 3AM. This might be convenient when you for example, share a stage with testers who work
during the day. You don't want to constantly deploy new versions to that stage while they're working.
This setting would create a clean fresh environment for them at 3AM each weekday.
✔️ Note: The default timezone is UTC. You can change this to suit your local timezone as this might be
easier to work with when creating schedules.
5. For now, we don't need a scheduled deployment, so click the Enabled button again to disable the
scheduled release trigger and close the pane.
Pre-deployment Triggers
6. Click the lightning bolt on the Development stage to open the pre-deployment conditions.
✔️ Note: Both artifact filters and a schedule can be set at the pre-deployment for each stage rather than
just at the artifact configuration level.
Deployment to any stage doesn't happen automatically unless you have chosen to allow that.
Considerations for Release Approvals

In this part, we will talk about release approvals and release gates.
First, we take a look at manual approvals. This does not always resonate well when we talk about Contin-
uous Delivery, because Continuous Delivery implies that you deliver multiple times a day.
As we have described in the introduction, Continuous Delivery is all about delivering on demand. But, as
we discussed in the differences between release and deployment, delivery, or deployment, is only the
technical part of the Continuous Delivery process. It is all about how you are technically able to install the
software on an environment, but it does not say anything about the process that needs to be in place for
a release.
Release approvals are not to control how, but control if you want to deliver multiple times a day.
Manual approvals also suit a significant need. Organizations that start with Continous Delivery often lack
a certain amount of trust. They do not dare to release without a manual approval. After a while, when
they find that the approval does not add any value and the release always succeeds, the manual approval
is often replaced by an automatic check.
Things to consider when you are setting up a release approval are:

●● What do we want to achieve with the approval?
Is it an approval that we need for compliance reasons? For example. We need to adhere to the
four-eyes principal to get out SOX compliance. Or, Is it an approval that we need to manage our
dependencies. Or, is it an approval that needs to be in place purely because we need a sign off from
an authority like Security Officers or Product Owners.
●● Who needs to approve?
We need to know who needs to approve the release. Is it a product owner, Security officer, or just
someone that is not the one that wrote the code. This is important because the approver is part of the
process. He is the one that can delay the process if not available. So be aware that.
●● When do you want to approve?
Another essential thing to consider is when to approve. This is a direct relationship with what happens
after approval. Can you continue without approval? Or, is everything on hold until approval is given.
By using scheduled deployments, you can separate approval from deployment.
Although manual approval is a great mechanism to control the release, it is not always useful. On many
occasions, the check can be done in an earlier stage. For example, approving a change that has been
made in Source Control.
Scheduled deployments already solve the dependency issue. You do not have to wait for a person in the
middle of the night. But there is still a manual action involved. If you want to eliminate manual activities
altogether, but still want to have control you start talking about automatic approvals or release gates.
Example:
In many organizations, there are so-called dependency meetings. This is a planning session where the
release schedule of dependent components is discussed. Think of downtime of a database server or an
update of an API. This takes a lot of time an effort, and the only thing that is needed is a signal if the
release can proceed. Instead of having this meeting you can also create a mechanism where people press
a button on a form when the release cannot advance. When the release starts, it checks the state of the
gate by calling an API. If the “gate” is open, we can continue. Otherwise, we stop the release.
By using scripts and API's, you can create your own release gates instead of a manual approval. Or at
least extending your manual approval. Other scenarios for automatic approvals are for example.
●● Incident and issues management. Ensure the required status for work items, incidents, and issues. For
example, ensure that deployment only occurs if no bugs exist.
●● Notify users such as legal approval departments, auditors, or IT managers about a deployment by
integrating with approval collaboration systems such as Microsoft Teams or Slack, and waiting for the
approval to complete.
●● Quality validation. Query metrics from tests on the build artifacts such as pass rate or code coverage
and only deploy if they are within required thresholds.
●● Security scan on artifacts. Ensure security scans such as anti-virus checking, code signing, and policy
checking for build artifacts have completed. A gate might initiate the scan and wait for it to complete,
or check for completion.
●● User experience relative to baseline. Using product telemetry, ensure the user experience hasn't
regressed from the baseline state. The experience level before the deployment could be considered a
baseline.
●● Change management. Wait for change management procedures in a system such as ServiceNow com-
plete before the deployment occurs.
●● Infrastructure health. Execute monitoring and validate the infrastructure against compliance rules after
deployment, or wait for proper resource utilisation and a positive security report.
In short, approvals and gates give you additional control over the start and completion of the deploy-
ment pipeline. They can usually be set up as a pre-deployment and post-deployment condition, that can
include waiting for users to approve or reject deployments manually, and checking with other automated
systems until specific requirements are verified. In addition, you can configure a manual intervention to
pause the deployment pipeline and prompt users to carry out manual tasks, then resume or reject the
deployment.
To find out more about Release Approvals and Gates, check these documents.
●● Release approvals and gates overview10
●● Release Approvals11
●● Release Gates12
Demonstration Setting Up Manual Approvals

In this demonstration, you will investigate Manual Approval.
Note: Before starting this demonstration, make sure you have performed the steps in the prerequisites
section and the previous walkthroughs.
Steps
Let's now take a look at when our release pipeline needs manual approval before deployment of a stage
starts, or manual approval that the deployment of a stage completed as expected.
While DevOps is all about automation, manual approvals are still very useful. There are many scenarios
where they are needed. For example, a product owner might want to sign off a release before it moves to
production. Or the scrum team wans to make sure that no new software is deployed to the test environ-
ment before someone signs off on it, because they might need to find an appropriate time if it's con-
stantly in use.
This can help to gain trust in the DevOps processes within the business.
Even if the process will later be automated, people might still want to have a level of manual control until
they become comfortable with the processes. Explicit manual approvals can be a great way to achieve
that.
Let's try one.
1. Click the pre-deployment conditions icon for the Development stage to open the settings.
10 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/approvals?view=vsts
11 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/approvals?view=vsts
12 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates?view=vsts
2. Click the Disabled button in the Pre-deployment approvals section to enable it.
3. In the Approvers list, find your own name and select it. Then set the Timeout to 1 Days.
Note: Approvers is a list, not just a single value. If you add more than one person in the list, you can also
choose if they need to approve in sequence, or if either or both approvals are needed.
4. Take note of the approver policy options that are available:
It is very common to not allow a user who requests a release or deployment to also approve it. In this
case, we are the only approver so we will leave that unchecked.
5. Close the Pre-deployment conditions pane and notice that a checkmark has appeared beside the
person in the icon.
Test the Approval

Now it's time to see what happens when an approval is required.
6. Click Save to save the work, and OK on the popup window.
7. Click Create release to start the release process.
8. In the Create a new release pane, note the available options, then click Create.
9. In the upper left of the screen, you can see that a release has been created.
10. At this point, an email should have been received, indicating that an approval is required.
At this point, you could just click the link in the email, but instead, we'll navigate within Azure DevOps to
see what's needed.
11. Click on the Release 1 Created link (or whatever number it is for you) in the area we looked at in Step
9 above. We are then taken to a screen that shows the status of the release.
You can see that a release has been manually triggered and that the Development stage is waiting for an
approval. As an approver, you can now perform that approval.
12. Hover over the Development stage and click the Approve icon that appears.
Note: Options to cancel the deployment or to view the logs are also provided at this point
13. In the Development approvals window, add a comment and click Approve.
The deployment stage will then continue. Watch as each stage proceeds and succeeds.
Demonstration Setting Up Release Gates

In this demonstration walkthrough, you will investigate Release Gates.
and the previous walkthroughs.
Steps
Let's now take a look at when our release pipeline needs to perform automated checks for issues like
code quality, before continuing with the deployments. That automated approval phase is achieved by
using Release Gates.
Let's take a look at configuring a release gate.
1. Click the lightning icon on the Development stage to open the pre-deployment conditions settings.
2. In the Pre-deployment conditions pane, click the Disabled button beside Gates to enable them.
3. Click +Add to see the available types of gates, then click Query work items.
We will use the Query work items gate to check if there are any outstanding bugs that need to be dealt
with. It does this by running a work item query. This is an example of what is commonly called a Quality
Gate.
4. Set Display name to No critical bugs allowed, and from the Query drop down list, choose Critical
Bugs. Leave the Upper threshold set to zero because we don't want to allow any bugs at all.
5. Click the drop down beside Evaluation options to see what can be configured. While 15 minutes is a
reasonable value in production, for our testing, change The time between re-evaluation of gates to
5 Minutes.
The release gate doesn't just fail or pass a single time. It can keep evaluating the status of the gate. It
might fail the first time, but after re-evaluation, it might then pass if the underlying issue has been
corrected.
6. Close the pane and click Save and OK to save the work.
7. Click Create release to start a new release, and in the Create a new release pane, click Create.
8. Click on the release number to see how the release is proceeding.

9. If it is waiting for approval, click Approve to allow it to continue, and in the Development pane, click
Approve.
After a short while, you should see the release continuing and then entering the phase where it will
process the gates.
10. In the Development pane, click Gates to see the status of the release gates.
You will notice that the gate failed the first time it was checked. In fact, it will be stuck in the processing
gates stage, as there is a critical bug. Let's look at that bug and resolve it.
11. Close the pane and click Save then OK to save the work.
12. In the main menu, click Boards then click Queries.
13. In the Queries window, click All to see all the available queries.
14. From the list of queries, click Critical bugs.
You will see that there is one critical bug that needs to be resolved.
15. In the properties pane for the bug, change the State to Done, then click Save.
16. Click Run query to re-execute the work item query.
Note that there are now no critical bugs that will stop the release.
17. Return to the release by clicking Pipelines then Releases in the main menu, then clicking the name of
the latest release.
18. When the release gate is checked next time, the release should continue and complete successfully.
Gates are a very powerful automated approval mechanism.
Clean up
To avoid excessive wait time in later walkthroughs, we'll disable the release gates.
19. In the main menu, click Pipelines, then click Releases, then click Edit to open the release pipeline
editor.
20. Click the Pre-deployment conditions icon (i.e. the lightning bolt) on the Development task, and in
the Pre-deployment conditions pane, click the switch beside Gates to disable release gates.
21. Click Save, then click OK.
Building a High-Quality Release pipeline

Quality of Release process and quality of release
Before we dive into high-quality release pipelines, we need to consider the difference between a release
and a release process. Or, when you talk about tooling, a release pipeline.
We start with defining a release process or release pipeline. The release pipeline contains all the steps
that you walk through when you move your artifact, that comes from one of the artifact sources that we
discussed earlier, through the stages or environments.
The stage can be a development stage, a test stage or a production stage or just a stage where a specific
user can access the application. We discussed stages earlier in this module. Also part of your pipeline are
the people that approve the release or the deployment to a specific stage, the triggers or the schedule on
which the releases executes and the release gates, the automatic approvals of the process.
The release itself is something different. The release is an instance of the release pipeline. You can
compare it with object inheritance. In Object Orientation, a class contains the blueprint or definition of an
object. But the object itself is an instance of that blueprint.
Measuring quality
How do you measure the quality of your release process? The quality of your release process cannot be
measured directly because it is a process. What you can measure is how good your process works. If your
release process constantly changes, this might be an indication that there is something wrong in the
process. If your releases constantly fail, and you constantly have to update your release process to make
it work, might also be an indication that something is wrong with your release process.
Maybe something is wrong with the schedule on which your release runs, and you notice that your
release always fails at a particular day or at a certain time. Or your release always fails after the deploy-
ment to another environment. This might be an indication that some things are maybe dependent or
related.
What you can do to keep track of your release process quality, is creating visualisations about the quality
of all the releases following that same release process or release pipeline. For example, adding a dash-
board widget which shows you the status of every release.
Building a High-Quality Release pipeline 323
The release also has a quality aspect, but this is tightly related to the quality of the actual deployment
and the package that has been deployed.
When we want to measure the quality of a release itself, we can perform all kinds of checks within the
pipeline. Of course, you can execute all different types of tests like integration tests, load tests or even
you UI tests while running your pipeline and check the quality of the release that you are deploying.
Using a quality gate is also a perfect way to check the quality of your release. There are many different
quality gates. For example, a gate that monitors to check if everything is healthy on your deployment
targets, work item gates that verify the quality of your requirements process. You can add additional
security and compliance checks. For example, do we comply with the 4-eyes principle, or do we have the
proper traceability?
Using release gates as quality gate

A quality gate is the best way to enforce a quality policy in your organization. It is there to answer one
question: can I deliver my application to production or not?
A quality gate is located before a stage that is dependent on the outcome of a previous stage. In the
past, a quality gate was typically something that was monitored by a QA department. They had a number
of documents or guidelines, and they verified if the software was of a good enough quality to move on to
the next stage. When we think about Continuous Delivery, all manual processes are a potential bottle-
neck.
We need to reconsider the notion of quality gates and see how we can automate these checks as part of
our release pipeline. By using automatic approval using a release gate, you can automate the approval
and validate your company's policy before moving on.
Many quality gates can be considered.
●● No new blocker issues
●● Code coverage on new code greater than 80%
●● No license violations
●● No vulnerabilities in dependencies
●● No new technical debt introduced
●● Compliance checks
●● Are there work items linked to the release?

●● Is the release started by someone else as the code committer?
●● Is the performance not affected after a new release?
Defining quality gates make the release process better, and you should always consider adding them.
Release Notes and Documentation

When you deploy a new release to a customer or install new software on your server, and you want to
communicate what has been released to your customer, the usual way to do this is the use of release
notes.
But where do the release notes come from? There are different ways where you can store your release
notes, and I will walk through the various ways in this section of the course.
Document store
An often used way of storing release notes is by creating text files, or documents in some document
store. This way, the release notes are stored together with other documents. The downside of this
approach is that there is no direct connection between the release in the release management tool and
the release notes that belong to this release.
Wiki
The most used way that is used at customers is to store the release notes in a Wiki. For example, Conflu-
ence from Atlassian, SharePoint Wiki, SlimWiki or the Wiki in Azure DevOps.
The release notes are created as a page in the wiki, and by using hyperlinks, relations can be associated
with the build, the release and the artifacts.
In the code base

When you look at it, release notes belong strictly to the release. To the features you implemented and the
code you wrote. In that case, the best option might be to store release notes as part of your code
repository. The moment, the team completes a feature, they or the product owner also write the release
notes and saves these alongside the code. This way it becomes living documentation because the notes
change with the rest of the code.
In a work item
Another option is to store your release notes as part of your work items. Work items can be Bugs, Tasks,
Product Backlog Items or User Stories. To save release notes in work items, you can create or use a
separate field within the work item. In this field, you type the publicly available release notes that will be
communicated to the customer. With a script or specific task in your build and release pipeline, you can
then generate the release notes and store them as an artifact or publish them to an internal or external
website.
Building a High-Quality Release pipeline 325
●● Generate Release Notes Build Task13

●● WIKI Updater Tasks14
●● Atlassian Confluence15
●● Azure DevOps Wiki16
There is a difference between functional and technical documentation. There is also a difference between
documentation designing the product, mostly written up front and documentation describing the
product afterwards, like manuals or help files. Storing technical documentation about your products, that
is still in the design phase, is usually done on a document sharing portal, like SharePoint or Confluence.
A better and more modern way to store your documentation is to create a wiki. Wiki's do not contain
Documents, Presentations or Spreadsheets but text files called Markdown Files. These markdowns can
refer to pictures, can hold code samples and can be part of your code repository. Code repositories can
deal very well with text files. Changes and history can be easily tracked by using the native code tools.
However, the most significant advantage of using a Wiki instead of documents is that a Wiki is accessible
for everyone in your team. By giving the right permissions to all the team members, people can work
together on the documentation instead of having to wait for each other when working on the same
document.
Manuals or documentation that you release together with the product, should be treated as source code.
When the product changes and new functionality is added, the documentation needs to change as well.
You can store the documentation as part of your code repository, or you can create a new repository
containing your documentation. In any case, the documentation should be treated the same way as your
source code. Create a documentation artifact in your build pipeline, and deliver this artifact to the release
pipeline. The release pipeline can then deploy the documentation to a site or just include in in the boxed
product.
13 https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-XplatGenerateReleaseNotes
14 https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-WIKIUpdater-Tasks
15 https://www.atlassian.com/software/confluence
16 https://azure.microsoft.com/en-us/services/devops/wiki/
Choosing a deployment pattern

Introduction into deployment patterns
Choosing a deployment pattern
A deployment pattern is a way of how you choose to move your application to production. Traditionally
the way to do it was to set up a Development environment, a Test environment and a Production environ-
ment and perform more or less the same steps on each environment. Nowadays we can have Infrastruc-
ture on-demand, and this opens up a new range of possibilities when it comes to deployment patterns.
We are not limited to a fixed set of environments but have various options.
When we move towards Continuous Delivery, we also need to consider that deploying multiple times a
day, can impact our users. They do not want to be surprised with a changed UI after a refresh or 5
minutes of downtime during a transaction. Modern deployment patterns built upon software architecture
patterns. A good example is the use of Feature Toggles that enable you to hide specific functionality.
In this chapter, we will briefly discuss some deployment Patterns. In Module 3 we will cover them in more
details, together with some demos and HandsOn exercises. The most important thing to realise is that
not every application can follow these deployment patterns without changing the application and
architecture.
Traditional Deployment Pattern

Dev, QA, Prod - As new builds are produced, they can be deployed to Dev. They can then be promoted to
QA, and finally to Prod. At any time, each of these stages may have a different release (set of build
artifacts) deployed to them. This is an excellent example of the use of stages in a release pipeline.
Modern Deployment Patterns

Blue-Green Deployment
The Blue-Green deployment is all about ensuring you have two production environments, as identical as
possible. After deployment and tests, the environments are swapped.
Canary Release
A canary release is only pushed to a small number of users. Therefore its impact is relatively small should
the new code prove to be buggy. Changes can be reversed quickly.
Dark Launching
Dark launching is the process of releasing production-ready features to a subset of your users before a
full release. This enables you to decouple deployment from release, get real user feedback, test for bugs,
and assess infrastructure performance.
Progressive Exposure Deployment
In a progressive exposure deployment, you expose the new software to a subset of users, that you extend
gradually over time. Impact (also called blast radius), is evaluated through observation, testing, analysis of
telemetry, and user feedback.
Choosing the right release management tool 327
Choosing the right release management tool

Overview Release Management Tools
A release pipeline consists of different components.
When choosing the right Release Management tool, you should look at the possibilities of all the differ-
ent components and map them to the needs you have. There are many tools available in the marketplace
from which we will discuss some in the next chapter. The most important thing to notice is that not every
vendor or tool treats Release Management in the same manner.
The tools in the marketplace can be divided into 2 categories
●● Tools that can do Build and Continuous Integration and Deployment
●● Tools that can do Release Management
In many cases, companies only require the deployment part of Release Management. Deployment, or
installing software can be done by all the build tools out there. Primarily because the technical part of the
release is executing a script or running a program. Release Management that requires approvals, quality
gates, and different stages, needs a different kind of tool that usually tightly integrate with the build and
CI tools but are not the same thing.
Previously, s we have discussed all the components that are part of the release pipeline, and here we will
briefly highlight the things you need to consider when choosing a Release Management Tool.
Artifacts and Artifact source

As we have seen in the previous chapter, artifacts can come from different sources. When you want to
treat your artifact as a versioned package, it needs to be stored somewhere before your release pipeline
consumes it. Considerations for choosing your tool can be:
●● Which Source Control systems are supported?
●● Can you have 1 or more artifact sources in you release pipeline? In other words, can you combine
artifacts from different sources into one release?
●● Does it integrate with your build server?

●● Does it support other build servers?
●● Does it support container registries?
●● How do you secure the connection to the artifact source?
●● Can you extend the artifact sources?
Triggers and Schedules

Triggers are an essential component in the pipeline. Triggers are required to start a release but, if you
want to have multiple stages, also to start a deployment
Considerations for choosing your trigger can be:
●● Does your system support Continuous Deployment triggers.
●● Can you trigger releases from an API (for integration with other tools)
●● Can you schedule releases
●● Can you schedule and trigger each stage separately?
Approvals and gates

Starting a release and using scripts, executables or deployable artifacts does not make the difference
between a Continuous Integration/Build tool and a Release Management tool. Adding a release approval
workflow to the pipeline is the critical component that does make the difference.
Considerations When it comes to approvals:
●● Do you need approvals for your release pipeline?
●● Are the approvers part of your company? Do they need a tool license?
●● Do you want to use manual or automatic approvals? Or both?
●● Can you approve with an API (integration with other tools)
●● Can you set up a workflow with approvers (optional and required)?
●● Can you have different approvers per stage?
●● Can you have more than one approver? Do you need them all to approve?
●● What are the possibilities for automatic approval?
●● Can you have a manual approval or step in your release pipeline?
Stages
Running a Continuous Integration pipeline that build and deploys your product is a very commonly used
scenario.
But what if you want to deploy the same release to different environments? When choosing the right
release management tool, you should consider the following things when it comes to stages (or environ-
ments)
●● Can you use the same artifact to deploy to different stages?
●● Can you differ the configuration between the stages
●● Can you have different steps for each stage?
●● Can you follow the release between the stages?

●● Can you track the artifacts / work items and source code between the stages?
Build and Release Tasks

Last but not least the work needs to be done within the pipeline. It is not only about the workflow and
orchestration, the code needs to be deployed or installed. Things to consider when it comes to the
execution of tasks
●● How do you create your steps? Is it running a script (bat, shell, PowerShell cli) or are there specialised
tasks?
●● Can you create your own tasks?
●● How do tasks authenticate to secure sources?
●● Can tasks run on multiple platforms?
●● Can tasks be easily reused
●● Can you integrate with multiple environments? (Linux, Windows, Container Clusters, PaaS, CLoud)
●● Can you control the tasks that are used in the pipeline
Traceability, Auditability and Security

One of the most essential things in enterprises and companies that need to adhere to compliance
frameworks is Traceability, Auditability and Security. Although this is not explicitly related to a release
pipeline, it is an important part.
When it comes to compliance 3 principles are fundamental:
●● 4-eyes principle
●● Is the deployed artifact reviewed by at least one other person.

●● Is the person that deploys another person as the one that writes the code
●● Traceability
●● Can we see where the released software originates from (which code)
●● Can we see the requirements that led to this change
●● Can we follow the requirements through the code, build and release
●● Auditablity
●● Can we see who, when and why the release process changed
●● Can we see who, when and why a new release has been deployed
Security is vital in this. When people can do everything, including deleting evidence, this is not ok. Setting
up the right roles, permissions and authorisation are important to protect your system and your pipeline.
When looking at an appropriate Release Management tool, you can consider
●● Does it integrate with your company's Active Directory?
●● Can you set up roles and permissions?
●● Is there change history of the release pipeline itself?
●● Can you ensure the artifact did not change during the release?
●● Can you link requirements to the release?
●● Can you link source code changes to the release pipeline?
●● Can you enforce approval or 4-eyes principle?
●● Can you see release history and the people who triggered the release?
Release Management Tools

The following tools are mainstream in the current ecosystem. You will find links to the product websites
where you can explore the product and see if it fits the needs as we described in the previous chapter.
●● What Artifacts and Artifact source does the tool support
●● What Triggers and Schedules?
●● Does the tool support Approvals and gates
●● Can you define multiple stages?
●● How does the Build and Release Tasks work?
●● How does the tool deal with Traceability, Auditability and Security
●● What is the Extensibility model?
Per tool is indicated if it is part of a bigger suite. Integration with a bigger suite gives you a lot of advan-
tages regarding traceability, security and auditability. A lot of integration is already there out of the box.
Jenkins
The leading open source automation server, Jenkins provides hundreds of plugins to support building,
deploying and automating any project.
●● On-prem system. Offered as SaaS by third-party
●● No part of a bigger suite

●● Industry standard, especially in the full stack space
●● Integrates with almost every source control system
●● Rich ecosystem of plugins
●● CI/Build tool with deployment possibilities.
●● No release management capabilities
Links
●● Jenkins17
●● Tutorial: Jenkins CI/CD to deploy an ASP.NET Core application to Azure Web App service18
●● Azure Friday - Jenkins CI/CD with Service Fabric19
Circle CI
CircleCI’s continuous integration and delivery platform help software teams rapidly release code with
confidence by automating the build, test, and deploy process. CircleCI offers a modern software develop-
ment platform that lets teams ramp quickly, scale easily, and build confidently every day.
●● CircleCI is a cloud-based system or an on-prem system
●● Rest API — you have access to projects, build and artifacts
●● The result of the build is going to be an artifact.
●● Integration with GitHub and BitBucket
●● Integrates with various clouds
●● Not part of a bigger suite
●● Not fully customizable
Links
●● circleci/20
●● How to get started on CircleCI 2.0: CircleCI 2.0 Demo21
Azure DevOps Pipelines

Azure Pipelines helps you implement a build, test, and deployment pipeline for any app. Tutorials,
references, and other documentation show you how to configure and manage continuous integration
and Continuous Delivery (CI/CD) for the app and platform of your choice.
●● Hosted on Azure as a SaaS in multiple regions and available as an on-prem product
●● Complete Rest API for everything around Build and Release Management
17 https://jenkins.io/
18 https://cloudblogs.microsoft.com/opensource/2018/09/21/configure-jenkins-cicd-pipeline-deploy-asp-net-core-application/
19 https://www.youtube.com/watch?v=5RYmooIZqS4
20 https://circleci.com/
21 https://www.youtube.com/watch?v=KhjwnTD4oec
●● Integration with many build and source control systems (Github, Jenkins, Azure Repos, Bitbucket,
Team Foundation Version Control, etc.)
●● Cross Platform support, all languages and platforms
●● Rich marketplace with extra plugins, build tasks and release tasks and dashboard widgets
●● Part of the Azure DevOps suite. Tightly integrated
●● Fully customizable
●● Manual approvals and Release Quality Gates supported
●● Integrated with (Azure) Active Directory
●● Extensive roles and permissions
Links
●● Azure Pipelines22
●● Building and Deploying your Code with Azure Pipelines23
GitLab Pipelines
GitLab helps teams automate the release and delivery of their applications to enable them to shorten the
delivery lifecycle, streamline manual processes and accelerate team velocity. With Continuous Delivery
(CD), built into the pipeline, deployment can be automated to multiple environments like staging and
production, and support advanced features such as canary deployments. Because the configuration and
definition of the application are version controlled and managed, it is easy to configure and deploy your
application on demand.
GitLab24
Atlassian Bamboo
Bamboo is a continuous integration (CI) server that can be used to automate the release management for
a software application, creating a Continuous Delivery pipeline.
Atlassian Bamboo25
XL Deploy/XL Release
XL Release is an end-to-end pipeline orchestration tool for Continuous Delivery and DevOps teams. It
handles automated tasks, manual tasks, and complex dependencies and release trains. And XL Release is
designed to integrate with your change and release management tools.
xl-release - XebiaLabs26
22 https://azure.microsoft.com/en-us/services/devops/pipelines/
23 https://www.youtube.com/watch?v=NuYDAs3kNV8
24 https://about.gitlab.com/stages-devops-lifecycle/release/
25 https://www.atlassian.com/software/bamboo/features
26 https://xebialabs.com/products/xl-release/

Multiple choice
Would adding a feature flag increase or decrease the cyclomatic complexity of the code?
Increase
Decrease
Multiple choice
Would adding a feature flag increase or decrease technical debt?
Increase
Decrease
Suggested answer
You plan to slowly increase the traffic to a newer version of your site. What type of deployment pattern is
this?
4. Suggested answer
When you want to change an immutable object of any type, what do you do?
5. Suggested answer
What can you use to prevent a deployment in Azure DevOps when a security testing tool finds a compliance
problem?
Answers
Multiple choice
Would adding a feature flag increase or decrease the cyclomatic complexity of the code?
■■ Increase
Decrease

Multiple choice
Would adding a feature flag increase or decrease technical debt?
■■ Increase
Decrease

You plan to slowly increase the traffic to a newer version of your site. What type of deployment pattern is
this?
Blue-green
When you want to change an immutable object of any type, what do you do?
You make a new one and (possibly) remove the old one
What can you use to prevent a deployment in Azure DevOps when a security testing tool finds a compli-
ance problem?
Release gate
Module 11 Set up a Release Management
Workflow
Module Overview
Module Overview
Continuous Delivery is much more about enabling teams within your organization. Enable them to deliver
the software on demand. Making it possible that you can press a button at any time of the day, and still
have a good product means a number of things. It says that the code needs to be high quality, the build
needs to be fully automated and tested, and the deployment of the software needs to be fully automated
and tested as well.
Now we need to dive a little bit further into the release management tooling. We will include a lot of
things coming from Azure pipelines. A part of the Azure DevOps suite. Azure DevOps is an integrated
solution for implementing DevOps and Continuous Delivery in your organization. We will cover some
specifics of Azure pipelines, but this does not mean they do not apply for other products available in the
marketplace. Many of the other tools share the same concepts and only differ in naming.
Release pipelines
A release pipeline, in its simplest form, is nothing more than the execution of a number of steps. In this
module, we will dive a little bit further into the details of one specific stage. The steps that need to be
executed and the mechanism that you need to execute the steps within the pipeline.
In this module, we will talk about agent and agent pools that you might need to execute your release
pipeline. We will look at variables for the release pipeline and the various stages.
After that, we dive into the tasks that you can use to execute your deployment. Do you want to use script
files or do you want to use specific tasks that can perform one job outstanding? For example, the market-
places of both Azure DevOps and Jenkins have a lot of tasks in the store that you can use to make your
life a lot easier.
We will talk about secrets and secret management in your pipeline. A fundamental part to secure your
not only your assets but also the process of releasing your software. At the end of the module, we will
talk about alerting mechanisms. How to report on your software, how to report on your quality and how
MCT USE ONLY. STUDENT USE PROHIBITED 338 Module 11 Set up a Release Management Workflow
to get notified by using service hooks. Finally, we will dive a little bit further into automatic approvals
using automated release gates.
Learning objectives
●● Explain the terminology used in Azure DevOps and other Release Management Tooling
●● Describe what a Build and Release task is, what it can do, and some available deployment tasks
●● Classify an Agent, Agent Queue, and Agent Pool
●● Explain why you sometimes need multiple release jobs in one release pipeline
●● Differentiate between multi-agent and multi-configuration release job
●● Use release variables and stage variables in your release pipeline
●● Deploy to an environment securely using a service connection
●● Embed testing in the pipeline
●● List the different ways to inspect the health of your pipeline and release by using alerts, service hooks,
and reports
●● Create a release gate
Create a Release Pipeline 339
Create a Release Pipeline

Release pipelines Classic interface or YAML
Azure DevOps Release Pipelines
Azure DevOps has extended support for pipelines as code (also referred to as YAML pipelines) for
continuous deployment and started to introduce various release management capabilities into pipelines
as code. The existing UI based release management solution in Azure DevOps is referred to as classic
release. In the table below you'll find a list of capabilties and their availability in YAML pipelines vs classic
build and release pipelines.
Feature YAML Classic Build Classic Release Notes

Agents Yes Yes Yes Specifies a re-
quired resource on
which the pipeline
runs.
Approvals Yes No Yes Defines a set of
validations
required prior to
completing a
deployment stage.
Artifacts Yes Yes Yes Supports publish-
ing or consuming
different package
types.
Caching Yes Yes No Reduces build time
by allowing
outputs or down-
loaded dependen-
cies from one run
to be reused in
later runs. In
Preview, available
with Azure
Pipelines only.
Conditions Yes Yes Yes Specifies condi-
tions to be met
prior to running a
job.
Container jobs Yes No No Specifies jobs to
run in a container.
Demands Yes Yes Yes Ensures pipeline
requirements are
met before
running a pipeline
stage. Requires
self-hosted agents.

Dependencies Yes Yes Yes Specifies a require-
ment that must be
met in order to run
the next job or
stage.
Deployment Yes No Yes Defines a logical
groups set of deployment
target machines.
Deployment group No No Yes Specifies a job to
jobs release to a
deployment group.
Deployment jobs Yes No No Defines the
deployment steps.
Requires Mul-
ti-stage pipelines
experience.
Environment Yes No No Represents a
collection of
resources targeted
for deployment.
Available with
Azure Pipelines
only.
Gates No No Yes Supports automat-
ic collection and
evaluation of
external health
signals prior to
completing a
release stage.
Available with
Azure Pipelines
only.
Jobs Yes Yes Yes Defines the
execution se-
quence of a set of
steps.
Service connec- Yes Yes Yes Enables a connec-
tions tion to a remote
service that is
required to
execute tasks in a
job.
Service containers Yes No No Enables you to
manage the
lifecycle of a
containerized
service.

Stages Yes No Yes Organizes jobs
within a pipeline.
Task groups No Yes Yes Encapsulates a
sequence of tasks
into a single
reusable task. If
using YAML, see
templates.
Tasks Yes Yes Yes Defines the
building blocks
that make up a
pipeline.
Templates Yes No No Defines reusable
content, logic, and
parameters.
Triggers Yes Yes Yes Defines the event
that causes a
pipeline to run.
Variables Yes Yes Yes Represents a value
to be replaced by
data to pass to the
pipeline.
Variable groups Yes Yes Yes Use to store values
that you want to
control and make
available across
multiple pipelines.
Definitions and Glossary

We have covered the concepts of a release pipeline. Many terms and definitions are used. The hardest
part is that these terms vary from tool to tool. In this part, you find a list of names and definitions and
synonyms.
In this list, you find the term that is used in Azure DevOps.
Term Description Synonym

Stage an isolated and independent Environment
target for deployment
Job A phase in the release pipeline Phases
that can run simultaneously with
other phases on different
Operating Systems
Agent The program that runs the build
or release
Build & Release Task Tasks are units of executable Action, Plugin, App
code used to perform designat-
ed actions in a specified order.
Term Description Synonym

Release pipeline The process that runs when release process, pipeline, release
deploying an artifact. Including definition
triggers, approvals and gates
CI/CD Continuous Integration / Contin-
uous Deployment
Release gate An automated check that Quality Gate, Automatic Approv-
approves the continuation al
Service Connection A secure connection to an Service Endpoint
environment or service
Build and Release Tasks

A build and release platform requires the ability to execute any number of repeatable actions during the
build process. Tasks are units of executable code used to perform designated actions in a specified order.
Add steps to specify what you want to build, the tests that you want to run, and all of the other steps
needed to complete the build process. There are steps for building, testing, running utilities, packaging,
and deploying.
If a task is not available, you can find a lot of community tasks in the marketplace. Jenkins, Azure DevOps
and Atlassian have an extensive marketplace where additional tasks can be found.
Links
●● Task types & usage1
●● Tasks for Azure2
●● Atlassian marketplace3
●● Jenkins Plugins4
●● Azure DevOps Marketplace5
Important Deployment Tasks

The choice of deployment tasks depends on the target environment to which you want to deploy your
software.
If you want to deploy a mobile app, you can create a package and upload it with a script or use a task
that directly deploys to the Apple Store or Google Play store.
If you want to deploy to a server running on premises, then you might want to use a PowerShell or
command line script to install the software. Or, if you're going to use a specialised task, you can use the
web deployment task, that deploys MS deploy packages directly on an IIS
You can also use an SSH Task and use, Shell tasks to execute the necessary actions on the target server.
When you want to deploy to Azure or another cloud, you can use command line tools specialised for that
cloud, or some specialised tasks that you can use to install your resources.
When you want to deploy to a container cluster, you can run a docker command in a command line task,
or you can use specific docker tasks. They do a lot of the plumbing and secure connections to the
container cluster and container registry.
In the following section, a list of out of the box tasks is listed so you can see what is available for you to
deploy. Regardless of the environment that you want to target.
1 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml
2 https://github.com/microsoft/azure-pipelines-tasks
3 https://marketplace.atlassian.com/addons/app/bamboo/trending
4 https://plugins.jenkins.io/
5 https://marketplace.visualstudio.com/
Deploy
Task
Distribute app builds to testers and users via App
Center
App Center Distribute (https://docs.microsoft.

com/en-us/appcenter/distribution/)
Update Azure App Service using Web Deploy /
Kudu REST APIs
Azure App Service Deploy (https://docs.microsoft.

com/en-us/azure/devops/pipelines/tasks/deploy/
azure-rm-web-app-deployment?view=vsts)
Task
Start, Stop, Restart or Slot swap for an Azure App
Service
Azure App Service Manage (https://docs.micro-

soft.com/en-us/azure/devops/pipelines/tasks/
deploy/azure-app-service-manage?view=vsts)
Run a shell or batch script containing Azure CLI
commands against an Azure subscription
Azure CLI (https://docs.microsoft.com/en-us/azure/

devops/pipelines/tasks/deploy/azure-cli?view=vsts)
Task
Deploy an Azure Cloud Service
Azure Cloud PowerShell Deployment (https://

docs.microsoft.com/en-us/azure/devops/pipelines/
tasks/deploy/azure-cloud-powershell-deploy-
ment?view=vsts)
Copy files to Azure blob or VM(s)
Azure File Copy (https://docs.microsoft.com/en-us/

azure/devops/pipelines/tasks/deploy/azure-file-
copy?view=vsts)
Task
Incorporate secrets from an Azure Key Vault into a
release pipeline
Azure Key Vault (https://docs.microsoft.com/

en-us/azure/devops/pipelines/tasks/deploy/
azure-key-vault?view=vsts)
Configure alerts on available metrics for an Azure
resource
Azure Monitor Alerts (https://docs.microsoft.com/

azure-monitor-alerts?view=vsts)
Task
Run your scripts and make changes to your Azure
DB for MySQL.
Azure MySQL Deployment (https://docs.microsoft.

azure-mysql-deployment?view=vsts)
Security and compliance assessment with Azure
policies on resources that belong to the resource
group and Azure subscription.
Azure Policy Check Gate (https://docs.microsoft.

azure-policy-check-gate?view=vsts)
Task
Run a PowerShell script within an Azure environ-
ment
Azure PowerShell (https://docs.microsoft.com/

azure-powershell?view=vsts)
Deploy, start, stop, delete Azure Resource Groups
Azure Resource Group Deployment (https://docs.

microsoft.com/en-us/azure/devops/pipelines/tasks/
deploy/azure-resource-group-deploy-
ment?view=vsts)
Task
Deploy an Azure SQL database using DACPAC or
run scripts using SQLCMD
Azure SQL Database Deployment (https://docs.

deploy/sql-azure-dacpac-deployment?view=vsts)
Deploy a virtual machine scale set image.
Azure VM Scale Set Deployment (https://docs.

deploy/azure-vmss-deployment?view=vsts)
Task
Build a machine image using Packer.
Build Machine Image (Packer) (https://docs.

deploy/packer-build?view=vsts)
Deploy to Chef environments by editing environ-
ment attributes
Chef (https://docs.microsoft.com/en-us/azure/
devops/pipelines/tasks/deploy/chef?view=vsts)
Task
Run Scripts with knife commands on your chef
workstation
Chef Knife (https://docs.microsoft.com/en-us/

azure/devops/pipelines/tasks/deploy/chef-
knife?view=vsts)
Copy files from source folder to target folder on a
remote machine over SSH
Copy Files Over SSH (https://docs.microsoft.com/

copy-files-over-ssh?view=vsts)
Task
Build, tag, push, or run Docker images, or run a
Docker command. Task can be used with Docker
or Azure Container registry
Docker
Build, push or run multi-container Docker applica-
tions.
Docker Compose
Task
Deploy, configure, update your Kubernetes cluster
in Azure Container Service by running helm
commands.
Helm Deploy (https://docs.microsoft.com/en-us/

azure/devops/pipelines/tasks/deploy/helm-de-
ploy?view=vsts)
Deploy a website or web app to a machine group
using WebDeploy
IIS Web App Deploy (https://docs.microsoft.com/

iis-web-app-deployment-on-machine-
group?view=vsts)
Task
Create or update a website, web app, virtual
directory, or application pool on a machine group
IIS Web App Manage (https://docs.microsoft.com/

iis-web-app-management-on-machine-
group?view=vsts)
Deploy, configure, update your Kubernetes cluster
in Azure Container Service by running kubectl
commands.
Kubernetes (https://docs.microsoft.com/en-us/
azure/devops/pipelines/tasks/deploy/kuber-
netes?view=vsts)
Task
Execute PowerShell scripts on remote machine(s)
PowerShell on Target Machines (https://docs.

deploy/powershell-on-target-machines?view=vsts)
Deploy a Service Fabric application to a cluster
Service Fabric Application Deployment (https://

tasks/deploy/service-fabric-deploy?view=vsts)
Task
Deploy a Service Fabric application to a cluster
using a compose file
Service Fabric Compose Deploy (https://docs.

deploy/service-fabric-compose-deploy?view=vsts)
Run shell commands or a script on a remote
machine using SSH
SSH (https://docs.microsoft.com/en-us/azure/
devops/pipelines/tasks/deploy/ssh?view=vsts)
Task
Copy files to remote machine(s)
Windows Machine File Copy (https://docs.

deploy/windows-machine-file-copy?view=vsts)
Deploy a SQL Server database using DACPAC or
SQL scripts
WinRM SQL Server DB Deployment (https://

tasks/deploy/sql-dacpac-deployment-on-machine-
group?view=vsts)
Refer to Build and release tasks6 for a full list of tasks.
Agents, Agent Pools and Queues

A build agents is a running background service which listens for commands from the central server and
starts and executes the actual build or release processes. It is installed and configured separately from the
server (or saas solution).
6 https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/index?view=vsts
An agent can most of the times run on different Operating Systems and in some cases as a SaaS (hosted
agent) solution.
Agents are organized into pools and provide access to the pools by using queues.
Agent pools
Agent pools are used to organize and define permission boundaries around your agents. In Azure
DevOps, Pools are scoped to your organization. You can share your pool across multiple team project
collections.
Agent Queues
An agent queue provides access to a pool of agents. When you create a build or release definition, you
specify which queue it uses. Queues are scoped to your team project collection so that you can share
them across build and release definitions in multiple team projects.
Build Agents and Server Options

Build agents are tasked with performing the builds. To build your code or deploy your software, you need
at least one agent. As you add more code and add more people, you will eventually need more agents to
form a pool.
Pipelines are based on build agents, which are implemented as a background service installed on a virtual
machine. Build agents are then grouped into agent pools, which are supplied from an agent queue. This
means that build pipelines do not interact with build agents directly, but instead place a request in an
agent queue, which is owned by a team project. Each agent queue feeds a single agent pool, and multi-
ple queues may feed the same agent. The pool then provides build agents based on availability and the
build definition requirements.
Build agents come in two types:

Hosted agents. These agents exist within their own hosted pool and are maintained and upgraded by
the vendor. Hosted agents have specific limitations and advantages:
●● Hosted agents have no cost and are immediately available, and have most common software and
libraries installed.
●● Do not have an interactive mode.
●● Do not allow administrative privilege or allow logon.
Hosted agents come in many flavours. Based on the needs of your product and the platform that you
target you can choose an appropriate agent. The agent software is cross-platform and can run on any
platform
Private (or Custom) agents. Private agents are provisioned on private virtual machines (VMs) and are
custom built to accommodate the project's needs.
System capabilities
System capabilities are name/value pairs that you can use to ensure that your build definition is run only
by agents that meet the criteria that you specified. Environment variables automatically appear in the list.
Some capabilities (such as frameworks) are also added automatically.
When a build is queued, the system sends the job only to agents that have the capabilities demanded by
the build definition7.
7 https://docs.microsoft.com/en-us/azure/devops/pipelines/build/options?view=vsts&tabs=yaml
User capabilities
You can manually add capabilities (name/value pairs) that you know your agent has and that you want
your build definition to be able to demand8.
Agents and Deployment Groups

Agents run on a separate server and install and execute actions on a deployment target. By having an
agent installed in this way, you need to have permissions to access the target environment. The target
environment needs to accept incoming traffic. When you use Hosted agents, running in the cloud, you
cannot use these agents to deploy software on your on-premises server.
To overcome this issue, you can run agents in your local network that communicate with the central
server.
If this also does not work, you need to fall back on the traditional approach of installing agents on the
target environment. In Azure DevOps, this is called Deployment Groups. The agent on the target server is
registered and do everything themselves. This means that they only need to have outbound access and is
sometimes the only allowed option
Learn more
●● Azure Pipelines agents9
●● Provision deployment groups10
●● Microsoft-hosted agents11
●● Agent pools12
●● Self-hosted Linux agents13
●● Deploy an Azure Pipeline agent in Windows14
8 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=vsts
9 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=vsts
10 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/?view=vsts
11 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml
12 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=vsts
13 https://docs.microsoft.com/en-us/vsts/build-release/actions/agents/v2-linux?view=vsts
14 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=vsts
●● Deploy a build and release agent on macOS15

●● Deploy a Azure Pipelines agent on Linux16
Release Agent Jobs Introduction

What is a Release Agent Job?
You can organize your build or release pipeline into jobs. Every build or deployment pipeline has at least
one job.
A job is a series of tasks that run sequentially on the same target. This can be a Windows server, a Linux
server, a container or a deployment group. A release job is executed by a build/release agent. This agent
can only execute one job at the same time.
During the design of your job, you specify a series of tasks that you want to run on the same agent. At
runtime (when either the build or release pipeline is triggered), each job is dispatched as one or more
jobs to its target.
A scenario that speaks to the imagination, where Jobs play an essential role is the following.
Assume that you built an application, with a backend in .Net, a front end in Angular and a native IOS
mobile App. This might be developed in 3 different source control repositories triggering three different
builds, delivering three different artifacts.
The release pipeline brings the artifacts together and wants to deploy the backend, frontend, and Mobile
App all together as part of 1 release. The deployment needs to take place on different agents. An IOS app
needs to be built and distributed from a Mac, and the angular app is hosted on Linux so best deployed
from a Linux machine. The backend might be deployed from a Windows machine.
Because you want all three deployments to be part of one pipeline, you can define multiple Release Jobs,
which target the different agents, server or deployment groups.
By default, jobs run on the host machine where the agent is installed. This is convenient and typically
well-suited for projects that are just beginning to adopt continuous integration (CI). Over time, you may
find that you want more control over the stage where your tasks run.
15 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=vsts
16 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=vsts
For more inforamtion, see Jobs in Azure Pipelines and TFS17.
Using Release Jobs

You can have different Release Jobs. In this chapter, they are briefly covered
Jobs or Agent Jobs

A job is a series of tasks that run sequentially on the same target. At design time in your job, you specify
a set of tasks that you want to run on a common target. At runtime (when either the build or release
pipeline is triggered), each job is dispatched as one or more jobs to its target.
When the target is an agent, the tasks are run on the computer that hosts the agent. This agent can only
execute one job at the same time.
For more information, see Specify jobs in your pipeline18.
Server or Agentless Jobs

Tasks in a server or agentless job are orchestrated by and executed on the server (Azure Pipelines or TFS).
A server job does not require an agent or any target computers. Only a few tasks, such as the Manual
Intervention and Invoke REST API tasks, are supported in a server job at present.
17 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=vsts&tabs=yaml
18 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=vsts&tabs=yaml
Container Jobs
Containers offer a lightweight abstraction over the host operating system. You can select the exact
versions of operating systems, tools, and dependencies that your build requires. When you specify a
container in your pipeline, the agent will first fetch and start the container. Then, each step of the job will
run inside the container.
For more information, see Define container jobs (YAML)19.
Deployment Group Jobs

Deployment groups make it easy to define groups of target servers for deployment. Tasks that you define
in a deployment group job run on some or all of the target servers, depending on the arguments you
specify for the tasks and the job itself.
You can select specific sets of servers from a deployment group to receive the deployment by specifying
the machine tags that you have defined for each server in the deployment group. You can also specify the
proportion of the target servers that the pipeline should deploy to at the same time. This ensures that the
app running on these servers is capable of handling requests while the deployment is taking place.
For more information, see Deployment group jobs20.
Multi-Configuration and Multi-Agent

We talked about Jobs and how to make it possible to divide the work between different agents or servers.
Sometimes you want to run the tasks of a pipeline multiple times but with a slightly different configura-
tion, or split a large batch of work amongst multiple agents.
There are three different types of job you can run.
●● None: Tasks will run on a single agent.
●● Multi-configuration: Run the same set of tasks on multiple configurations as specified in the multi-
pliers. Configurations will run in parallel, and each configuration will use a single agent. For example
●● Run the release once with configuration Setting A on WebApp A and setting B for WebApp B
●● Deploy to different geographic regions.
●● Multi-configuration testing: run a set of tests in parallel - once for each test configuration.
19 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=vsts&tabs=yaml
20 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-group-phases?view=vsts&tabs=yaml
●● Multi-agent: Run the same set of tasks on multiple agents using the specified number of agents. For
example, you can run a broad suite of 1000 tests on a single agent. Or, you can use two agents and
run 500 tests on each one in parallel.
For more information, see Specify jobs in your pipeline21.
Discussion
How to use Release jobs
Do you see a purpose for Release Jobs in your pipeline and how would you set it up?
Topics you might want to consider are:
●● Do you have artifacts from multiple sources?
●● Do you want to run deployments on different servers simultaneously?
●● Do you need multiple platforms?
●● How long does your release take?
●● Can you run your deployment in parallel or does it need to run in sequence?
Release Variables
Variables give you a convenient way to get critical bits of data into various parts of the pipeline. As the
name suggests, the contents of a variable may change between releases, stages of jobs of your pipeline.
The system predefines some variables, and you are free to add your own as well.
The most important thing you need to think about when using variables in the release pipeline is the
scope of the variable. You can imagine that a variable containing the name of the target server may vary
between a Development environment and a Test Environment.
Within the release pipeline, you can use variables in different scopes and different ways.
For more information, see Release variables and debugging22.
21 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=vsts&tabs=designer#multi-configuration
22 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=vsts&tabs=batch
Predefined variables
When running your release pipeline, there are always variables that you need that come from the agent
or context of the release pipeline. For example, the agent directory where the sources are downloaded,
the build number or build id, the name of the agent or any other information. This information is usually
accessible in pre-defined variables that you can use in your tasks.
Release pipeline variables

Choose a release pipeline variable when you need to use the same value across all the stages and tasks in
the release pipeline, and you want to be able to change the value in a single place.
Stage variables
Share values across all of the tasks within one specific stage by using stage variables. Use a stage-level
variable for values that vary from stage to stage (and are the same for all the tasks in a stage).
Variable groups
Share values across all of the definitions in a project by using variable groups. We will cover variable
groups later in this module.
Normal and Secret variables

Because the tasks of the pipeline are executed on an agent, usually variable values are passed to the
various tasks using environment variables. The task knows how to read this. You should be aware that a
variable contains clear text and can be exposed on the target system. When you use the variable in the
log output, you can also see the value of the variable. When the pipeline has finished, the values will be
cleared.
You can mark a variable in the release pipeline as secret. This way the secret is hidden from the log
output. This is especially useful when writing a password or other sensitive information
Provision and Configure Environments

Provision and Configure Different Target Envi-
ronments
The release pipeline deploys software to a target environment. But, it is not only the software that will be
deployed with the release pipeline. If you are truly focusing on Continuous Delivery, Infrastructure as
Code and spinning up infrastructure as part of your release pipeline is very important.
When we focus on the deployment of the infrastructure, we should first consider the differences between
the target environments that we can deploy to.
●● On-Premises servers
●● Cloud servers or Infrastructure as a Service (IaaS). For example Virtual machines or networks.
●● Platform as a Service (PaaS) and Functions as a Service (FaaS). For example Web apps or storage
accounts.
●● Clusters.
Let us dive a bit further into these different target environments.
On-Premises servers
In most cases, when you deploy to an on-premises server, the hardware and the operating system is
already in place. The server is already there and ready Sometimes empty but most of the times not. In this
case, the release pipeline can focus on deploying the application only.
In some cases, you might want to start or stop a virtual machine (for example Hyper-V or VMWare). The
scripts that you use to start or stop the on-premises servers should be part of your source control and be
delivered to your release pipeline as a build artifact. Using a task in the release pipeline, you can run the
script that starts or stops the servers.
When you want to take it one step further, and you want to configure the server as well. You should take
a look at technologies like PowerShell Desired State Configuration(DSC), or use tools like Puppet and
Chef. All these products will maintain your server and keep it in a particular state. When the server
changes its state, they (Puppet, Chef, DSC) recover the changed configuration to the original configura-
tion.
Integrating a tool like Puppet, Chef or Powershell DSC in to the release pipeline is no different from any
other task you add.
Infrastructure as a service
When you use the cloud as your target environment things change a little bit. Some organizations did a
lift and shift from their on-premises server to cloud servers. Then your deployment works the same as to
an on-premises server. But when you use the cloud to provide you with Infrastructure as a Service (IaaS),
you can leverage the power of the cloud, to start and create servers when you need them.
This is where Infrastructure as Code (IaC) starts playing a significant role. By creating a script or template,
you can create a server or other infrastructural components like a SQL server, a network or an IP address.
By defining a template or using a command line and save it in a script file, you can use that file in your
release pipeline tasks to execute this on your target cloud. As part of your pipeline, the server (or another
component) will be created. After that, you can execute the steps actually to deploy the software.
Provision and Configure Environments 369
Technologies like Azure Resource Manager (ARM) or Terraform are great to create infrastructure on
demand.
Platform as a Service
When you are moving from Infrastructure as a Service (IaaS) towards Platform as a Service (PaaS), you will
get the infrastructure from the cloud that you are running on.
For example: In Azure, you can choose to create a Web application. The server, the hardware, the net-
work, the public IP address, the storage account, and even the web server, is arranged by the cloud. The
user only needs to take care of the web application that will run on this platform.
The only thing that you need to do is to provide the templates which instruct the cloud to create a
WebApp. The same goes for Functions as a Service(FaaS or Serverless technologies. In Azure called Azure
Functions and in AWS called AWS Lambda.
You only deploy your application, and the cloud takes care of the rest. However, you need to instruct the
platform (the cloud) to create a placeholder where your application can be hosted. You can define this
template in ARM or Terraform. You can use the Azure CLI or command line tools or in AWS use CloudFor-
mation. In all cases, the infrastructure is defined in a script file and live alongside the application code in
source control.
Clusters
Last but not least you can deploy your software to a cluster. A cluster is a group of servers that work
together to host high-scale applications.
When you run a cluster as Infrastructure as a Service, you need to create and maintain the cluster. This
means that you need to provide the templates to create a cluster. You also need to make sure that you
roll out updates, bug fixes and patches to your cluster. This is comparable with Infrastructure as a Service.
When you use a hosted cluster, you should consider this as Platform as a Service. You instruct the cloud
to create the cluster, and you deploy your software to the cluster. When you run a container cluster, you
can use the container cluster technologies like Kubernetes or Docker Swarm.
Summary
Regardless of the technology, you choose to host your application, the creation, or at least configuration
of your infrastructure should be part of your release pipeline and part of your source control repository.
Infrastructure as Code is a fundamental part of Continuous Delivery and gives you the freedom to create
servers and environments on demand.
Links
●● AWS Cloudformation23
●● Terraform24
●● Powershell DSC25
●● AWS Lambda26
23 https://aws.amazon.com/cloudformation/
24 https://www.terraform.io/
25 https://docs.microsoft.com/en-us/powershell/dsc/overview/overview
26 https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
●● Azure Functions27
●● Chef28
●● Puppet29
●● Azure Resource Manager /ARM30
Demonstration Setting Up Service Connections

In this demonstration, you will investigate Service Connections.
To follow along with this walkthrough, you will need to have an existing Azure subscription, that contains an
existing storage account.
Steps
Let's now take a look at how a release pipeline can access resources that require a secure connection. In
Azure DevOps, these are implemented by Service Connections.
You can set up a service connection to environments to create a secure and safe connection to the
environment that you want to deploy to. Service connections are also used to get resources from other
places in a secure manner. For example, you might need to get your source code from GitHub.
In this case, let's take a look at configuring a service connection to Azure.
1. From the main menu in the Parts Unlimited project, click Project settings at the bottom of the
screen.
2. In the Project Settings pane, from the Pipelines section, click Service connections. Click the drop
down beside +New service connection.
27 https://azure.microsoft.com/en-us/services/functions
28 https://www.chef.io/chef/
29 https://puppet.com/
30 https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
As you can see, there are many types of service connections. You can create a connection to the Apple
App Store or to the Docker Registry, to Bitbucket, or to Azure Service bus.
In this case, we want to deploy a new Azure resource, so we'll use the Azure Resource Manager option.
3. Click Azure Resource Manager to add a new service connection.
4. Set the Connection name to ARM Service Connection, click on an Azure Subscription, then select
an existing Resource Group.
Note: You might be prompted to logon to Azure at this point. If so, logon first.
Notice that what we are actually creating is a Service Principal. We will be using the Service Principal as
a means of authenticating to Azure. At the top of the window, there is also an option to set up Managed
Identity Authentication instead.
The Service Principal is a type of service account that only has permissions in the specific subscription and
resource group. This makies it a very safe way to connect from the pipeline.
5. Click OK to create it. It will then be shown in the list.
6. In the main Parts Unlimited menu, click Pipelines then *Releases, then Edit to see the release pipeline.
Click the link to View stage tasks.
The current list of tasks is then shown. Because we started with an empty template, there are no tasks as
yet. Each stage can execute many tasks.
7. Click the + sign to the right of Agent job to add a new task. Note the available list of task types.
8. In the Search box, enter the word storage and note the list of storage-related tasks. These include
standard tasks, and tasks available from the Marketplace.
We will use the Azure file copy task to copy one of our source files to a storage account container.
9. Hover over the Azure file copy task type, and click Add when it appears. The task will be added to
the stage but requires further configuration.
10. Click the File Copy task to see the required settings.
11. Set the Display Name to Backup website zip file, then click the ellipsis beside Source and locate the
file as follows, then click OK to select it.
We then need to provide details of how to connect to the Azure subscription. The easiest and most
secure way to do that is to use our new Service Connection.
12. From the Azure Subscription drop down list, find and select the ARM Service Connection that we
created.
13. From the Destination Type drop down list, select Azure Blob, and from the RM Storage Account
and Container Name, select the storage account, and enter the name of the container, then click
Save at the top of the screen and OK.
14. To test the task, click Create release, and in the Create a new release pane, click Create.
15. Click the new release to view the details.
16. On the release page, approve the release so that it can continue.
17. Once the Development stage has completed, you should see the file in the Azure storage account.
A key advantage of using service connections is that this type of connection is is managed in a single
place within the project settings, and doesn't involve connection details spread throughout the pipeline
tasks.
Manage and Modularize Tasks and Templates

Introduction
When you deploy multiple applications and have multiple builds and release pipelines, reusability comes
into mind.
For example, you deploy to the same set of servers and use the same connection strings. You want to
store the values in one place so you can easily update them.
The same goes for some actions you always want to perform together. For example, stop a website,
running a script, start a website.
Sometimes you want to take this even one step further. You want to do some specialized actions, that are
not available in the public marketplace. By writing a reusable task that you can use in your organization
or even make public, is an excellent way to encapsulate logic and distribute this safely and securely.
Within the Azure DevOps suite, three important concepts enable reusability.
●● Task Groups
●● Variable Groups
●● Custom Build and Release Tasks
Task Groups
A task group allows you to encapsulate a sequence of tasks, already defined in a build or a release
pipeline, into a single reusable task that can be added to a build or release pipeline, just like any other
task. You can choose to extract the parameters from the encapsulated tasks as configuration variables,
and abstract the rest of the task information.
Task groups are a way to standardize and centrally manage deployment steps for all your applications.
When you include a task group in your definitions, and then make a change centrally to the task group,
the change is automatically reflected in all the definitions that use the task group. There is no need to
change each one individually.
For more information, see Task groups for builds and releases31.
Variable Groups
A variable group is used to store values that you want to make available across multiple builds and
release pipelines.
Examples
●● Store the username and password for a shared server
●● Store a share connection string
●● Store the geolocation of an application
●● Store all settings for a specific application
For more information, see Variable Groups for Azure Pipelines and TFS32.
31 https://docs.microsoft.com/en-us/azure/devops/pipelines/library/task-groups?view=vsts
32 https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=vsts
Manage and Modularize Tasks and Templates 379
Custom Tasks
Instead of using the out-of-the-box tasks, or using a command line or shell script, you can also use your
custom build and release task. By creating your own tasks, the tasks are available for publicly or privately
to everyone you share it with.
Creating your own task has significant advantages.
●● You get access to variables that are otherwise not accessible,
●● you can use and reuse secure endpoint to a target server
●● you can safely and efficiently distribute across your whole organization
●● users do not see implementation details.
For more information, see Add a build or release task33.
Demonstration Creating and Managing Task

Groups
In this demonstration, you will investigate Task Groups.
Steps
Let's now take a look at how a release pipeline can reuse groups of tasks.
It's common to want to reuse a group of tasks in more than one stage within a pipeline or in different
pipelines.
1. In the main menu for the Parts Unlimited project, click Pipelines then click Task groups.
You will notice that you don't currently have any task groups defined.
33 https://docs.microsoft.com/en-us/azure/devops/extend/develop/add-build-task?view=vsts
There is an option to import task groups but the most common way to create a task group is directly
within the release pipeline, so let's do that.
2. In the main menu, click Pipelines then click Releases, and click Edit to open the pipeline that we have
been working on.
3. The Development stage currently has a single task. We will add another task to that stage. Click the
View stage tasks link to open the stage editor.
You can see that there is currently one task.
4. Click the + sign to the right of the Agent job line to add a new task. In the Search box, type data-
base.
We will add a task to deploy an Azure SQL Database.

5. Hover over the Azure SQL Database Deployment option and click Add. Click the Azure SQL
DacpacTask when it appears in the list, to open the settings pane.
6. Set the Display name to Deploy devopslog database, and from the **Azure Subscriptions" drop
down list, click ARM Service Connection.
Note: we are able to reuse our service connection here
7. In the SQL Database section, set a unique name for the SQL Server, set the Database to devopslog,
set the Login to devopsadmin, and set any suitable password.
8. In the Deployment Package section, set the Deploy type to Inline SQL Script, set the Inline SQL
Script to:
CREATE TABLE dbo.TrackingLog
(
TrackingLogID int IDENTITY(1,1) PRIMARY KEY,
TrackingDetails nvarchar(max)
);
9. Click Save then OK to save the work.

Now that we have two tasks, let's use them to create a task group.
10. Click to select the Backup website zip file task and also select the Deploy devopslog database task,
then right-click either task.
11. Click Create task group, then in the Create task group window, set Name to Backup website zip
file and deploy devopslog. Click the Category drop down list to see the available options. Ensure
that Deploy is selected, and click Create.
In the list of tasks, the individual tasks have now disappeared and the new task group appears instead.
12. From the Task drop down list, select the Test Team A stage.
There are currently no tasks in the stage.
13. Click the + sign to the right of Agent job to add a new task. In the Search box, type backup and
notice that the new task group appears like any other task.
14. Hover on the task group and click Add when it appears.
Task groups allow for each reuse of a set of tasks and limits the number of places where edits need to
occur.
Walkthrough cleanup
15. Click Remove to remove the task group from the Test Team A stage.
16. From the Tasks drop down list, select the Development stage. Again click Remove to remove the
task group from the Development stage.
17. Click Save then OK.
Demonstration Creating and Managing Variable

Groups
In this demonstration, you will investigate Variable Groups.
Steps
Let's now take a look at how a release pipeline can make use of predefined sets of variables, called
Variable Groups.
Similar to the way we used task groups, variable groups provide a convenient way to avoid the need to
redefine many variables when defining stages within pipelines, and even when working across multiple
pipelines. Let's create a variable group and see how it can be used.
1. On the main menu for the Parts Unlimited project, click Pipelines, then click Library. There are
currently no variable groups in the project.
2. Click + Variable group to commence creating a variable group. Set Variable group name to Web-
site Test Product Details.
3. In the Variables section, click +Add, then in Name, enter ProductCode, and in Value, enter RED-
POLOXL.
You can see an extra column that shows a lock. It allows you to have variable values that are locked and
not displayed in the configuation screens. While this is often used for values like passwords, notice that
there is an option to link secrets from an Azure key vault as variables. This would be a preferable option
for variables that are providing credentials that need to be secured outside the project.
In this example, we are just providing details of a product that will be used in testing the website.
4. Add another variable called Quantity with a value of 12.
5. Add another variable called SalesUnit with a value of Each.
6. Click Save to save the new variable group.
7. On the main menu, click Pipelines, then click Releases, then click Edit to return to editing the release
pipeline that we have been working on. From the top menu, click Variables.
8. In the left-hand pane, click Variable Groups.

Variable groups are linked to pipelines, rather than being directly added to them.
9. Click Link variable group , then in the Link variable group pane, click to select the Website Test
Product Details variable group (notice that it shows you how many variables are contained), then in
the Variable group scope, select the Development, Test Team A, and Test Team B stages.
We need the test product for development and during testing but we do not need it in production. If it
was needed in all stages, we would have chosen Release for the Variable group scope instead.
10. Click Link to complete the link.
The variables contained in the variable group are now available for use within all stages except Produc-
tion, just the same way as any other variable.
Integrate Secrets with the release pipeline 389
Integrate Secrets with the release pipeline

Integrate Secrets with the release pipeline
When you deploy your applications to a target environment, there are almost always secrets involved.
●● Secrets to access the target environment (servers, storage accounts)
●● Secrets to access resources (connections strings, tokens, username/passwords)
●● Secrets that your application uses (config files)
When your software is packaged as an artifact and moves through the different stages, secrets need to
inserted during the execution of the pipeline. Mainly because secrets (should) differ between stages and
environments but, just as important, secrets should NEVER be part of your source control repository.
There are different ways to deal with secrets in your pipelines. In this chapter, we walk through some
options.
Using Service Connections

A Service Connection is a securely stored configuration of a connection to a server or service. By using
this Service Connection, the pipeline tasks can execute securely against this endpoint. This way now
credentials or secrets are needed as part of the release pipeline.
For more information, see Service Connections34.
Using secret variables

A straightforward and convenient way to add secrets to your pipeline is the use of secret variables. Earlier
in this chapter we covered variables. By making the variable secret, it is hidden from view in all log files
and unrecoverable.
Secret variables are often used to store secrets, connection strings and are used as replacement values in
the pipeline. By creating placeholders in a target file, and replacing the placeholder with the real value in
the pipeline, you create a secret free repository.
For more information, see Define variables35.
Storing secrets in a key vault

Another option of securing passwords and secrets is using a Keyvault. This is an excellent option because
it allows you to keep the secrets outside of the pipeline and be able to retrieve them in another way (if
you have the appropriate rights).
Retrieve with a variable group

To make use of this option within your build and release pipelines you need to create a variable group
that refers to this KeyVault.
For more information, see Add & use variable groups36.
34 https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=vsts
35 https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts
36 https://docs.microsoft.com/en-us/vsts/build-release/concepts/library/variable-groups?view=vsts#link-secrets-from-an-azure-key-vault-as-
variables
Accessing Keyvault from within the pipeline

You can also access Keyvault variables without a variable group by using the dedicated build task.
Demonstration Setting Up Pipeline Secrets

In this demonstration, you will investigate Pipeline Secrets.
Steps
Let's now take a look at how a release pipeline can make use of the secrets that it needs during deploy-
ment.
In the walkthrough on variable groups, you saw that variable groups can work in conjunction with Azure
Key Vault.
1. In the Azure Portal, in the key vault (that was set up in the pre-requisites section) properties, in the
Secrets section, create the following secrets using the +Generate/Import option with an Upload
option of Manual.
Adding secrets by using an Azure Key Vault task in a stage

There are several ways that secrets from an Azure Key Vault can be used. The first option is to add an
Azure Key Vault task to a stage.
2. In Azure DevOps, in the main menu for the Parts Unlimited project, click Pipelines, then click
Releases, then click Edit to open the editing screen for the release pipeline that was created in earlier
walkthroughs.
3. From the Tasks drop down list, click Development to open the tasks editor for the Development
stage.
No tasks have been defined as yet.

4. Click the + sign to the right hand side of Agent job to add a new task. In the Search box, type vault.
5. Hover over the Azure Key Vault task and when Add appears, click it, then in the task list, click the
Azure Key Vault task to open its settings.
We can use the same service connection that was used in earlier walkthroughs.
6. Set Display name to the name of your key vault, and from the Azure subscription drop down list,
select ARM Service Connection. In the Key vault drop down list, select your key vault.
The Secrets filter can be used to define which secrets are required for the project. The default is to bring
in all secrets in the vault. It will be more secure to restrict the secrets to just those that are needed.
7. In the Secrets filter, enter database-login,database-password.
8. Click Save then OK to save your work.

The secrets can now be used like any other variables. You can reference them as $(database-login) and
$(database-password) when configuring tasks.
Adding secrets by using variable groups

Another way to configure Azure Key Vault secrets is by linking them to variable groups.
9. Click Remove to remove the Azure Key Vault task, then click Save and OK.
10. In the main menu, click Pipelines, then Library. The existing variable group is shown.
11. Click +Variable group to add a new variable group.
12. Click Link secrets from an Azure key vault as variables. In the Azure subscription drop down list,
click ARM Service Connection, and from the Key vault name drop down list, select your key vault.
Note the warning that appears. Any service principal that needs to list secrets or get their values, needs
to have been permitted to do so, by creating an access policy. Azure DevOps is offering to configure this
for you.
13. Click Authorize to create the required access policy.
Note: you will be required to log on to Azure to perform this action
The warning should then disappear.
14. Click +Add to start to add the secrets.
15. Click to select both database-login and database-password secrets, then click Ok.
16. Click Save to save the variable group.

17. In the main menu, click Pipelines, then Releases, then Edit to return to editing the release pipeline.
Click Variables, then Variable groups, then Link variable group.
18. In the Link variable group pane, click to select Database Credentials, then from the Stages drop
down list, select Production.
19. Click Link to link the variable group to the Production stage of the pipeline. Click the drop down
beside Database Credentials so that you can see the variables that are now present.
20. Click Save then OK.

An important advantage of using variable groups to import Azure Key Vault secrets, over adding the
Azure Key Vault task to a stage, is that they can be scoped to more than one stage in the pipeline, and
linked to more than one pipeline.
Configure Automated Integration and Func-

tional Test Automation
Introduction
The first thing that comes to mind when talking about Continuous Delivery is that everything needs to be
automated. Otherwise, you cannot deploy multiple times a day. But how to deal with testing then? Many
companies still have a broad suite of manual tests that need to run before delivering to production.
Somehow these tests need to run every time a new release is created.
Instead of automating all your manual tests into automated UI tests, you need to rethink your testing
strategy. As Lisa Crispin describes in her book Agile Testing, you can divide your tests into multiple
categories.
>source: http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
We can make four quadrants where each side of the square defines what we are targeting with our tests.
●● Business facing, meaning the tests are more functional and most of the time executed by end users of
the system or by specialized testers that know the problem domain very well.
●● Supporting the Team, means it helps a development team to get constant feedback on the product so
they can find bugs fast and deliver a product with quality build in
●● Technology facing, means the tests are rather technical and non-meaningful to business people. They
are typical tests written and executed by the developers in a development team.
●● Critique Product, are tests that are there to validate the workings of a product on it’s functional and
non-functional requirements.
Now we can place different test types we see in the different quadrants.
e.g., we can put functional tests, Story tests, prototypes and simulations in the first quadrant. These tests
Configure Automated Integration and Functional Test Automation 399
are there to support the team in delivering the right functionality and are business facing since they are
more functional.
In quadrant two we can place tests like exploratory tests, Usability tests, acceptance tests, etc.
In quadrant three we place tests like Unit tests, Component tests, and System or integration tests.
In quadrant four we place Performance tests, load tests, security tests, and any other non-functional
requirements test.
Now if you look at these quadrants, you can see that specific tests are easy to automate or are automat-
ed by nature. These tests are in quadrant 3 and 4
Tests that are automatable but most of the time not automated by nature are the tests in quadrant 1
Tests that are the hardest to automate are in quadrant 2
What we also see is that the tests that cannot be automated or are hard to automate are tests that can be
executed in an earlier phase and not after release. This is what we call shift-left where we move the
testing process more towards the development cycle.
We need to automate as many tests as possible. And we need to test as soon as possible. A few of the
principles we can use are:
●● Tests should be written at the lowest level possible
●● Write once, run anywhere including production system
●● Product is designed for testability
●● Test code is product code, only reliable tests survive
●● Test ownership follows product ownership
By testing at the lowest level possible, you will find that you have a large number of tests that do not
require infrastructure or applications to be deployed. For the tests that need an app or infrastructure, we
can use the pipeline to execute them.
To execute tests within the pipeline, we can run scripts or use tools that execute certain types of tests. On
many occasions, these are external tools that you execute from the pipeline, like Owasp ZAP, SpecFlow,
or Selenium. In other occasions, you can use test functionality from a platform like Azure. For example
Availability or Load Tests that are executed from within the cloud platform.
When you want to write your own automated tests, choose the language that resembles the language
from your code. In most cases, the developers that write the application should also write the test, so it
makes sense to use the same language. For example, write tests for your .Net application in .Net, and
write tests for your Angular application in Angular.
To execute Unit Tests or other low-level tests that do not need a deployed application or infrastructure,
the build and release agent can handle this. When you need to execute tests with a UI or other special-
ized functionality, you need to have a Test agent that can run the test and report the results back.
Installation of the test agent then needs to be done up front, or as part of the execution of your pipeline.
Setting up Test Infrastructure

Installing the test agent
To execute tests from within the pipeline, you need an agent that can run these tests. An agent can run
on another machine and can be installed as part of the pipeline.

Bloque2 - Az 400t00a Enu Trainerhandbook PDF Free

Uploaded by

Copyright:

Available Formats

Bloque2 - Az 400t00a Enu Trainerhandbook PDF Free

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bloque2 - Az 400t00a Enu Trainerhandbook PDF Free

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

Implement Secure and Compliant Develop-

There are five major threat modeling steps:

Microsoft Threat Modeling Tool

●● Suggest and manage mitigations for security issues.

Demonstration Threat Modeling

Key Validation Points

IDE / Pull Request

Application Deployment to Dev and Test

Results and Bugs

Rethinking Application Config Data

A ray of hope: The DevOps movement

External Configuration Store pattern

This pattern is useful for:

Integrating Azure Key Vault with Azure Pipeline

Manage Secrets, Tokens, and Certificates

Why use Azure Key Vault?

Securely store secrets and keys

Monitor access and use

Simplified administration of application secret

Integrate with other Azure services

DevOps Inner and Outer Loop

Kubernetes and Azure Key Vault

Why not just use Kubernetes you may ask?

Mapping the above diagram to our roles and responsibilities earlier:

// add azure key vault configuration using environment variables

// get the key vault uri

#add a new secret to keyvault

Kubernetes is the Configuration Store and serves multiple purposes here:

- containerPort: 80 #map to port 80 in the docker container

Implement Tools for Managing Security and

Implement Continuous Security Validation

Securing Infrastructure with AzSk

Scanning Azure Resource Manager (ARM) Templates for

Scanning Azure Resources for best practices

Now review the detailed logs from the inspection…

Azure Policy and Governance

Module Review and Takeaways

What are the five stages of threat modeling?

Why would you use WhiteSource Bolt?

Managing Code Quality

Measuring and Managing Quality Metrics

Common quality-related metrics

Technical Debt Defined

Sources and Impacts of Technical Debt

Using Automated Testing to Measure Technical

Automated Measurement for Monitoring

Discussion - Code Quality Tooling

Measuring and Managing Technical Debt

Integrating Other Code Quality Tools

Resharper Code Quality Analysis

Search in Azure DevOps

For more information, you can see:

Planning Effective Code Reviews

Managing Security Policies

Planning to Implement OWASP Secure Coding

Inspecting and Validating Code Bases for Com-

Open Source Licensing Challenges

Discussion - Security Policy Tooling