Build Agents and Pools
Configuring API Access
The course is part of this learning path
Azure DevOps has many great tools for implementing and managing your build infrastructure, and this course walks you through how to use them. With a mix of theory and real-life demonstrations from the Azure portal, you will learn how to create Azure pipelines, use them to integrate 3rd party build systems, utilize agent pools, and learn how to put it all together to set up an automated workflow that can potentially save you hundreds of man-hours. So, whether you’re here to learn more about DevOps, improve your development process, or learn more about Azure DevOps in particular, this course will help get you further along your path.
For any feedback, queries, or suggestions relating to this course, please contact us at email@example.com.
- Learn how to build an Azure DevOps pipeline and add automation tasks
- Use the visual designer for adding build tasks to a pipeline
- Create a pipeline that closely matches an existing build process
- Determine a pipeline strategy based on the information given to you during a discovery process
This course is intended for:
- IT professionals looking to become certified DevOps professionals
- IT professionals experienced with other cloud providers who want to gain a better understanding of Azure
- Anyone who wants a better understanding of Azure build infrastructure processes
To get the most from this course, you should have some understanding of the software development process, at least at a high level, as well as an understanding of what DevOps is and the terminology related to it.
In this lecture, we will be talking about Azure Pipelines. Azure Pipelines is Microsoft's cloud service offering for creating Continuous Integration and Continuous Delivery.
In this section, we will be talking about what Azure Pipelines are and what they do, and then we will go through a demo of how to create an Azure Pipeline.
What are Azure Pipelines? Well, we cannot talk about Azure Pipelines without first having a clear understanding of what Continuous Integration and Continuous Delivery CI/CD for short are.
The concept of Continuous Integration is constantly and frequently integrating code updates to a shared repository for testing and use by other developers and processes. Code committed to this shared repository is verified by an automated build process and additional tasks allowing individual pieces of code to be checked for problems that could introduce breaking changes or potential bugs into the application. Typically code that breaks the build is prevented from being committed to a shared repository.
The concept of Continuous Delivery is the process of handing off code to the quality assurance team for testing as part of an agile process. Testing at this stage is to detect bugs that are logical in nature and while the syntax of the code committed may not break the build, it may not execute as expected or may not meet the acceptance criteria for resolving the problem. Testing earlier in the software development process is done in hopes of detecting and fixing bugs before they make it to production. This process typically involves deploying to a staging area and generally does not add direct value to the user, but it is a necessary step in the agile software methodology.
As an aside, the concept of continuous deployment often gets confused with continuous delivery. In this automated process of deploying code, this code must again pass a series of automated tests and manual requirements to be accepted as production-ready and deployable. The continuous delivery and continuous deployment terms are often confused with each other. However, they are not the same thing and comprise two parts of a larger DevOps whole.
I find the best way to visualize a build pipeline is like an assembly line in an auto factory. The raw materials in our case code starts at the beginning of the process and at the end, you have a drivable vehicle. For us, a testable piece of code. At each station, along the way, a new piece of functionality or modification is added. For us, we call these tasks and once all the stations or tasks have done their work, we should have a testable piece of code that can be sent to the QA department.
Azure pipelines work with many different languages like C#, C++, Python, Go, and many more. One requirement of using Azure Pipelines or any CI/CD automation tool is having a code base stored in a version control repository accessible by Azure. You must set up both an organization and a project in Azure DevOps. Projects can either be publicly accessible or private. This has a significant impact on the pricing model used for creating and running Azure Pipelines.
Azure Pipelines also works with many various version control systems like Azure Repos, Team Foundation version control and GitHub, which we will be talking about later in this course. You can build and deploy almost any type of application. Some examples are .NET, Node JS, Java, even Xcode.
It's also possible to deploy your code to multiple deployment targets such as virtual machines, on-premise servers or Azure-hosted environments. You can even deploy to other cloud service providers like AWS or GCP.
You can choose from many types of deployment packages like NuGet, npm, zip files and others. There's an amazing amount of versatility within the Azure DevOps service offering from Microsoft and Azure Pipelines are the foundation upon which the build process automation are built.
As I mentioned during the intro section, your project accessibility has a large impact on the pricing model used by Azure DevOps pipelines. If you have a publicly accessible project in a public repository like GitHub, then Azure Pipelines are free. Free is a nice option, but having your code visible to the world might not work for you. If you have proprietary systems that should be protected or if youR code security is an issue for you, then this is not likely an option for you. Luckily, Microsoft provides 1800 minutes or 30 hours of build time for pipelines in private projects. This is a lot of time, but if you have exceptionally large projects that take many hours to build, then managing your build hours can be very important. Luckily, you can disable your pipeline to prevent unintentionally using build minutes. Later in this course, we'll be talking about private hosted build agents. This is another option for reducing build hours used in Azure Pipelines.
So now we know what Azure Pipelines are, why do we wanna use continuous integration and continuous delivery and Azure Pipelines? Some of the major reasons for using continuous integration are increasing and maintaining code quality, catching potential errors earlier in the development process, ensuring code testing and code test coverage is maintained and maintaining consistent code style across entire applications.
Major reasons for using continuous delivery, reducing and removing time-consuming and error-prone manual processes, keeping your development staging and production environments up to date, ensuring that your infrastructure is secure and properly maintained, automating integration and regression testing. These are just some of the reasons that you might wanna use CI and CD.
All right, now we know what Azure Pipelines are and what we use them for. Next, we'll go through a demo and we'll create our own Azure Pipeline.
About the Author
As well being the owner and CTO of Sharp Solutions Group, a software development and IT staffing company based in the Philippines, Kelso is a Microsoft Certified professional and an avid knowledge seeker. His belief is that you need to learn something new each day to stay on top of the constantly changing IT world. He is an avid gamer (both video games and board games) and lives in the Philippines with his wife and soon-to-be-delivered son.