Azure Pipeline

Introduction: This article is a continuation of the series of articles starting with the description of SignalR service which was followed by a discussion on Azure Gateway service, Azure Private Link, and Azure Private Endpoint and the benefit of diverting traffic to the Azure Backbone network. Then we started reviewing a more public internet-facing service such as the Bing API. and the benefits it provided when used together with Azure Cognitive Services. We now focus internally with infrastructure API such as Provider API and ARM resources and follow it up with a discussion on the Azure Pipeline. 

Description:    

Azure Pipeline provides the opportunity to allow code to move quickly. Their tools deliver value faster and more transparently. Some customization is inevitable depending on the business purpose of the software, but most pipelines can do with out-of-box features. 

Azure services are fully managed services. Their dependencies, build, test and deployment logic can be quite large, but they are handled very well by the parameters, triggers, jobs, tasks, and stages in a pipeline once the artifacts are generated or become available.

For example, to deploy software to millions of devices, the following steps can be taken. First, the Build module images, and the Push module images task can be edited so that the modules are available in the edge solution. Second, the modules can be built and pushed to Azure Container Registry. Third, the deployment manifests can be uploaded to say an IoT Hub. Finally, the edge devices can get the deployment and pull images from Azure Container Registry.

The targets are one example of how flexible and critical the Azure Pipeline is but there are others.  YAML files can be authored to take advantage of multiple channels. It is also possible to integrate with other CI/CD workflows and a wide range of tasks can be enabled with extensions. Some extensions for common use cases are already available. Some ecosystem support can be enumerated as the support to automatically build and test .NET Core projects, build test and deploy Node.js applications, Python, Java, Go, PHP, and GitHub Actions.

Applications can be built on multiple branches and CI trigger can be created for a topic branch, multiple platforms can be built, pipeline artifacts can be published at any stage, service containers can be used, cross platform scripts can be executed. PowerShell script with the use all Azure and desktop cmdlets can be written, Git commands can be run, the build time can be reduced using caching. Build runs and versions can be incremented, and tasks can be used to increase retention. These are just some of the examples in which the pipeline can be sued.

Conclusion: These are the ways in which the Azure Pipeline can be used, and it is available as just another cloud resource along with the benefits that come with a cloud service.