How to setup Azure DevOps CI build/release pipeline for nuget packages (advanced)

21
votes

As a company, we are creating NuGet packages from various git repo's in Azure DevOps. Once a package is tested and approved it should be shared within the Azure DevOps organization.

I am struggling still with the setup of the build/release pipeline by using Azure DevOps feeds. Packages should become available for testing first before it gets shared in the organization.

Although there are a lot of recommendations and best practices shared by Microsoft, I still can't find a workable solution. I will explain the solutions I have tried so far:

Solution A

Using one feed where for the entire organization. Packages are automatically pushed to the @local feed and pushed to the @prerelease and @release view once testing is done. The pipeline is used as follows:

  • We work according to git-flow with develop, feature and master branches.
  • A CI build is triggered on develop branch
  • The package with pre-release suffix is pushed to the @local feed.
  • Acceptance tests are done in other tools by enabling the pre-release checkbox in NuGet package manager inside visual studio.
  • When the package is accepted a release is created and a new build is triggered.
  • The package is pushed

Issues Solution A:

  • When a package is accepted it should be promoted to the @release view but the package name still contains the -pre suffix.
  • When a package is accepted no new build should be required in my opinion, unless you can perform this from a release branch maybe?
  • Although the package is only visible in visual studio with the pre- suffix it can be pushed with the suffix to a @release view.
  • When a package is promoted it should be copied and stored without any suffix.

Solution B

Using a dedicated feed for each git repository (recommended by Microsoft) and publish NuGet packages to this feed from the CI builds. Each package is sent to the @local feed without any suffix. When a package is tested and accepted the package is promoted to the @release view. Each dedicated feed is configured as upstream source (@release view), the packages from the release view will be 'cached' in the common feed shared in the organization among all development teams.

Issues Solution B:

  • The packages that become visible via the upstream sources are only added/cached once a single deployment/build is done. You cannot enforce this when a package is promoted to the @release view.
  • All development teams have to subscribe in Visual Studio to all NuGet feeds to install the latest version of a package. (30 git repos = 30 feeds)

General Questions:

  • Is git-flow workable when we only create NuGet packages?
  • Should we work with pre-release packages or keep them in a @pre-release view without the suffix?
  • It feels wrong to start a new build to have a package without the suffix. Once the pre-release package is tested it should only be promoted to the release view.
  • Should we build the package in the CI build and use a release build to release the package. I have seen people using PowerShell with environment variables to promote package from one release to another.

I know there are a lot of questions but I am struggling for quite some time now with this issue. I hope someone can provide me with some good suggestions.

Thanks!

1
gitcontinuous-integrationnugetazure-devopsdevops
I'm trying to set up a similar scenario. I can't provide a solution either, a few notes: 30 repos = 30 feeds, isn't the idea to create 1 feed that developers consume and the feeds with packages are upstream sources of that? Ideally, I'd like to add prerelease tag to packages from feature branches, while packages from the main branch (master?) are considered the stable ones. Not sure how to set that up. – Anton
Did you ever have any luck with this. We are struggling with the same problem, we want all NuGet packages from feature branches to have the branch name as the pre-release version. – user351711

1 Answers

1
votes

What I do is in my build pipeline I build a pre-release and a release package and save them both to my artefacts.

In my release pipeline I publish the pre-release package to a local cache, once I am ready for UAT I approve the release to UAT and this publishes it as a pre-release package. Upon completion of UAT it gets approved for release to release which publishes the release package.