For the book updates and community contributions

Environments 
Now that you’ve published an artifact that’s 
potentially deployable
, you’ll add 
deployment
jobs to the 
workflow. There’s nothing special about a deployment job, other than the fact that it references an 
environment
. Environments are 
logical
constructs that allow you to specify environment protection 
rules, such as approvals, on any group of resources that you’re targeting.
In this walkthrough, you’ll be deploying to two environments: PRE
-PROD and PROD. In a typical 
development lifecycle, you’ll want to depl
oy the latest code to a 
soft
environment (typically DEV) that 
is expected to be a bit unstable. You’ll use PRE
-PROD as this 
soft
environment. The “higher” 
environments (like UAT and PROD) are 
harder
environments that are expected to be more stable. To 
enfo
rce this, you can build protection rules into higher environments. You’ll configure an approval 
protection rule on the PROD environment: whenever a deployment job targets an environment with 
an approval rule, it will pause until approval is granted before executing. 

---

49 
CHAPTER 3 | Continuous integration and deployment with Azure DevOps 
GitHub environments are 
logical
. They represent the physical (or virtual) resources that you’re 
deploying to. In this case, the PRE-PROD is just a deployment slot on the Azure Web App. PROD is the 
production slot. The PRE-PROD deployment job will deploy the published .NET app to the staging 
slot. The PROD deployment job will swap the slots. 
Once you have these steps in place, you’ll update the workflow to handle environment
-specific 
configuration using environment secrets. 
Note 
For more information, see 
GitHub Actions - Environments
.