Sonatype CLM Server - Application Composition Report

Initially, label assignment might seem like a task that deserves less process. It’s actually the opposite.

The label process actually starts at the Sonatype CLM server, where each organization, and in many cases application, have a specific set of labels.

Creating labels at this level means that they are available to users of the application composition report. So, before you label something, a number of things need to be considered, which might mean you need to go back to label and policy management. Let’s take a look at some questions that we can use to form a baseline to what labels we need and/or should have.

Do we have a process defining labels, as well as how and when they should be used? Every label should have a reason for using it. If it doesn’t you don’t need it. That’s because people will naturally infer meaning to the label. For example, if you have a needs review label, you should have a process for reviewing components with that label. It shouldn’t merely be a tag. You should also consider adding labels such as reviewed, so someone can tell if something was reviewed. The possibilities are endless, but this may mean you need to rethink the labels you have, or should create.

Should this label apply to only my applications, or all applications for this organization? We like to refer to this as the scope of a label. A good way to look at scope is the concept of macro and micro. At the macro level we have an organization that may have thousands of applications. If I apply this label to the component at the macro level (organization) it means the label will be seen by all applications under that organization. That’s a pretty sweeping change, and it could be the right thing to do. However, you might actually be better served by considering the impact at the micro level. In this case, maybe this is a label that should only be applied to a particular application.

If I apply this label, is it part of a policy, and does it escape certain violations? Conditions in a policy can include values for labels. In many cases, this is best used as a way to prevent a certain component from violating the condition. For example, I could have a policy that requires a component to be no older than three years. However, a safe, and commonly used component is four years old. If I have a process built around reviewing a case like this, where an exception would be valid, I could first place labels to identify the component to be reviewed for an exception, and then another label once that exception is approved (or disapproved). In this scenario, if I have built policies correctly, including allowing them to flow through certain stages, even with a violation, development can continue. This of course should occur simultaneously to a review/exception process. It’s important to consider scenarios like this when creating labels, as well as policy.

There are more questions regarding labels that should be asked as well, but many of these you will discover as you develop your own processes. The key is that labels can be deceivingly simple, given their implementation in other systems. The reality is, that in Sonatype CLM, they are much more than just a component tag. Now that you have the word of warning, let’s take a look at how to assign a label.