 Hi, my name is Edward Thompson. I'm a program manager at Microsoft working on Azure DevOps. Today, I'd like to introduce you to Azure Pipelines now available in the GitHub Marketplace. Azure Pipelines is the premier continuous integration service for everything from open-source projects to enterprise software. It supports any language on any platform, so it supports your project, whether that's a Node.js app, Java, Ruby on Rails, .NET, or heck, even old-school C. Azure Pipelines provides build agents for you for Linux, Windows, and macOS so that you can build your project on every platform and they're hosted in the Microsoft Cloud so that you don't have to manage them. Best of all, Azure Pipelines provides a free pipeline for your project with up to 1,800 minutes of build time per month, and it's even more generous for open-source projects. Azure Pipelines provides no limit on the build minutes for open-source and you get up to 10 pipelines in parallel for free. That's why I rely on Azure Pipelines for my open-source projects, especially one project that you may not have heard of. It's called LibGit2. But just because you haven't heard of it, doesn't mean you haven't used it. LibGit2 is the project that get hosting providers like Azure Repos and GitHub used to manage pull requests. As a maintainer of an open-source project that makes up the critical infrastructure of software development, it's crucial to me that we have a robust and reliable continuous integration service. Being able to validate changes, ensuring that pull requests build across all the platforms we support, and that our tests pass for every contribution is crucial for my open-source project and it's crucial for your software projects too. So, I'm going to show you how you can add Azure Pipelines as a continuous integration build for your software project to build and test the master branch of your code and validate pull requests. Let's take a look at how easy it is to get started with Azure Pipelines. Here, I have a very simple project. It's a pocket calculator. Well, sort of. It's actually a node.js application that looks like a retro calculator, the kind that we nerds had back in the day before the phone in your pocket could calculate integrals. Of course, I've published this project out on GitHub. I'm excited to share it with the world in the hopes that other people will use it and maybe contribute back to it. Maybe somebody will find a bug in my code, or maybe somebody will theme it up so it looks more like the pocket calculator that they remember from their youth. But, if I'm going to take contributions, I need to have a build pipeline configured so that when somebody opens a pull request, I can make sure that their changes build and that all the tests pass and the easiest way to do this is with Azure Pipelines. All I have to do to get started is to go to the GitHub Marketplace. Just look up in the top banner of github.com and click Marketplace. There are a bunch of great services here that integrate with GitHub. But for continuous integration builds, we want Azure Pipelines. So I'll just type that here in the search box. And then click on the search results. I can click on Read More to get more details about Azure Pipelines. And when I'm ready to get started, I can just click to set up a new plan. In the pricing information, I'm reminded that Azure Pipelines is completely free for open source projects. So just by selecting the free plan, you get unlimited build minutes across up to 10 simultaneous build queues. It's the most generous offer for building open source projects. And it's free for private projects as well. Private projects get a single parallel job with up to 1,800 minutes of build time included every month. And if you want to scale up beyond that, you can add additional private build agents. But for open source projects, it's still free for unlimited minutes. When you're ready to get started, just click Install It For Free. On the next page, you'll choose where you want to install Azure Pipelines. You can install it directly to your GitHub account or into a GitHub organization, which you might have if you're part of an open source project or a company. I've actually created an organization for my application, so I'm going to select to install it there. Then I can click Complete my order and begin installation. On the next page, you'll need to verify that you want to install Azure Pipelines. This permission is needed so that Azure Pipelines can read your repository and write its configuration into your GitHub account. This adds the continuous integration workflow and adds builds into pull requests. As a safety precaution, you may need to enter your GitHub password here to confirm this access. And finally, you'll need to sign in with your Microsoft account. And if you don't have a Microsoft account yet, you can just click to create one. It's free and easy. But here, I'll just type in my username and password. And once I'm logged in, Azure DevOps will set me up with a new account to build my GitHub project. Once my account is created, it will bring me to this new pipeline designer. Here, the first thing that I need to do is make sure that the correct repository to build is selected. That's easy since I only have one in my organization and that's my calculator app. So I'll click on it. When I do that, Azure Pipelines will analyze my repository to try to figure out what kind of project I have checked in and how to build it. It's detected here that I have a Node.js project, which I do. It also selects some other project types in case it guessed wrong. If I were using React or View, I could select those templates. If I were using Webpack, I could select that. I could even design my own pipeline from scratch. But of course I don't need to. Let's take a look at the Node template that Azure Pipelines has recommended. So when I click on it, it shows me the build YAML. Azure Pipelines uses a YAML configuration file to describe the build pipeline. It's a technique called configuration as code, which is great because you can check in the build description right next to the code that it builds. So as your code changes and as the build needs to change to support that, those changes to the build configuration get versioned right alongside your source code. So Azure Pipelines shows me this YAML up front before it finishes creating the pipeline. This is an opportunity to make sure that this matches what I expect from my project. And it is, it's just building my Node.js project with NPM, so this is perfect. So to complete the setup, I just need to click save and run. This actually adds the YAML file directly to my repository on GitHub and sets up an Azure Pipelines build that reads it. I could also select to use a pull request, which would let other contributors to the project look at the YAML before it goes live. And pull requests are definitely a best practice, but since I'm just getting started with this project and I don't have any other contributors yet, I'm happy to just click save and run and commit it directly. And once I do that, you can see that this actually starts a build of our project. It's going to find a free Linux build agent in our cloud hosted pool of build machines. It's going to download my project's repository from GitHub. Then it's going to run the build script, which runs NPM install, then NPM run build. I can actually watch the console output from the build as it runs to see the progress as it goes. And once it's finished with all the steps, you can see that it's succeeded. So that's great. But I can make this even more powerful by tweaking the configuration for my project. The out of the box template is good, but it's even better if we customize it. For example, I have tests in my project using the Mocha framework. And I want to run them as part of the validation that I want to perform on pull requests. So I can add this just by navigating to my project on GitHub. I can click this link right here in the build output to go there. Then in GitHub, I can select the YAML file that Azure Pipelines added for me. And at the top of the YAML text, I can click the pencil to edit it. And in the script section, right after the NPM install and NPM run build commands, I can add NPM test. That's the great thing about YAML. It's easy to change. All I need to do is scroll down to the bottom of this page and type a quick commit message in and then click commit changes. Again, although pull requests are a best practice, I'm just getting things set up, so I'm going to commit directly. And when I did that, GitHub notified Azure Pipelines that there's been new content pushed to the master branch and that it should queue a new build with those changes. So if I move back over to Azure Pipelines, you can see that this did indeed queue a new build for me. If I click on it and then go to the log view and then click on the build log for the NPM step, you can see that it did run my test suite and that they all passed. So that's perfect. As I commit changes to my master branch on GitHub, they're built and tested with this pipeline. But now let's see how this actually works to validate contributions through pull requests. If I navigate back to my project on GitHub, I can go through the contribution mechanism with pull requests. Let me navigate to my project's controller and then click to view it. And when I do one thing that I notice is that this operation for addition is a little strange. Plus A plus plus B. If I'm not familiar with JavaScript and how the plus operator is both addition and string concatenation, that might look like an error to me. So I might want to be helpful and contribute a pull request, changing it to just A plus B. So just like before, I'll click the pencil to edit this file and I'll change this operation to something that looks better. And again, I'll scroll down and I'll type a commit message. But this time, I do wanna follow best practices. So I'll select this to create a new branch and I'll give my new branch a name and then I'll click propose file changes. Once I do that, GitHub will navigate me directly to the new pull request experience where I can double check my code and then click create pull request. And then again, GitHub will notify Azure Pipelines that I opened a pull request and then it will start a build against that pull request branch to validate those changes. You can see it right here on the pull request page that it's turned yellow. It's in the process of running my build. If I wanna see it in action, I can click on the details to open up the GitHub status page. Then I can select to open this in Azure Pipelines. And by the time I do, you can see that this build has actually failed. If I click on the NPM task, I can scroll through the output to see what happened. If I scroll down, I see that my addition tests failed. My test that adds two numbers, 21 and 21, is supposed to return 42. But here it returned 2121. And this one adds 42 and zero and expects 42 back. But here I got 420. It looks like instead of actually doing addition, it's concatenating these numbers as if they were strings. That's clearly not right. Let me close this window to go back to GitHub and then go back to my pull request. Now, Azure Pipelines has reported back to GitHub that the tests failed. So I have this big red X to warn me about this. This lets me know as a project maintainer that there's a problem with this pull request just at a glance. So even though that line of code looked strange, it was actually correct after all. And this pull request validation build made sure that I didn't accidentally break something. Now that Azure Pipelines has given me this helpful feedback, telling me that this contribution was not actually a good change, I can iterate on the pull request. If I go to the files changed tab, then again, I can click on the pencil to make another change to this pull request. Obviously the original code was correct. The plus A plus plus B coerces A and B to numeric values and adds them instead of treating them like strings and concatenating them. So I'll revert that change. But if you're not familiar with the finer points of JavaScript, then this is still a little confusing. So I'll add a comment to this code to make it clear what it's doing and why. This is a good pull request. It takes some code that was confusing and clarifies it with a comment. So again, I'm going to scroll down and I'm going to type a comment for the commit. And then I'm going to click commit changes. This will add a new commit on the pull request branch. So when I click back to the conversation tab, I'll see this new commit and I'll see another status update that shows Azure Pipelines is running a build. It's looking at the newest change to see if now this pull request will build. So again, I wanna click through to details and then to my build in Azure Pipelines. And I'm going to watch it build again. And this time it succeeded just like I expected. I certainly hope that adding a comment won't break the build. So now I can close this and go back to the pull request in GitHub. And now I can see that the pull request has this lovely green check mark next to it instead of that ugly red X. This indicates that all the build validation checks have passed and that Azure Pipelines has run all the tests. In other words, it's safe to merge this at least as far as what I've configured my continuous integration build to look for. So I can feel confident clicking this green merge pull request button. This will merge the pull request into the master branch and in a way that I feel confident about the code quality. So now I have a continuous integration build set up that builds whenever changes are merged into the master branch and it will build pull requests to validate the changes before they get merged. As a maintainer of a software project, this is a level of sophistication that I expect. And I want people who are contributing to my project to know that I'm following these best practices with CI builds. So I can actually show this to them easily so that they know the project is healthy. I can do this by adding what's called a badge to my project's page on GitHub. This badge will show contributors that my main integration branch is building successfully and that all the tests are passing. It's a bit of a litmus test really for open source projects and really for any software project. Azure Pipelines makes it easy to add a badge to your project's read me where it will be shown as soon as anybody navigates to your project on GitHub. To add one to my project, all I need to do is navigate back to my build in Azure Pipelines. Then I need to click this ellipses and then I'll select the option for a status badge. When I click on that, Azure Pipelines will show me an example of my badge. You can see that it's green. That means my builds are currently succeeding which is exactly what I wanna see. And it shows me the URL for this image but even better, it gives me some markdown that I can actually just copy and paste right into my read me. So I'm going to select that and then copy it to my clipboard. Then I'm going to go back to GitHub to edit my read me and add the markdown. Back in my repository, I'm going to click on my read me.md to open it in the viewer and just like before, I'll click the pencil to start editing and I can select right here in the file where I want the build badge to show up in my read me and then paste the markdown right in. Finally, again, I'll scroll down to the commit area like before, type in a simple commit message and then commit the changes. So now when I'm taken back to my projects read me, you can see this nice green badge that shows everyone I'm following best practices by having a continuous integration pipeline for my pull requests and for my master branch and that Azure Pipelines is keeping my project safe. So you can see how easy it is to protect your project and keep it building and tests passing which helps you safely accept contributions whether that's from the open source community or from your coworkers. And it's easy to get started. Just go to the GitHub marketplace and select Azure Pipelines to build and protect your project whether it's no.js, Java, .NET Core or anything else. It's free to start with 1,800 build minutes per month and a single pipeline available at no cost. For open source projects, it's completely free with unlimited build minutes and up to 10 concurrent builds. If you want more information about Azure Pipelines, you can visit dev.azure.com and be sure to follow us on Twitter or at azuredevops. So again, I'm Edward Thompson. Thanks for watching and I hope that you'll get started with Azure Pipelines for your project.