Expert-developed and customizable to help organizations of all sizes master our tools
Presenter: Kevin Griffin of SwiftKick Training, and an Inedo-certified Master Trainer
We are going to talk about Universal Packages, and we’ll also talk about a great tool called UPack.
UPack lets you build your own Universal Packages, and we’ll discuss ways of publishing them in your internal infrastructure, and then how members of your team can consume these packages.
UPack is a technology-neutral packaging platform that allows you to uniformly distribute your applications and components across environments to enable consistent deployment and testing.
You might be thinking, “what does that mean, Kevin? You just said a lot of words.” And really, I just read the copy from all the great marketing material. So, let’s just dive into it.
When I say Universal Packaging, I mean anything that is not really suited for another environment.
These are all examples of just “stuff” that we need to distribute to members of our team, but it doesn’t fit into any of these other molds that might exist. We need something that’s more universal.
UPack is highly extensible. Because it doesn’t fit into the mold of any of these other packaging systems, you can really customize it to your heart’s content.
Do you need people to know certain things about certain packages? You can just embed that metadata.
You can easily distribute a Universal Package. You can put it up in a UNC-path, if that is still the way you want to do business. Or, you could use ProGet and expose a universal feed. You could also just have it on your local drive.
I could use the command-line interface to go out and find packages if I need to. Or, I could use ProGet to search for all the packages I might have published up there. I also have a history of what packages are installed on my system, when they were installed, and who installed them.
UPack is free, to anyone wants to use it, and you could go download it now at inedo.com/upack/download.
There’s a couple different tools there, not just the command-line interface, or UPack.exe. You could also install the Universal Package Explorer, which I’ll show you a demo of a little bit later.
There’s also a visual studio extension for building and deploying UPack, and there’s a UPack.net library. If you want to build your own systems that can create and publish UPack packages, there’s a library for that.
There is also a Jenkins plugin, so if you are using another build system and you want to incorporate UPack as part of your process, there is a plugin for that.
My recommended way to install UPack, is to install the UPack package via Chocolatey if you are running in PowerShell. You just type
choco install UPack, and get the latest version.
What’s great about Chocolatey, is it’s kind of mixing great package managers. You have Chocolatey, which is built for managing and maintaining Windows packages, and you have UPack, which is used for creating, maintaining and publishing Universal Packages. So, mixing two great technologies. If you don’t have Chocolatey installed, follow the lab in the full training, there’s a set of commands in there that tell you how to install Chocolatey. Really simple.
Like we said in a previous section, a package is just a glorified zip-file, that contains other files and some metadata.
Well, UPack is no different. You have metadata, which is just JSON or upack.json, and a collection of files that need to be unpacked, whenever the package is installed.
Because the metadata is just JSON, we can put almost anything that we want inside of it. This information is used by UPack and ProGet to know how to display the data to anyone that might go searching for it.
Any files that are included in the UPack file are in a directory called “Package”.
You can easily open a UPack file in a zip editor, and you can see what’s inside of that file. You have to be careful, because UPack does enforce a verification and validation of the contents in the file. So, if we were to change anything inside of the file, it changes the hash for the file, and it might not be verifiable after stuff has been changed.
Now, if you’re not going crazy, this is what a sample of a UPack.json file looks like:
We need to know the name of the package, the version (UPack uses SemVer, three octets), and you might have a title or a human readable title and description for the utility. So, when this is up in ProGet, you can read all this like a human would want to read the content.
So, let’s walk through the process of building a Universal Package…
Our training courses are built modularly, and we can develop a customized training roadmap for your organization, so that everyone gets the training they need, when they need it.