Home | Applications | Documentation | Transport | Personal |

Documentation

Home | Cloud | C# | Database | DevOps | Revision | Web |

DevOps | Repos | Pipelines | Boards |

Pipelines (Workflow)

Introduction

Pipelines controls the Continuous Intergration, Continous Delivery and Continuous/Push Deployments in DevOps. These are called Workflows in GitHub. GitHub does allow you to use Azure yaml. So YAML so this will be the main feature of this page.

To find the pipelines(workflows) page in GitHub, go to the Actions tab.

Create your first JavaScript pipeline in Devops

1. Sign in to your Azure DevOps organization and navigate to your project.

2. In your project, navigate to the Pipelines page. Then choose the action to create a new pipeline.

3. Walk through the steps of the wizard by first selecting GitHub as the location of your source code.

4. You might be redirected to GitHub to sign in. If so, enter your GitHub credentials.

5. When the list of repositories appears, select your Node.js sample repository.

6. Azure Pipelines will analyze the code in your repository and recommend Node.js template for your pipeline. Select that template.

7. Azure Pipelines will generate a YAML file for your pipeline. Select Save and run, then select Commit directly to the main branch, and then choose Save and run again.

8. A new run is started. Wait for the run to finish.

When you're done, you'll have a working YAML file (azure-pipelines.yml) in your repository that's ready for you to customize.

Create your first JavaScript workflow in GitHub

1. Sign in to your GitHub page and navigate to your actions.

2. In your actions, navigate to the Workflow page. Then choose the action to create a new workflow.

??? Walk through the steps of the wizard by first selecting GitHub as the location of your source code.

??? You might be redirected to GitHub to sign in. If so, enter your GitHub credentials.

??? When the list of repositories appears, select your Node.js sample repository.

??? Azure Pipelines will analyze the code in your repository and recommend Node.js template for your pipeline. Select that template.

??? Azure Pipelines will generate a YAML file for your pipeline. Select Save and run, then select Commit directly to the main branch, and then choose Save and run again.

??? A new run is started. Wait for the run to finish.

??? When you're done, you'll have a working YAML file (azure-pipelines.yml) in your repository that's ready for you to customize.

Key concepts for new Azure Pipelines users

Learn about the key concepts and components that make up a pipeline. Understanding the basic terms and parts of a pipeline can help you deliver better code more efficiently and reliably.

Key concepts overview

  • A trigger tells a Pipeline to run.
  • A pipeline is made up of one or more stages. A pipeline can deploy to one or more environments.
  • A stage is a way of organizing jobs in a pipeline and each stage can have one or more jobs.
  • Each job runs on one agent. A job can also be agentless.
  • Each agent runs a job that contains one or more steps.
  • A step can be a task or script and is the smallest building block of a pipeline.
  • A task is a pre-packaged script that performs an action, such as invoking a REST API or publishing a build artifact.
  • An artifact is a collection of files or packages published by a run.

Azure Pipelines terms

Agent
When your build or deployment runs, the system begins one or more jobs. An agent is computing infrastructure with installed agent software that runs one job at a time. For example, your job could run on a Microsoft-hosted Ubuntu agent.

Approvals
Approvals define a set of validations required before a deployment runs. Manual approval is a common check performed to control deployments to production environments. When checks are configured on an environment, pipelines will stop before starting a stage that deploys to the environment until all the checks are completed successfully.

Artifact
An artifact is a collection of files or packages published by a run. Artifacts are made available to subsequent tasks, such as distribution or deployment.

Continuous delivery
Continuous delivery (CD) is a process by which code is built, tested, and deployed to one or more test and production stages. Deploying and testing in multiple stages helps 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 existing systems. Monitoring and alerting systems run constantly to drive visibility into the entire CD process. This process ensures that errors are caught often and early.

Continuous integration
Continuous integration (CI) is the practice used by development teams to simplify the testing and building of code. CI helps to catch bugs or problems early in the development cycle, which makes them easier and faster to fix. Automated tests and builds are run as part of the CI process. The process can run on a set schedule, whenever code is pushed, or both. Items known as artifacts are produced from CI systems. They're used by the continuous delivery release pipelines to drive automatic deployments.

Deployment group
A deployment group is a set of deployment target machines that have agents installed. A deployment group is just another grouping of agents, like an agent pool. You can set the deployment targets in a pipeline for a job using a deployment group. Learn more about provisioning agents for deployment groups.

Environment
An environment is a collection of resources, where you deploy your application. It can contain one or more virtual machines, containers, web apps, or any service that's used to host the application being developed. A pipeline might deploy the app to one or more environments after build is completed and tests are run.

Job
A stage contains one or more jobs. Each job runs on an agent. A job represents an execution boundary of a set of steps. All of 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 stage and two jobs.

Pipeline
A pipeline defines the continuous integration and deployment process for your app. It's made up of one or more stages. It can be thought of as a workflow that defines how your test, build, and deployment steps are run.

Run
A run represents one execution of a pipeline. It collects the logs associated with running the steps and the results of running tests. During a run, Azure Pipelines will first process the pipeline and then send the run to one or more agents. Each agent will run jobs. Learn more about the pipeline run sequence.

Script
A script runs code as a step in your pipeline using command line, PowerShell, or Bash. You can write cross-platform scripts for macOS, Linux, and Windows. Unlike a task, a script is custom code that is specific to your pipeline.

Stage
A stage is a logical boundary in the pipeline. It can be used to mark separation of concerns (for example, Build, QA, and production). Each stage contains one or more jobs. When you define multiple stages in a pipeline, by default, they run one after the other. You can specify the conditions for when a stage runs.

Step
A step is the smallest building block of a pipeline. For example, a pipeline might consist of build and test steps. A step can either be a script or a task. A task is simply a pre-created script offered as a convenience to you. To view the available tasks, see the Build and release tasks reference. For information on creating custom tasks, see Create a custom task.

Task
A task is the building block for defining automation in a pipeline. A task is packaged script or procedure that has been abstracted with a set of inputs.

Trigger
A trigger is something that's 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 the completion of another build. All of these actions are known as triggers.

Understanding YAML

Configuration as Code

My notes on pipelines, to be checked
Create a pipeline project
Attach to the Github/Repos source code
This creates a Pipeline in YAML (build pipeline)
This creates a build, but doesn't deploy anything
This is triggered by change to the Master branch
You can create a Pipeline Release
This will allow you to deploy the artifact created by the build
You can have many stages
Each stage can have many tasks

So how do you automatically run a release pipeline as it's the build pipeline that has the trigger. Also, how do you create a push deployment

I will create an App Service in Azure and try to deploy this website. Wish me lots of luck.