The 6 Figure Developer Podcast

Episode 143 – Azure Pipelines

May 11 '20

In this episode we talk about Azure Pipelines.

Definitions

What is a pipeline
- Chain of repeatable actions/tasks that transform some input into some output. Its like a function chain.
Types of pipelines
- Build Pipeline
  - This pipeline takes the source code as input and produces deployable artifacts as the output.
  - It may also do some unit testing, linting and static analysis to the code to check the validatiy of the output artifacts.
- Release Pipleline
  - This pipeline takes the deployable artifacts as input and produces deployed environments as outputs.
  - It may also perform some automated integration tests to test the validity of the deployment
Continuous Integration (CI)
- This is the practice of merging the small batches of developer changes into the main branch continuously instead of all at once at the end of a development cycle.
- This is facilitated by a good build pipeline.
- For good or worse CI Pipeline and Build Pipeline are often conflated
Continuous Delivery (CD)
- This is the practice of automatically deploying an artifact to an environment as soon as the artifact is created.
- This does not mean that the environment production.
- This is facilitated by a good release pipeline
- For good or worse CD Pipeline and Release Pipeline are often conflated
CI/CD
- This is when we combine the practice of Continuous Integration with the practice of Continuous Delivery
Continuous Deployment
- This is the practice of extending the automatic deployment of an artifact through all stages until is automatically deployed to production.
- This requires one or more good release pipelines
- It often gets confused with Continious Delivery. It is Continuous Delivery but Continuous Delivery is not Continuous Deployment.

Azure DevOps Products

Azure DevOps
- A suite of development tools
Azure Pipelines
- Tool for building out the build and release pipelines
- Alternates Jenkins, Octopus, TeamCity, Circleci, GitLab
- Excellent GitHub and Azure DevOps Repos integration, but can connect to other remote repositories
- Excellent Azure integration, but can deploy into most any platfor or environment.
- Linux, macOS and Windows adjents
- Supports most lanuages
- Free for Open Source (10 parallel jobs unlimited minutes)
- First agent free for closed source

Before Creating a Pipeline

Consider your branching strategy
- Recommend, Trunk-based Strategy
  - Team shares single trunk (master) that all development is based off of.
- Release Flow

Creating a Build Pipeline

YAML vs Classic
- Recommend, YAML uses a yaml config stored in the source code repository to define the build pipeline.
- Classic is good for learning the platform and can be used to figure out the correct yaml.
trigger
- Recommend, based on changes to specified branchs
  - can include or exclude files and folders within the branch
- can be triggered on a timed schedule
define jobs
- a job us run on an agent and has its own variables and copies of source code etc.
- jobs can be completed in parallel
define steps in jobs
- steps are the collection of steps/tasks that a given job will run
define the task in step
- each step is a task
- this will be the heart of your build pipeline and will depend largely on what you are building
variables
- you may want to specify some variables across jobs, like version number
pools
- you many want to specify the type of agent to use by default instead of in every job definition

Creating a Release Pipeline

Classic
- The “only released” method for creating a release pipeline is the classic method
- You could create a yaml build pipeline that performed the release tasks but triggers might be more challenging.
- Recommend, There are some other options in pre-release.
select artifacts
- this will likely come from artifacts published from a build pipeline
define (release) trigger
- recommend, set continuous when an artifact is avaible
- can be triggered on a timed schedule
define a stage
- define (stage) trigger
- define stage tasks
  - this is the heart of your release pipeline and will depend largely on what you are deploying to
Classic stores your release definition in a source control but not managed by you.
Think of every environment as a stage
Releases are created but that does not mean the artifacts are deployed to an environment. The stage completes that deployment to the environment
If you change the release pipeline definition you will need to create a new release to follow the new changes

Multi-Stage Pipeline

Pre-release feature, well supported and pretty feature full but not complete
GearGuy (next to login avatar) > Preview Features > Multi-stage pipelines
This combines your build and release pipelines
They are all defined by a single yaml config in your source code repo
Follow similar steps to building a deployment pipeline however, add stages.
usually the entire build pipeline would be contained within a single stage
then just like in classic release pipelines each environment would be a stage.
the same job, steps, tasks organization exists within every stage
the heart of every stage is at the task level
A release is created every time pipeline is triggered (likely every code change)
stages can be rerun within a given release