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
There are multiple ways to share packages.
This is important because if we have these packages, and we know they exist, how do we put them in a place that is discoverable for members of our team? Or for other people out there in the world, that we want to share our content with?
We’ll talk about two different ways.
This isn’t the most efficient way to share packages, but it works and it’s still good enough. It’s better than manually getting all the files, wherever they might be.
I’ve seen this before, where we have a package that has a manifest inside of it, and all the binaries are code snippets, and we put those out on a UNC-path. I know, it’s what we talked about was bad, using UNC-paths. But the packages are already in a central location, and if folks know where that central location is, we can install the packages from that central location.
It’s difficult to deal with versioning with the Direct Copy approach because you just end up with a lot of files. You could end up with Kevin’s package 1.0, Kevin’s package 1.1, Kevin’s package 1.2, and so on. You would then have to maintain all these different versions in just one central location.
Also, Direct Copy is not easily searchable.
If you don’t realize Kevin’s package is named the way that it is, there’s no search engine that will go through that directory. It would be up to you as the consumer to look through all the content and figure out which package that you want to pull in.
We really recommend feeds, instead of something like direct copy.
With a feed, whether you are using the public repositories for any of these feed managers, or you maintain your own with something like ProGet, you want a system that can track these packages.
A feed will know all the metadata about the packages, the versions of the packages, and it can track the various versions of the packages. It also gives you one-click or one-command installation of the packages.
If you have a case where all your packages are internal private code that you don’t want to share with the rest of the world, then you definitely need a tool like ProGet because it has the tools that aren’t available in any of these public repositories.
When we go into the section about UPack, I will show you a little bit more about ProGet.
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.