DevOps for your Organization – Part 7: Package Build

In the previous post, we discussed the benefits of including automated unit tests in to your project, as well as how to add them. In this post, I will discuss the purpose of creating a package of your solution, as well as going through the steps for packaging up our project for distribution.

Purpose of a Package

The purpose of packaging your solution is to collect all files your application needs to run into a single deployable unit. These packages may include images, configuration, DLLs, static files, documentation, and anything else that may be used to run your program. Creating a package as part of your build process makes releasing the code easier. The package that we generate in this step will be used in the next post for deployment.

Adding Packaging to our Build

Before I begin, I want to note that Microsoft also has some good documentation on how to achieve this. The purpose of my blog post is that it is specific to the project that we have been using.

  1. Open up the build YAML that we’ve been working with.
  2. On the Tasks bar on the right-hand side, choose .NET Core
  3. In the drop-down, choose Publish. Additionally, check the following boxes.

    The publish command will package up the .Net Core ASP.NET project into a zip file that can be published. The Publish Web Projects and Zip Published Projects will support this.
  4. For the Arguments section, put the following: –-configuration $(BuildConfiguration) –output $(Build.ArtifactStagingDirectory)

    These arguments will make sure to use the proper build configuration for your project (Debug or Release), and will output the package that we want to generate to the artifacts staging directory. The artifact staging directory is a folder created by our build to hold all of the artifacts generated by the build. In this case, it will be the packaged website.
  5. On the Tasks bar on the right-hand side, choose Publish build artifacts. Use the default settings.

With that, your pipeline should be ready! Below is the YAML that we generated. The displayName tag has been added to add names to the steps when you run the job.

# Create a zip file that can be used to publish the site
- task: DotNetCoreCLI@2
  displayName: 'Publish Site' 
  inputs:
    command: 'publish'
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    publishWebProjects: true
    zipAfterPublish: True

- task: PublishBuildArtifacts@1
  displayName: 'Publish Build Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

After running your job, you will be able to see the artifacts that you generated under the Artifacts section. Click on the 1 published text to see what you’ve generated.

In the next post of this series, we will be covering how to deploy this newly generated package to your test environment using Azure DevOps releases.

Let Us Help You Out!

Code Vanguard has worked with clients of all sizes, helping them to use DevOps practices to accelerate their time to delivery. If you’d like Code Vanguard to help your organization with your DevOps process, feel free to reach out to us!


This post is part of the DevOps for your Organization series, where we walk through some basic steps you can take to move your organization towards the DevOps process. The full series can be found here. If you’d like Code Vanguard to help your organization with its DevOps process, feel free to reach out to us!

James Stephens About the author

James is the founder of Code Vanguard and one of its developers. He is an applied mathematician turned computer programming. His focuses are on security, DevOps, automation, and Microsoft Azure.

No Comments

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.