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

Question

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!

Answer 1

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.