Azure Pipelines is a Cloud service that lets users automatically build and test the code project by incorporating continuous delivery and continuous integration approach. Meaning - it allows development teams to consistently test and build the code, and when the project is completed, it automatically ships it to the target.
Agent: Every time you run a build or deployment, the system automatically launches one or more jobs. These jobs are processed by an agent that is installed as agent software. For example, a job could run on a Microsoft-hosted Ubuntu agent.
Approvals: Before running a deployment, certain approvals are required. Like a manual approval, a check is done to control the deployment to the production environments. Once these checks are configured on an environment, pipelines cease the deployment to the environment until all the checks are done 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.
Here is a list of supported Artifacts in Azure Pipelines:
Continuous Delivery: It’s a process that lets your code to the production stage after passing various stages like building, testing, deploying it for further testing. Continuous integration systems produce deployable artifacts that are consumed by the automated release pipelines so that the new versions can be released or the existing system can be fixed. Such dedicated monitoring or alerting is constantly visible into the entire process and ensures errors are caught early and quality can be achieved.
Continuous Integration: This process simplifies the testing and building of the code. With the help of CI, development teams can identify and fix bugs early in the development cycle. And Automated tests and builds assist the CI process to do that. The CI process also produces artifacts that are used by the continuous delivery pipelines to do automatic deployments.
Deployment Group: These groups are indicated as deployment target machines where agents are installed. In other words, these groups are known as groups or pools of agents. Using a deployment group you can set the deployment targets in a pipeline that is also referred to as a job.
Environment: It’s a collection of resources used to deploy the application. These resources can contain one or more virtual machines, containers, web apps, or any service that is used to host the application. The role of the pipeline is to deploy the application in one or more environments once the build is complete and ready for the tests.
Job: A stage consists of one or more jobs where each job runs on an agent and acts as an execution boundary for a set of steps. All of the steps run simultaneously on the same agent. For instance, if you build two configurations: x86 and x64. Now it will be understood that you have built one stage and two jobs.
Pipeline: This process defines the continuous integration and deployment of your application. It includes one or more stages. In simple words, pipelines are the workflows for your application where you define how you would build, test, and deploy your application including the number of steps required to complete the steps.
Run: Single time execution of a pipeline means a run. It collects the logs related to running the steps and the results of running tests. During a run, Azure pipelines process the pipeline and send the run to one or more agents, and each agent runs jobs.
Script: It runs a custom code as a step specifically in your pipeline using the command line, PowerShell, or Bash. To run code on cross-platform like macOS, Linux, and Windows, you need to write cross-platform scripts.
Stage: It is a logical boundary in the pipeline used to mark the separation of concerns like Build, QA, and production. Each stage contains one or more jobs and once you define multiple stages in a pipeline, each stage runs one after the other based on the conditions defined for a particular stage.
Step: It is the smallest building block of a pipeline and it can be either a script or a task. For example, a pipeline might have various build and test steps.
Task: It’s a prebuilt, packaged script or procedure that has been abstracted with a set of inputs that provides convenience to you. It is the building block for defining automation in a pipeline.
Trigger: It’s a kind of setup to signal the pipeline when to run. As you configure a pipeline, you can decide whether a pipeline would run upon a push to a repository, at scheduled times, or after the completion of another build. And all these actions are known as triggers.
Progressive Deployment: In Azure Pipelines, you can define any number of stages during the development and testing process. The biggest advantage of defining many stages during a process gives you better control over the project, and transition from one step to another becomes so easy. Plus, the development team can find bugs, address issues in a much better way. All in all, throughout the project, you remain in full control.
Multiple-Cloud Capabilities: Azure Pipelines doesn’t restrict the Cloud deployment to a single Cloud. You get plenty of options as to when and where you want to deploy.
Virtual Machine Features: Using Azure Pipelines, you can access both traditional virtual machine managers and more advanced Deployment Groups. These Deployment groups consist of target machines with individual agents, and help you:
Free Offerings: Azure Pipelines extends support to open source projects in the form of unlimited minutes or up to 10 parallel jobs at no cost. Users who are already using Github Repos can easily integrate a CI/CD pipeline using Azure Pipeline.
Azure pipelines give agility and help you deliver software at a fast pace, and at the same time ensure software quality. Of all the features that make this service incredible is its compatibility with multiple languages, environments, and repositories. Its simple continuous delivery experience with a flexible environment helps you scale easily.