Close
Blog

Streamlining NuGet Package Deployment with Azure DevOps CI/CD!

By, projscope.com
  • 10 Oct, 2024
  • 29 Views
  • 0 Comment

As .NET developers, managing multiple framework versions can be a challenge, especially when building and deploying reusable NuGet packages. Using Azure DevOps, we can simplify the CI/CD process and ensure our packages are built and tested across different .NET versions. Here’s a quick guide on setting up a CI pipeline for a NuGet package that targets multiple .NET versions in Azure!

📦 Why Use NuGet Packages? NuGet packages allow us to encapsulate code libraries, making it easier to share and manage dependencies across projects. This can save time and maintain consistency, as developers can simply pull in a package with the latest functionality without having to copy code manually.

🔍 Centralized Testing with NuGet Packages Another great advantage of a well-maintained NuGet package is the ability to test common functionality in one place. By including tests directly within the package, we can ensure that essential features work consistently across all projects that depend on it. This makes it easier to catch bugs early and maintain reliability as both legacy and modern systems evolve.

🏢 Cross-Departmental and Organizational Benefits A NuGet package can serve as a single source of truth not only within a specific project but across an entire organization. For example, a package that handles email sending functionality can be utilized by multiple teams, ensuring a consistent approach and reducing duplication of code. With this approach, any improvements or bug fixes to the email functionality can be made in one place, benefiting all teams using it.

💡 Creating a CI Pipeline for Multi-Framework Support Let’s consider an example where we have two projects: one targeting .NET Framework 4.7 and another targeting .NET 8.0. To ensure our NuGet package can support both, we’ll define a CI structure in Azure DevOps that builds and tests for each framework version.

Below is an outline of the CI pipeline structure that will guide us through:

Azure CI definition

This structure will include steps for restoring dependencies, building, and testing for both .NET 4.7 and .NET 8.0. With Azure DevOps, we can set up parallel jobs to run these tasks, making it efficient and robust for cross-framework support.

Azure CI definition

When configuring the dotnet pack tasks, we’ll specify the path for each project in the Path to csproj or nuspec file(s) to pack field:

  • For dotnet pack - NET 8.0, set this path to the project file that runs on .NET 8.0.
  • Similarly, for dotnet pack - NET 4.7, set this path to the project file that runs on .NET 4.7.

By setting specific paths for each framework version, we can ensure that both versions of our package are built and ready for deployment, covering all the bases in one streamlined pipeline!

📦 Continuous Deployment for Internal NuGet Packages With our CI setup complete, the next step is to configure a Continuous Deployment (CD) pipeline. This CD pipeline will allow us to automatically create and publish an internal organization-wide NuGet package, ensuring that the latest version is readily available for all teams.

If there’s interest, we’ll dive into the details of setting up a CD pipeline for NuGet package deployment in our next post. Stay tuned!

Leave a comment

Your email address will not be published. Required fields are marked *