Episode 143 – Azure Pipelines 1


In this episode we talk about Azure Pipelines.



  • 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




“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved


Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast!
Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!


Please Consider Sharing This Post: