Publishing Artifacts in an Azure DevOps Release Pipeline

The goal of this article is to show you how to use Azure DevOps with a release pipeline. This can be done in either your corporate environment or on an emulator if you don’t have access to production resources. Using the build-deploy-test approach, we will create and publish artifacts from our codebase using a Jenkinsfile as well as deploy them into an Azure sandboxed container through ARM templates.

The “azure pipeline publish artifact example” is a blog post that shows how to publish artifacts in an Azure DevOps Release Pipeline.

You’ve developed an Azure DevOps release pipeline. The build and all of the tests have been automated. It’s now time to provide a build artifact someplace. Stay tuned to discover how to use Azure DevOps to add a NuGet Azure Artifacts stream!

Azure Artifacts offers a 2 GB free use tier. This article’s work will be completely free.

Packaging and deployment are one of the final phases in a CI/CD workflow. To be useful, you must actually deploy code to an environment. It’s a nice technique to distribute the project to have all of the assets in one package.

NuGet, a package management tool, is one approach to package a program and its related build artifacts. Many tools support NuGet as a convenient packaging format. NuGet enables you to package and publish your project as a feed. You may then direct a client to this feed and download a versioned package to use.

There are a variety of services that enable you to generate packages and publish them to NuGet feeds. However, if you’re already utilizing an Azure DevOps release pipeline to generate projects, Azure Artifacts is a built-in artifact publication engine.

Azure Artifacts is a fantastic method to share and distribute all types of NuGet packages. You’ll discover how to use Azure Artifacts as a last step in a CI/CD pipeline in this post!

Overview of the Project

This project will be divided into six distinct components. They are:

• Ascertaining if the project is ready for Azure Artifacts
• Ensure that the pipeline can publish to the NuGet feed by setting feed permissions.
• The NUSPEC definition file is created.
• Creating and uploading the package to the pipeline
• The deployment job has been added to the pipeline.
• NuGet Package Development with the pipeline and publishing it to the Azure DevOps project’s Azure Artifacts feed

You’ll have a fully functional example of how to publish a build artifact to a NuGet feed and deliver that NuGet package to a client using PowerShell when you’re through.

Note that Azure Artifacts accepts NuGet feeds from both organizations and projects. You’ll be utilizing the pre-created NuGet feed that comes with every organization in this tutorial.

Before You Begin

If you’re going to follow the methods in this post, make sure you have a few prerequisites in place first.

Ascertain that the project’s artifacts are enabled.

For an Azure DevOps project, you may activate and stop certain services. The Artifacts service is enabled by default, but if you’re using another project, make sure it’s enabled as well.

You may activate it by going to Project settings and checking the Artifacts box in the Overview section, as seen in the picture below.

ensure that Artifacts is turned on

Adding the ability for the pipeline to publish to artifacts

Every Azure DevOps organization includes a NuGet feed that has already been setup. Artifacts is where you’ll find this feed. My company is named adbertram, as you can see in the screenshot below.

The pipeline build service identity has no ability to publish packages to the feed by default. You must provide permission for the pipeline to publish the package after it has been produced. To do so, go to the feed settings by clicking on the gear button below.

To access feed options, click the gear symbol.

Click the Permissions section once you’re in the Feed settings.

Tab Permissions

Click Add users/groups once you’re in permissions.

Button to add users/groups

Type the first few characters of the project name in the Users/group dropdown. The project name for this article is PowerShellModuleProject. As you can see in the screenshot below, the item is named PowerShellModuleProject Build…. Select Contributor from the drop-down menu and click Save.

Looking for a contributor to PowerShell

As illustrated below, the group should appear as [ProjectName] Build Service ([org name]).

Build Service ([org name]) user/group [ProjectName]

NUSPEC File Creation

NuGet must know how to construct a NuGet package using an NUSPEC file in order to do so. A NUSPEC file is similar to an XML manifest for a package. It enables developers to specify details like as name, version, description, and files contained, among other things.

To avoid getting mired down in too much information, the NUSPEC file for this project will be kept minimal. The NUSPEC file that this project will employ looks like this. The PowerShellModuleProject.nuspec file is stored in the Git repo’s root directory.

Except for the version tag, the most of the tags are self-explanatory. When a NuGet package is produced, the version tag specifies the package’s version. This NUSPEC file will be used to dynamically assign the version depending on the build as part of the build process. When the package is produced, the version tag must include a placeholder to dynamically assign the version.

When we start developing the pipeline, you’ll see where the $VERSIONHERE$ placeholder is utilized.

<?xml version=”1.0″?> <package> <metadata> <id>PowerShellModuleProject</id> <version>$VERSIONHERE$</version> <authors>Adam Bertram</authors> <description>My awesome PowerShell module</description> </metadata> </package>

Creating a NuGet Package

So you’ve built the NUSPEC file. It’s time to inform the pipeline to create a new NUPKG file (the NuGet package) and make sure it’s ready for the next deployment step. You’ll need to create two tasks named [email protected] and [email protected] to do this.

Using the Multi-Stage Pipeline UI, you’ll make changes to the pipeline. This feature is currently under Preview as of this writing.

NuGet Package Development

A [email protected] assignment is listed below. You may restore, pack, and publish NuGet packages to a NuGet feed using this job. The command property is used to describe this behavior. The command is configured to pack as you can see below. This command instructs NuGet to generate a package based on the data in the NUSPEC file specified in the packagesToPack property.

The pipeline searches the root of the working directory for the PowerShellModuleProject.nuspec file produced in the previous step.

VersioningScheme and versionEnvVar are two versioning properties you’ll notice. These two properties establish the versioning strategy, which determines how NuGet gives a version to the final package. Where the package version appears is determined by the versioning technique.

Off, byPrereleaseNumber, byEnvVar, and byBuildNumber are some of the versioning schemes available. Versioning is handled in this case using semantic versioning, which is specified in the variable section above in the pipeline, as seen below.

major: 0 minor: 0 variables patch: $ (Build.BuildID) $ buildVer (major). $(minor). $(Build.BuildID)

You must use byEnvVar since we’re constructing our own versioning scheme and allocating a custom pipeline variable to each build. Then you must supply the variable that stores the current build version iteration for versionEnvVar.

Finally, you can see the buildProperties below. This is where that placeholder in the NUSPEC file (<version>$VERSIONHERE$</version>) comes in handy. In this attribute, you can replace the placeholder with the build version by specifying a key value pair.

– responsibility: [email protected] packagesToPack: ‘$(System.DefaultWorkingDirectory)/PowerShellModuleProject.nuspec’ versioning: command: ‘pack’ Version: byEnvVar scheme buildVer buildEnvVar: ‘VERSIONHERE=$(buildVer)’ property

Adding the NuGet Package to the Deployment Stage

Because each stage’s artifacts aren’t shared with other stages, you’ll need to make sure the following deploy stage has access to the newly formed NuGet package. Use the [email protected] task to do this. This job takes an artifact created in the current stages and makes it accessible to the pipeline’s later stages.

The pipeline is searching for a NuGet package specified by ArtifactName in the artifact staging directory, as seen below. The Container publishLocation is then used to store it into the pipeline itself. This artifact will be accessible to all stages of the pipeline once it is published.

– responsibility: [email protected] inputs: ‘$(Build.ArtifactStagingDirectory)’ PathtoPublish publishArtifactName:’NuGetPackage’ ‘Container’ is the location.

This step should generate an artifact when the pipeline runs, as illustrated below from the pipeline run status page.

On the pipeline run status screen, the stage created an artifact.

The final Build step looks like this once the package has been generated and made accessible to other stages in the pipeline.

– stage: Build jobs: – job: Build steps: – task: [email protected] inputs: filePath: ‘$(System.DefaultWorkingDirectory)/build_scripts/build.ps1’ – responsibility: [email protected] packagesToPack: ‘$(System.DefaultWorkingDirectory)/PowerShellModuleProject.nuspec’ versioning: command: ‘pack’ Version: byEnvVar scheme buildVer buildEnvVar: ‘VERSIONHERE=$(buildVer)’ property – responsibility: [email protected] inputs: ‘$(Build.ArtifactStagingDirectory)’ PathtoPublish publishArtifactName:’NuGetPackage’ ‘Container’ is the location.

The Pipeline Deployment Task is being added.

As you go through the YAML pipeline, you’ve arrived at the step you’ve been waiting for: deployment! In this step, you’ll take the NuGet package you just produced and publish it to the Artifacts service’s NuGet feed.

NuGet Package Installation

Because the NuGet package (build artifact) was published to the pipeline during the build stage, you can use the [email protected] task to make it accessible during the deployment step.

This job looks for any NuGet packages (artifactName) that have been published by the current pipeline run, as shown below (buildType). It then copies those NuGet packages to the current workspace after they’ve been located (targetPath).

– responsibility: [email protected] itemPattern: ‘**’ buildType: ‘current’ artifactName: ‘NuGetPackage’ ‘$(Pipeline.Workspace)’ as targetPath

An Azure DevOps Release Pipeline is used to publish the NuGet package.

Publish the package to the Artifacts NuGet feed once it is ready in the current stage. Use the [email protected] job once more to do this. This time, specify where to search for the package (packagesToPush), the internal Artifacts feed (nuGetFeedType), and the name of the internal Artifacts feed with the push command (adbertram).

Note that the name of the NuGet feed supplied to the publishVstsFeed attribute is always your Azure DevOps organization’s name.

– responsibility: [email protected] packagesToPush: ‘$(Pipeline.Workspace)/**/*.nupkg’ inputs: command: ‘push’ internal nuGetFeedType ‘adbertram’ publishVstsFeed

The Deploy stage should look like this after both jobs have been configured in the pipeline.

– stage: Deploy jobs: – job: Deploy steps: – responsibility: [email protected] itemPattern: ‘**’ buildType: ‘current’ artifactName: ‘NuGetPackage’ ‘$(Pipeline.Workspace)’ as targetPath – responsibility: [email protected] packagesToPush: ‘$(Pipeline.Workspace)/**/*.nupkg’ inputs: command: ‘push’ internal nuGetFeedType ‘adbertram’ publishVstsFeed

The YAML Pipeline at Its Finest

Following the addition of everything to the YAML pipeline, you should have a file named azure-pipelines.yml that will publish the artifact to your Azure DevOps release pipeline.

trigger: – master name: ‘PowerShell Module Project’ major: 0 minor: 0 variables patch: $ (Build.BuildID) $ buildVer (major). $(minor). $(Build.BuildID) pool: vmImage: “ubuntu-latest” stages: – stage: Build jobs: – job: Build steps: – task: [email protected] inputs: filePath: ‘$(System.DefaultWorkingDirectory)/build_scripts/build.ps1’ – responsibility: [email protected] packagesToPack: ‘$(System.DefaultWorkingDirectory)/PowerShellModuleProject.nuspec’ versioning: command: ‘pack’ Version: byEnvVar scheme buildVer buildEnvVar: ‘VERSIONHERE=$(buildVer)’ property – responsibility: [email protected] inputs: ‘$(Build.ArtifactStagingDirectory)’ PathtoPublish publishArtifactName:’NuGetPackage’ ‘Container’ is the location. – stage: Test jobs: – job: Test steps: – task: [email protected] inputs: scriptFolder: “@{Path=’$(System.DefaultWorkingDirectory)/PowerShellModuleProject.Tests.ps1′}” resultsFile: “$(System.DefaultWorkingDirectory)/PowerShellModuleProject.Tests.XML” usePSCore: true run32Bit: False – task: [email protected] inputs: testResultsFormat: “NUnit” testResultsFiles: “$(System.DefaultWorkingDirectory)/PowerShellModuleProject.Tests.XML” failTaskOnFailedTests: true – stage: Deploy jobs: – job: Deploy steps: – responsibility: [email protected] itemPattern: ‘**’ buildType: ‘current’ artifactName: ‘NuGetPackage’ ‘$(Pipeline.Workspace)’ as targetPath – responsibility: [email protected] packagesToPush: ‘$(Pipeline.Workspace)/**/*.nupkg’ inputs: command: ‘push’ internal nuGetFeedType ‘adbertram’ publishVstsFeed

The Pipeline in Action

It’s time to put the pipeline to the test now that it’s been completed! Now is the time to start the pipeline. If everything goes according to plan, you should have a lot of success.

Stages of successful development, testing, and deployment

Enjoying the Prestige of a Published Package

Return to Artifacts after the process is complete. You should now only see one package. It will be named PowerShellModuleProject if you followed through with the previous post and this one, as seen below.

The item appears in the Artifacts section.

You may now download the package with your preferred client tooling and take use of all the benefits that having software packaged with NuGet can provide!

Summary

You learnt how to package and publish an existing Azure DevOps release pipeline build artifact to an Azure Artifacts NuGet feed in this article.

Even though the sample project was a PowerShell module, these general knowledge nuggets may be applied to any project type.

What are you waiting for if you’re not using NuGet packages in your Azure DevOps release process to distribute your applications?

The “azure devops download build artifacts” is a tool that helps with the publishing process. It allows for the downloading of artifacts from a release pipeline.

Related Tags

• azure devops release pipeline multiple artifacts
• azure devops publish pipeline artifact
• azure devops pipeline artifacts
• publish build artifacts vs publish pipeline artifact
• azure devops build artifacts