Optimized Component Lifecycle Management with Sonatype CLM

So, let’s build on the third item we mentioned above, and first think about the intent of the policy we are going to create. Here are some question to consider:

These questions are really just the start, but in short you should ask what applications, what causes a violation, and what action should be taken. For our example policy, we want to focus on architecture aspects, with key areas being Age and Popularity of our components.

Since architecture is our focus we are going to use it as part of the name for our policy. In addition we are going to add Age and Popularity to the name to be more specific. This will help us later when we start creating additional architecture related policies. Lets go ahead and create this policy:

Threat level is one of the easiest concepts we’ll cover in this guide, yet it has the greatest chance to cause huge problems. At it’s core, this is simply a value for severity your business associates with a given policy. These values range from 1 to 10, each corresponding to range of severity, and a specific color:

To assign threat level to a policy, you will need to be in the policy edit mode (click on the editing icon). Next, use the drop down, which is located next to policy screen. This is displayed in Figure 3.7, “Policy Threat Level”.

When a threat level is selected by any component that has violated a policy will be displayed in the order of the severity of the violation. This is straight forward, but let’s take a look at the details and see where some issues can arise.

Just like taste is subjective, you have to realize that severity is subjective. What may be a level 10 for one part of the business may be quite different for another.

A bigger concern is what message you want to communicate to the recipients of the analysis. For example members of your team will naturally be inclined, to treat high severity as very important, and critical. If they see too many of these, the prospect of ever making any headway could be impacted in a negative way and you might dismay e.g. your developers to even get started on trying to fix the violations since there are just too many. As with any control mechanism it is probably advisable to be a bit lenient at first and start to get stricter at a later stage, when the worst problems are dealt with. Otherwise you could cause undue stress to development and management teams. The important thing is to keep in mind is how you will assign severity, and the impact it has on those reviewing violations.

Especially in the beginning, our recommendation is to reduce, if not exclude the high severity threat levels altogether. Remember, at the core, this number is purely for ordering how a violation will be displayed to a user of Sonatype CLM. Because this needs to be interpreted, the actual value is very subjective. It’s easy to overwhelm members of your team by seeing large numbers of highly severe violations. It might even be reasonable to set severity to the lowest setting for a violation (Low - 1) in the beginning. This way, members of your teams can get used to seeing the results that are produced.

In our example policy, architecture quality is pretty important, but it’s not the most important issue, so we’ll set this to a threat level of 7. This will give us a violation higher up in the display, but it’s certainly not the worst.

In many cases, policies will be evaluated against all applications. However, as your applications become more diverse and there are various groups of applications with similar characteristics, you may find the need to develop policies for these specific cases. This will go hand-in-hand with the creation of tags, which application owners will apply to their applications.

Given the ability to create tags, there is an endless amount of refinement that can be done in order to focus a particular policy on a set of applications with similar characteristics. While we won’t get into the creation of tags here, thinking about this as a way to create more finely tuned policy is a good first step. For now, we’ll assume we have some pretty generalized architecture requirements for all applications, and want to make a policy that will match all applications in this organization.

By now, we should know that an easy way to look at conditions is to consider them the "if" part of an "if/then" statement. In contrast, a constraint is not part of the statement, but rather a container for conditions. This can come in real handy when you want to consolidate a policy, by grouping similar conditions.

But why do this?

Well, for one thing, it reduces time. Next, because constraints are displayed on the application composition report, along with violations, it becomes easier for a member of your team to process information that is similar. Of course, it also has the added benefit of not having to create hundreds of small, "one-off" policies.

For example, in our Architecture Age and Quality policy, we may start with two conditions, one for age and one for popularity. This will work, but it’s likely better, especially if we want to expand that later on, we isolate these as separate constraints.

As a good practice, grouping similar conditions is the best way to build your constraints. Again, this will help de-clutter a multi-policy environment, as well as help someone reading any associated violations on the application composition report. For our example, we’ll place both conditions in the same constraint

Now, before we move on, let’s take a look at some of the specific aspects of conditions that can tend to be a bit confusing.

Policy Type. Sonatype CLM has an algorithm for determining the type of policy you created. This type is based on the types of conditions you include and is mainly used in reporting purposes. For example the trending report aggregate the different policy types into separate lists. The rules to determine the type of a policy are:

Any vs. All. If a component meets any constraint, the policy is considered violated. However, inside each constraint, when you have more than one condition, you have the ability to require that a component must either meet all conditions or just any of the conditions to trigger a violation.

This is a straightforward concept, but it can produce vastly different results. For example, selecting Any as an option will tend to produce a lot more violations, it’s the equivalent of placing an or between each condition. In addition even if you resolve one violation for a component, if the component meets other conditions later on, it might cause it to still violate the policy. On the other hand, using All' allows you to establish that all conditions must be met. It’s like placing an and between each condition. In this case, if you address any of the conditions, the violation will be resolved.

Let’s look at an example that would further explain this, and then we will move on to creating conditions in our policy. Below, we have a couple of policies and a component. If we wanted to exclude components that were younger then four years and had less than fifty percent popularity, which would we want to use? Also, would the component listed violate this policy?

It may seem like these two policies are exactly the same, but there is a key difference, Any vs. All. So, our first policy states that if Any of the conditions are met that a violation will occur. Given that, our component violates this policy. This is good, but we only want a component to violate a policy when Age is less than three years, and popularity is below 50%. We understand that there may be circumstances where a component might need to fall outside one of those boundaries, but if it’s both, we know we have a problem. Our component is pretty popular, so it might be a case where this component, even though it is newer than we prefer, actually resolves an issue another component might have. For this reason, the best policy for us to choose is Policy 2, and our component would not actually cause a violation.

Now that you know about all the available conditions and how they can be combined to match all or any condition to create a constraint we are ready to determine what should happen if a constraint is met - the policy actions.

In order to understand Policy Actions, we first need to discuss enforcement points, something we mention in our other guides, as well as much of the material you have likely used to make your decision to move forward with Sonatype CLM.

An enforcement point is simply a stage in Component Lifecycle Management as well as a parallel point in the Software Development Lifecycle. Given a particular stage, we can evaluate components within an application, making sure that they meet our policies (rules) that have been designed to manage component consumption. For example, we can show developers when a component they are using is too old to meet our policy on component age.

The actions we take at these enforcement points (stages) can simply be passive; in other words, only displaying violation of our policy to us and/or notifying specific people when a violation occurs.

In contrast, they can also be active, such as preventing a staged build from moving into production. Of course the caveat here, is you will need the proper CLM product (or products) to match the supported enforcement point. Additionally, we need to be careful, not to disrupt the process of development, by too quickly exposing large numbers of high-threat violations.

For our example, we will add a notification action for our build stage.

With that out of the way, let’s also take a look at the supported enforcement points, or stages of the development cycle, as well as how actions are are best utilized in each one.

Now, given the above, the natural thing to do seems to fail the process from moving forward any time problems are found. However, that’s actually not the best approach for everyone, and it’s not one we recommend. Instead, only consider failing the Stage Release as we’ve recommended, and even then, only consider doing so for the most severe violations.

While it is possible to fail the Build stage, this might put an unwanted roadblock in the way of your development process. Even without failing a build, your team can always be aware of the violations and trouble spots, but at the same time, still progress forward. A good alternative to build failure, is instead adding a notification to a stage so that when a policy violation is encountered. This way, responsible parties are aware without needing to routinely review a report, or have their own process stopped by an interruption event, like failing a build.

Congratulations! You should now have setup a custom policy that checks for a specific age and popularity of all the components. If you’ve been using the stand alone scanner, or if you are already using other enforcement points, take a look at how your applications react to this new policy. Here are the highlights you should know about: