PipeLines - knowlesy/AZ400 GitHub Wiki

A delivery pipeline enables the flow of more minor changes more frequently, with a focus on flow.

Your teams can concentrate on optimizing the delivery of changes that bring quantifiable value to the business.

This approach leads teams to continuously monitor and learn where they're finding obstacles, resolve those issues, and gradually improve the pipeline's flow.

The deployment is automated, allowing for the reliable delivery of new functionality to users within minutes if needed.

These automated pipelines need infrastructure to run on. The efficiency of this infrastructure will have a direct impact on the effectiveness of the pipeline.

Continuous integration is used to automate tests and builds for your project. CI helps to catch bugs or issues early in the development cycle when they're easier and faster to fix. Items known as artifacts are produced from CI systems. The continuous delivery release pipelines use them to drive automatic deployments.

Continuous delivery is used to automatically deploy and test code in multiple stages to help drive quality. Continuous integration systems produce deployable artifacts, which include infrastructure and apps. Automated release pipelines consume these artifacts to release new versions and fixes to the target of your choice.

image

Agent When your build or deployment runs, the system begins one or more jobs. An agent is installable software that runs a build or deployment job.

Artifact An artifact is a collection of files or packages published by a build. Artifacts are made available for the tasks, such as distribution or deployment.

Build A build represents one execution of a pipeline. It collects the logs associated with running the steps and the test results.

Deployment target A deployment target is a virtual machine, container, web app, or any service used to host the developed application. A pipeline might deploy the app to one or more deployment targets after the build is completed and tests are run.

Job A build contains one or more jobs. Most jobs run on an agent. A job represents an execution boundary of a set of steps. All the steps run together on the same agent.

For example, you might build two configurations - x86 and x64. In this case, you have one build and two jobs.

Pipeline A pipeline defines the continuous integration and deployment process for your app. It's made up of steps called tasks.

It can be thought of as a script that describes how your test, build, and deployment steps are run.

Release When you use the visual designer, you can create a release or a build pipeline. A release is a term used to describe one execution of a release pipeline. It's made up of deployments to multiple stages.

Stage Stages are the primary divisions in a pipeline: "build the app," "run integration tests," and "deploy to user acceptance testing" are good examples of stages.

Task A task is the building block of a pipeline. For example, a build pipeline might consist of build and test tasks. A release pipeline consists of deployment tasks. Each task runs a specific job in the pipeline.

Trigger A trigger is set up to tell the pipeline when to run. You can configure a pipeline to run upon a push to a repository at scheduled times or upon completing another build. All these actions are known as triggers.

If your pipelines are in Azure Pipelines, then you've got a convenient option to build and deploy using a Microsoft-hosted agent.

Each time a pipeline is run, a new virtual machine (instance) is provided. The virtual machine is discarded after one use.

With a Microsoft-hosted agent, maintenance and upgrades are automatically done.

Agent pool jobs The most common types of jobs. The jobs run on an agent that is part of an agent pool.

Container jobs Similar jobs to Agent Pool Jobs run in a container on an agent part of an agent pool.

Deployment group jobs Jobs that run on systems in a deployment group.

Agentless jobs Jobs that run directly on the Azure DevOps. They don't require an agent for execution. It's also-often-called Server Jobs.

Pools When creating a build or release pipeline, you can specify which pool it uses, organization, or project scope.

Pools scoped to a project can only use them across build and release pipelines within a project.

To share an agent pool with multiple projects, use an organization scope agent pool and add them in each of those projects, add an existing agent pool, and choose the organization agent pool. If you create a new agent pool, you can automatically grant access permission to all pipelines.

**Pre defined Pools ** The following virtual machine images are provided by default:

  • Windows Server 2022 with Visual Studio 2022.
  • Windows Server 2019 with Visual Studio 2019.
  • Ubuntu 20.04.
  • Ubuntu 18.04.
  • macOS 11 Big Sur.
  • macOS X Catalina 10.15.

image

When a newer version of the agent is only different in minor versions, it's automatically upgraded by Azure Pipelines.

This upgrade happens when one of the tasks requires a newer version of the agent.

If you run the agent interactively or a newer major version of the agent is available, you must manually upgrade the agents. Also, you can do it from the agent pools tab under your project collection or organization.

  • If you use a self-hosted agent, you can run incremental builds. For example, you define a CI build pipeline that doesn't clean the repo or do a clean build. Your builds will typically run faster.
  • You don't get these benefits when using a Microsoft-hosted agent. The agent is destroyed after the build or release pipeline is completed.
  • A Microsoft-hosted agent can take longer to start your build. While it often takes just a few seconds for your job to be assigned to a Microsoft-hosted agent, it can sometimes take several minutes for an agent to be allocated, depending on the load on our system.

Mara's going to map the existing script commands to Azure Pipelines tasks. A Pipeline is created using a YAML file, which is a compact format that makes it easy to structure the kind of data that's in configuration files. Pipeline YAML files are typically maintained directly with your app's source code.

Mara's used YAML previously to define similar build tasks and configurations. She also likes the idea of maintaining the build definition as code, just as she would any other part of her project.

To define her build, Mara chooses to use Visual Studio Code to create a YAML file. In it, she enters all the Azure Pipelines tasks that she'll use to replace the existing script commands.

Map script commands to Azure Pipelines tasks Now, you'll follow along as Mara maps commands from her script to Azure Pipelines tasks.

To map each command, Mara refers to the reference documentation. The documentation categorizes tasks by function, like build or deploy.

These elements are built-in variables that the system provides for use in your pipelines:

  • $(Build.DefinitionName) is the name of the build pipeline. For example, "SpaceGame-Web-CI."
  • $(Build.BuildId) is a numeric identifier for the completed build, like 115.
  • $(Build.BuildNumber) is the name of the completed build. You can configure the format, but by default, the build number includes the current date followed by the build number for that day. An example build number is "20190329.1."

To reference your own variables, use the $() syntax

variables: buildConfiguration: 'Release' wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot' dotnetSdkVersion: '6.x'

Code referencing

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)' displayName: 'Compile Sass assets'

A template lets you define common build tasks once and reuse those tasks multiple times.

You'll call a template from the parent pipeline as a build step. You can pass parameters into a template from the parent pipeline.

- template: templates/build.yml parameters: buildConfiguration: 'Debug'

- template: templates/build.yml parameters: buildConfiguration: 'Release'

Multi Platform

image image