IBM Application Runtimes Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
Managing the resource tree in UrbanCode Deploy (now DevOps Deploy) can be painful if you don't get it right early on. From a general user's point of view, things aren't that complicated since when UrbanCode Deploy (UCD) is setup well, a general user only sees the assets that they work with and this is normally only a small subset of the applications UCD is used to deploy.
However, from an administrator's viewpoint, the resource tree can quickly become spaghetti junction if it's not managed properly. The first thing to remember is that there is only one resource tree for all the environments of all the applications that UCD can deploy.
If you think of the resource tree a bit like the folder structure on your PC. You wouldn't put all of the folders in the root directory, would you? You'd use folders to organise your data into hierarchies so that you can easily navigate to any specific topic. If you think of the resource tree a bit like the folder structure on your PC. You wouldn't put all of the folders in the root directory, would you? You'd use folders to organise your data into hierarchies so that you can easily navigate to any specific topic.
If I was organising my customer information as one of the many things I have on my hard drive, I might have a folder called Customer Information. Inside that folder I might then have folders for each of the industry sectors my customers belong to. I might have folders for Banking, Insurance, Energy, Retail and so on. Inside each of those folders I might have a separate subfolder for each client project.
I organise my files into a hierarchy of folders that lets me find what I'm after more quickly. It's the same kind of task trying to organise the UrbanCode resource tree. But with the resource tree we also have to consider access rights. Who is allowed to create a new customer or industry sector? Does a client have distinct divisions that I might want to hold information about separately?
So thinking about the resource tree, the easiest way to manage this would be to create a new top-level group for each application.
When you've a relatively small application portfolio this isn't such a big thing, but if you're scaling for the enterprise, you may have many 100's or even 1000's of applications. That top level of the tree can get pretty busy very quickly. The bigger the resource tree is at any level the more data has to be fetched from the database and the longer it will take to render the resource view. So, we need to be a bit smarter about how we do this. We should be forward looking and find out how big this could get and plan accordingly.
Even if you don't have 100's or 1000's of applications you may still find these suggestions useful. I usually suggest that the top level of the resource tree and maybe the next level or two down are owned by the administrators. Then, nobody else can make a mess there.
I use the top level(s) in the resource tree to organise applications so that if, as an administrator, somebody wants you to look at a problem app, you know where to find it easily. You can drill down organisationally to where you need to be. [Organisationally in this context is how you choose to organise. It might be by business area, it might be alphabetically.]
There is a slight downside in that it means the administrators must create new applications resource folders, but maybe that's not such a bad thing. You need to onboard the applications, create teams add users and so on and since you'll want the application group folder to be owned by the right team(s) it's probably best for the admins to do it. In fact your role/permissions model may require it.
So, you might for example, create the top-level groups in the resource tree named for business divisions in your organisation, and the next level down might be departments within those business units. Quite how you decide on these organisational divisions is up to you.
So, you might have something like this:
I've got a couple of levels or organisational groups owned and maintained by UCD admins. The application level is created by admins since they need write access to the group above, but the application folder is editable by the application group team so they can add environments underneath.
If you wanted to enforce an environment naming convention, then you could of course have admins create both the application and environment groups and maybe the environment gates / approvals and so on if you're looking to enforce a process as well.
The environment groups shown in the red box would be the folders you attach as the base resource within the application environment.
Of course, what you choose as your organising criteria is a matter of preference and of course organisations don't always stay the same shape; responsibilities move and so on. So, whatever your organising criteria is, it would be best if it was relatively stable.
Of course when the application development groups start organising resources in their application environment folders, they should be encouraged to organise their resources into a hierarchy as well. Some of this comes naturally as for example agents become a de facto organising element. Components will naturally fall under the agent resource folder. However, complex applications with many components and perhaps a large number of resources can quickly make any given view of the resource tree quite large. So again we use folders to abstract away the complexity into something more easily managed and understood.
This issue is best tackled early on in the adoption of UCD otherwise there can be a lot of ownership changing and possibly reorganisation of the resource tree to make it all work effectively.
It needs careful consideration and should be planned for at the same time that the roles / permissions model is worked out. You need to decide how you will use teams since that is how access is granted to UCD objects. You also need to understand how you will structure the tree. A plan that everyone understands.
The longer you leave this, the harder it will get.Cloud, DevOps, IT Specialist, Cloud Integration Expert Labs
#UrbanCode#DevOps#bestpractices#UrbanCodeDeploy#10minutetip
By
Laurel Dickson-Bull
posted