Jenkins does a lot of things – but doesn’t do them well. For example, Jenkins’ built-in artifacts aren’t ideal for the software you intend to deploy.
Universal packages, on the other hand, are designed for just that. Not only are they designed to deploy software, but using universal packages gives you many more options for how you deploy.
Here is a guide for how to configure your Jenkins and ProGet to publish and deploy universal packages.
Deploying From Jenkins
Jenkins is really popular for CI (build automation), and many teams extend it for other general-purpose automation. It can run scripts, which means it can do anything you script it to, including deployment. “A match made in heaven” you might think. However, built-in Jenkins artifacts are not good. CI was originally intended to test code and provide testing feedback to developers as they coded. It was never intended for you to deploy directly from there.
Using Jenkins to automate deployment beyond simply copying artifacts to other file servers or the cloud is not recommended. Jenkins is an all-purpose automation tool that was designed for Continuous Integration. What that means is YOU have to script deployment, and there’s a LOT to deployments.
- Large, monolithic applications have thousands of files that can take a long time to deploy; require starting and stopping components at just the right time; come with quirks, and sometimes need a redo.
- Microservices are usually distributed to many servers, are relatively easy to deploy, but often need to deploy several at the same time, and there tend to be lots and lots of microservices, often with slightly different ways to deploy because they’re developed/improved over many years.
Universal Packages Are Better
Universal packages are designed for software you intend to deploy.
Universal Packages have a standards-defined format and are a single file that contains all of your build artifacts, as well as a manifest file that has the package’s name and version. Unlike artifacts, packages are essentially “read-only,” are Semantically Versioned, and have built-in metadata that contextualize who did what and when with the package, simplifying two of the most stressful dev events: auditing and rollbacks.
Universal packages help you uniformly deploy your software. Packages are built once and deployed consistently across environments. Because of this, you can be certain that what goes to production is exactly what was tested. You’ll also have many more options to deploy.
All of this comes together to create a simple yet effective deployment system.
How to Create Universal Packages
How to create a Universal Package private repository
After completing your Jenkins build that you’re ready to deploy, install ProGet for free here.
Once ProGet is running on your machine, click on Feeds in the ribbon and set up a Universal Package feed.
How to set up Jenkins to Integrate with ProGet
This plugin integrates ProGet with Jenkins and allows Jenkins jobs to create and upload, or download and extract universal packages. The plugin can be installed from any Jenkins installation connected to the Internet using the Plugin Manager screen.
To configure the plugin:
Ensure that an API key has been configured in ProGet (ProGet > Administration > API Keys & Access Logs) Without this, the plugin will still work to a certain point but will have reduced functionality in the job configuration – i.e. you will need to fill in certain details rather than select values from a drop-down list, of feeds, groups, and packages.
Next, navigate to Jenkins’ system config screen to tell Jenkins where’s your ProGet installation resides and the username and password of a user with permission to upload files to ProGet.
Finally, you can add a build step to “ProGet Upload Package” and your artifact will be uploaded as a universal package in ProGet.
In its basic form, this simply requires specifying the files in your workspace that you’d like to package, supplying some metadata that describes the package, and the job is done. Please consult the help text in the plugin configuration screen for more information on each setting.
There are some more advanced options that allow you to tweak the files that will be included in the package and supply additional metadata.
How to Deploy Your Universal Package
Now that you have your universal package published to your private ProGet repository, you have many different options to deploy. The two easiest options for deploying your universal packages from ProGet are to deploy using Jenkins, deploy using the command-line-interface, or deploy using Buildmaster.
Deploying using Command-Line Interface
The command-line interface (CLI) in UPack allows you to deploy Universal Packages straight from your ProGet.
Once the package is pushed to ProGet, it can be installed on any server that can access ProGet.
Using the CLI you could type:
PS C:\tmp\accounts> upack install Accounts --source=http://progetint/upack/Universe/ --target=.\install
This will extract the package contents of the “Universe” feed in ProGet into
Deploy using BuildMaster
There are a few tools that can integrate with and deploy directly from Jenkins. Most require that you use Jenkins to publish to an artifact repository or package feed first, and then deploy from that.
BuildMaster is one of these tools, and it directly communicates with Jenkins. BuildMaster will import artifacts directly from Jenkins and then handle all of the deployment complexity. It can also automatically queue builds in Jenkins, which means you can have BuildMaster use Jenkins behind the scenes. You can learn all about this integration on our Docs page.
Jenkins is really popular for build automation and can be extended to include deployment. However, it was never intended for you to deploy directly from there. Universal packages are designed for the software you intend to deploy. Use this guide along with an instance of ProGet’s free forever version and level up your deployments.