What are Azure Pipelines? - Azure Tutorial

- [Instructor] Azure Pipelines is a set of services that automate your application build and deployment phases. This is Microsoft's continuous integration and continuous delivery system. Continuous integration, also known as CI, is the industry word that describes the process of automating the building and testing of code. In Azure DevOps, this is known as the build pipeline. Continuous delivery, also known as CD, is the industry word that describes the process of automating the deployment of the application which ensures the final product is made available to the customers. In Azure DevOps, this is known as the release pipeline. Build and release are two distinct phases which can be automated in various ways. In DevOps, it is common to automate both but that is not always the case. There are teams that automate the build but still deploy manually. Plus, it's possible to do the opposite, manual build, automated deploy. Before talking about continuous integration, let's examine the idea of code integration. This is a deep topic and historically has had many definitions. For our discussion, it means to integrate two versions of the app together by merging new code with existing code. Once the merge is complete, we need to test the integrated code to ensure that it works correctly. Obviously, testing the software by hand takes a lot of time, is repetitious, and is susceptible to human error. We solve the problems with human error by using a testing system that reliably runs all the tests in an easily repeatable fashion. And these testing systems are one part of the continuous integration system. Essentially, the workflow for updating the app code looks like this, whether you're doing a manual or automated process. First you commit your code changes. Then you merge the new code into the main app code base. Next, build the application which generates the executables and other essential files for desktop applications. Or in web apps, the build process will generate minified files and other site artifacts. Finally, test everything. Obviously doing this manually is possible, but it's better to automate. And that's what you get with build pipeline. The build process is customarily triggered when the code is committed into the version control system. There are many nuances to this process. Some teams like the immediacy of instant builds, meaning you trigger the build process with every code merge. Other teams prefer to consolidate the builds until the end of the day, the so-called nightly build. Azure pipeline supports both these scenarios. Your release pipeline is very specific to your application structure. For a simple example, consider a web application. Deployment can be as simple as copying the modified files to the production server, perhaps running in an Azure app service. For a more complex scenario, we might need to deploy a set of microservices, update the web front end, and make some database changes. A deployment system needs to be able to handle these diverse tasks in one pipeline. Continuous delivery supports other deployment patterns for web apps. Blue-green deployment is a technique to roll out site changes in a staggered cadence. Essentially there are two sites running at the same time, the previous blue version and the new green one. Typically, this uses load balancing to send increasing amounts of traffic to the green deployment. If site monitoring exposes trouble with the green build, traffic can be rerouted to the blue deployment. Feature flags are another technique that is used to experiment with new features. These flags are set in the deployment configuration. They enable your team to expose new functionality to different end users based on their identity and group membership. For a more complex scenario, think about how Microsoft builds and deploys the Windows 10 operating system. For several years, they've used this idea of a change of progress through a series of rings or release rings. In this scenario, continuous delivery is configured as a series of deployment rings. In this example, the first deployment ring A is used to test new versions in production for a select audience of Microsoft employees. Builds do not move to the next ring until it passes a suite of load and acceptance tests. The continuous deployment system automates deployment from one ring to the other. This can be useful in early rings. As soon as the acceptance bar is met, the build is automatically moved to the next ring. As the rings progress it can be prudent to add an approval step in which a decision-maker signs off on the changes electronically. For example, deployment to general release is held until management approves. There is a lot to learn about the services available in Azure Pipelines. We'll look at build and release pipelines in this chapter.