This section outlines the steps to create a feed in Azure DevOps and then shows how to update the pipeline to publish the packages to that feed on every build. Publish the packages to a feed using push I'll explain why this is further a little later in this article when discussing versioning. I like that better as it gives me more control. That way, the pipeline doesn't generate unique version numbers and you're required to set them yourself in your projects. Note that I left Automatic package versioning set to off.
Save the pipeline to store the yaml back in source control and kick it off.I also ticked Do not build as I already have a separate build task. I changed the path to exclude my test projects that I'll add later. NET Core task, and configure it as follows: Open the pipeline in Azure DevOps and scroll to the end of the yaml code.Follow these steps to modify the build pipeline accordingly. The next step is to package the projects into NuGet packages. Include a dotnet pack step to build the packages
In a later article I'll add unit tests to the solution and run them every time code is committed. You may get an error from VS Test not being able to find any tests but that's fine. After a while you should get a confirmation that the build succeeded. I usually pick the second solution as using a VM that already has the required SDKs installed will make your build a little faster. This gives you the following yaml for the pipeline:Īpparently, windows-latest isn't the latest (yet), causing some issues. Under Configure your pipeline, choose ASP.NET Core:.
Clicking Approve and install takes you back to Azure. You'll be taken to GitHub again to approve Azure Pipelines to be installed in your selected repositories. Under Select a repository, choose the repo created in the previous section.If needed, authorize Azure DevOps to access your repo.Under Where is your code, click GitHub (yaml) or choose your own remote system.Log in to your Azure DevOps environment, and open the Pipelines menu.With the code in Git, I can now set up the build pipeline in Azure DevOps. Setup a build pipeline to build the project After a short while, the repository has been created and your code has been uploaded to Git.Select your remote system, provide credentials and other details and then click Create and push or just Push.In both cases you get a screen like this: If you had already created a Git repo locally, choose Git | Push to Git service instead. In part 4 of this series, I'll reinstate the web project and add the necessary references back as packages. With the solution loaded in Visual Studio, remove the web project from the solution, leaving only the projects that will become packages.You can choose your own remote repository in which case the steps below will be different. Add source code to a remote source repositoryĪs I mentioned, I'll be using GitHub to store my source code. In the following sections I'll describe these steps in more details. Verify the packages have been uploaded to the feed successfully.Include a push step in the build process to upload the packages to a private feed.Include a dotnet pack step in the build process to turn the compiled projects into packages.Set up a build pipeline in Azure DevOps to build the project.NET Core app, I'll use Github for my source code but you can pick Azure or something else if you want to follow along.
Just like in my article series on building and deploying a. This can be Github, Azure, and a few others. In order to get my project built and published to a NuGet feed, I took the following high-level steps: Auto-building and publishing NuGet packages In the next section you see how to build your packages using an Azure DevOps pipeline and then how to publish them to an Azure feed. Which feed you choose to publish to doesn't matter much when it comes to building the pipeline as they all follow the same principle. But there's a much better alternative available: uploading your packages to an external feed which could be entirely public (such as ) or with access to a limited set of developers only, such as MyGet or a private Azure DevOps feed. For more information, see the section Target build order of this article: įor small environments this approach may work fine.