In yesterday's post, I started talking about Packaging Utility. I want to continue that conversation today, but widen the scope a bit to talk about repositories and managing them in your enterprise. This seems like an area people generally don't think much about, although how you organize your repositories can have a great impact on your deployment strategy. Let's dig into this a bit more.
Types of Repositories
There are three kinds of repositories that Installation Manager can use:
- ESD repositories. As we discussed yesterday, the "Electronic Software Delivery" type is the format you get when you download repositories from IBM.com or receive a DVD of one of our products. It can only be used from a local drive, a shared directory mounted locally, or via FTP.
- Network repositories. Can be used from the same locations as the ESD repository, but also can be hosted via HTTP or HTTPS. This is the recommended way to host repositories.
- Composite repositories. This is a special beast, and I'll be discussing this further in a future post. In short, this is really a repository that's just a pointer to other repositories. The downside is that it must be created by hand at present. It's a very useful type, but like I said, we'll discuss this further in a future post.
Packaging Utility comes in to play when you want to move the repositories you acquire from IBM to another location or convert the ESD to a network repository.
The way your repositories are organized is the next thing to come in to play. There are a few different ways to organize how your products are hosted that we've seen.
- By product or product version
- By role or team
Let's look at these a bit closer
Product or Version
In this approach, you have a repository per product or product version. This is a simple approach, and matches how you receive the repositories from IBM. Leveraging Packaging Utility here will allow you to take advantage of any shared content between the versions of the product to reduce disk space. It keeps products siloed, so that adding a new product to your environment just means creating a new repository with no impact to existing repositories.
The downside is that you may end up with large number of repositories to manage across your enterprise, depending on the number of products or versions you use. To counteract that, I'd recommend using a repository per product, and add new versions to this repository. This reduces the number of repositories to just the number of products you use.
Another potential downside is that managing access to these repositories can get trickier. Each product may have a different set of users you'd like to allow access, and this approach means you'll have to manage access to each product repository.
Role or Team
In this approach, each repository is set up for a role or team inside your enterprise. The repository contains the set of products and versions intended for that role or team. It takes a bit more work, but Packaging Utility can copy multiple products into a single repository easily.
In this case, your access control is much easier to manage. For each role or team, you give them access to a repository created specifically for them. This means your access control is centralized. It also means adding a single repository to your silent response file or through the Installation Manager GUI gets the user all the products they'll need.
The downside is that you now have to manage the contents of the repository more, particularly in the case where tool sets may change. It also means you may have more than one copy of a product's repository around, if two or more teams share products.
We do have a way to address that last item, and that'll be covered when we discuss composite repositories.
All in one
This is the simplest repository type, where you use Packaging Utility to copy all of your products and versions to a single repository. This simplifies the management of repository locations, possibly reducing your hardware needs. Any shared components between products will only exist once since Packaging Utility will manage that properly during the copying process.
The downside, of course, is that now everything is in one place. If you use a number of different IBM products and versions, the list you are presented with in the GUI can get quite large and difficult to sort through.
Controlling access to products also becomes much more difficult in this approach.
Packaging Utility's role
As mentioned earlier, Packaging Utility's ability to copy multiple products and versions to a repository will come into play when creating your repositories, no matter the type. It also enables you to host these repositories via HTTP/HTTPS, which we recommend doing for both performance and security reasons.
Packaging Utility is a key component to how IBM envisions you managing your repositories. Take advantage of its capabilities to help reduce your disk space and management overhead when it comes to repositories.
But what's your recommended repository organization?!?!
I can hear you asking that question now. We recommend using either the product or role based method for organizing your repositories. This helps you control access to the repositories, while keeping their size manageable.
Even better is taking advantage of composite repositories, but like I said that's a topic we'll cover in more depth in the (hopefully near!) future.