Azure DevOps Pipelines

Azure DevOps Pipelines provides you the options to do your CI builds for any platform and any tool or language. Azure DevOps Pipelines provides a web interface where you can create jobs that contains steps that need to take place in order to create a production artifact for your software. That can be compiling C++ code, compiling Go, Ruby, Node, .NET, Java, you name it. 

Of course, the build automation pipelines allow you yo trigger from any external repository like GitHub, SVN, or your local Get server, or it can of course integrate with the Azure DevOps repositories. The triggers will then fire the build according to the definition you created.

Besides build automation, Azure DevOps also provides deployment automation. In the market, you see the people use with this Jenkins, XebiaLabs with XL Deploy and Release, Octopus Deploy, or other tools. The deployment automation is a deployment tool and infrastructure that lets you deploy any software on any platform. Please don't let the name Azure DevOps fool you, because it will not be tied into the Azure Cloud. You can very easily deploy to the Google Cloud, AWS, or on your on-promises services in many different ways. 

With the build automation and deploy automation, you can now realize both continuous integration and continuous delivery for deployment. When you use the whole suit of products, so you use the boards to track the work, the repos to track the work and the version control system, and when you also use the build and release tools, you will get full tractability out of box. This is great for compliance. With Azure DevOps it is very easy and doable.

Of course, if you prefer to use other tools, you can all plug them into the integration points that are available.

• Build Automation
• Continuous Integration
• Deployment Delivery
• Continuous Delivery
• Traceability and Compliance
• Hooks for other products

• The Pipeline defines the stages
• A stage contains jobs
• A Job runs on an Agent Or is "Serverless"
• An Agent is the process where all work is done

Jobs, Steps, Tasks, Scripts, and Triggers

When we look at the stage, then this is normally something called like a CI stage or staging or acceptance or a production stage.

A stage has one or more jobs, and that defines the steps that need to be executed on the agent. So the job contains steps, and a step is either a script that you want to run on the agent machine or it is a task that you installed in your Azure DevOps instance. Out of the box, there are already quite some tasks that you can choose from, but you can also install them from the Azure Marketplace.

• A Stage has one or more Jobs
• A Job defines the steps that need to be run in the same execution environment (agent)
• A Job contains Steps
• A Step is either:
  • A script you run
  • A task you use that is installed in your Azure DevOps instance

Task

The task is a building block for any automation in your pipeline.

Stages and jobs are more an orchestration concepts around these steps. The task is a package of software that will take care of what the step can do. It will be downloaded to the agent, and the task will have an entry point that will be called when executing the task.

There are built‑in tasks, and you can install your own. Also good to know is that a task has a version. This version is designated with the at sign.

Example:

steps:

    script: date /t

    displayName: Get the date

    script: dir

    workingDirectory: $(Agent.BuildDirectory)

    displayName: List contents of a folder

    script: |

        set MYVAR=foo

        set 

    displayName: Set a variable and then display all

    env:

        aVarFromYaml: comeValue

Trigger

A trigger is something that's set up to tell the pipeline when to run. You can cinfigure a pipeline to run upon a push to a repository, at scheduled ties, or upon the completion of another build.

• Pipeline triggers

• Build Completion triggers

Example:

schedules:

    cron: string # cron syntax defining a schedule

    displayName: string # friendly name given to a specific schedule

    branches:

        include: [string] # which branches to schedule applies to

        exclude: [string] # which branches to exlude from the schedule