Podcast: Play in new window | Download (Duration: 31:38 — 22.0MB)
Subscribe: Apple Podcasts | Google Podcasts | Spotify | Stitcher | Podchaser | Email | TuneIn | RSS
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
- Build Pipeline
-
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
- Recommend, Trunk-based Strategy
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
- Recommend, based on changes to specified branchs
-
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
Resources
https://azure.microsoft.com/en-in/overview/continuous-delivery-vs-continuous-deployment/
https://trunkbaseddevelopment.com/
https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml
https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops
“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved
An International Speaker, Author, and Microsoft MVP, John has been a professional developer since 1999. He has focused primarily on web technologies and currently focuses on C# and .NET Core in Azure. Clean code and professionalism are particularly important to him, as well as mentoring and teaching others what he has learned along the way.
Please Consider Sharing This Post:
