Before we get started with some hands-on exercises, we need to cover some general concepts. A release is a package that holds a versioned set of artifacts specific to your release pipeline. All the information needed to execute the tasks are stored in the release pipeline and are included from the stages, variables, triggers through to approvers and release gates. There can be multiple releases for one release pipeline.

An important distinction is understanding the difference between the release and the deployment. A release is talking about implementation of a new feature or a change to an existing system in the way it works. A deployment is pushing the code into a new environment. This distinction is also referred to as separating your functional release (or feature release) from your technical release (deployment to an environment). These two things often get mixed together because they are tightly coupled together in the release process.

Many of the tools and programs you will use do not exist within the Azure DevOps environment. To access these services, you will need to create services connections. You may have already created some of these but here is a list of commons service connections. Each service connection will have the specific parameters needed to create connect to that service.

An artifact is content required to deploy your application or infrastructure. The process is to build, collect, or create the content once and then release or deploy that same content over and over again. This is done by ensuring that the base artifacts don't change, if it changes how can we guarantee a consistent result? Here is the list of artifact sources and depending on your purpose or project you may choose different sources, there is no one right answer.

Looking over these sources there are some general types we can consider. There are builds where a build pipeline creates a package that is versioned and stored where the contents can't be changed. There are version control solutions, where the release pipelines pull code and packages directly from source control. There are container registries, that allow you to pull a specific version of a container helping with deployment consistency.

This list will obviously change over time, but the important thing to remember is the goal of this style of deployment is to create a consistent deployment that you can rely on. To achieve this, the source artifact you need to select needs to be stable. The only thing that should be changing when you deploy to a new environment is the configuration. The 'thing' you are deploying should never change.

An important consideration is what type of auditing do you need to provide for these source artifacts? As more layers are added, it often becomes more important to know what line of code changed and who checked in the code, or merged that branch. There are many tools and techniques out there to help with code in relation to version control but each organization needs to implement their own process around what they need to do and what to release.

Environments define collection of resources such as Kubernetes namespaces, Web Apps, VMs, or databases that can be targeted by deployments from a pipeline. Typical examples of environments include Dev, Test, Staging, and Production. Some benefits of using environments are that you can view deployment history by environment, users permissions, resource health, or traceability for tracking work items or tasks against an environment.

A deployment stage is a logical representation of somewhere you want to release your artifacts to, some easy examples are dev, test, or production. A key aspect of a stage is the boundaries of a stage. Each stage should be independent from each other, meaning you can release code independently to that stage. Depending on what you're deploying, this will also help define your boundaries.

With modern cloud platforms and PaaS services we can now define infrastructure as code or IAC. We can now define infrastructure that can be versioned and deployed along with the applications, for example, using ARM templates to build out network load balancers, virtual machines in Azure or even Kubernetes using AKS. Leveraging this power means a deployment stage can be completely torn down and rebuilt to ensure the source artifacts or package truly contain all the content and that our release contains all the configuration to ensure the solution is fully deployable.

Now that we have covered some fundamental concepts, let's take a look at the prerequisites needed to work through our lab. We are going to create one pipeline, containing four stages, we're going to use a GitHub project for our Azure infrastructure as code, we're going to use an HTML project as the website. By the end of this lab, we will be able to trigger a deployment simply by checking in a change to the HTML code or completing a pull request.