 | Level: Introductory Christian Buckley, Principal, Red Hill Partners
Darren Pulsipher, Configuration Management Architect, Cadence Design Systems
21 Apr 2004 In IBM Rational ClearCase, triggers are what allow for customization and automation of software development processes... and for overcoming entropy. Trigger happy: overcoming entropy in software engineering.
This article was originally published in January, 2002.
As you probably know, Entropy is defined as "the tendency for all matter and energy in the universe to evolve toward a state of inert uniformity." You can see examples of this in nature -- from something as simple as water running downhill, to interplanetary matter collapsing and transforming into some kind of physical mass. Arguably, entropy may also explain the "love handles" and other physical attributes usually seen on the engineering elite and other seat-warming technologists. (We're not making fun of anyone here -- we're all victims)
Over the years, entropy has become rather prevalent in the world of software
development. It can be attributed to budget constraints, time-to-market pressures,
and big engineering egos. So how do you control this? As a configuration
manager or business system owner, you're probably tired of the finger pointing
whenever there are questions about the quality of builds and the product --
but what can you do? Look at nature. There are some interesting principles we
can learn from nature and its ongoing fight against disorder and chaos. The
key is to acquire the relevant knowledge by a rational thought process in order
to take advantage of it.
In order to optimize the effectiveness of our actions, it is helpful to understand the implications of entropy. Look at one of the most universal powers in the universe: gravity. It is one of the main forces that cause matter and energy to come together. It keeps the universe from completely dispersing and becoming a whole lot of nothing. So how does gravity help your software engineers develop better code? First, it keeps your engineers from floating out to space (physically, not mentally). That's always a plus. But we should look at why gravity is so successful at what it does. It is consistent. It is constant. And it is invisible. The goal is to develop something similar to gravity to help your software development team keep their feet on the ground and focused on the product -- not on the little things that don't matter.
Consistent -- Gravity does not play favorites. It works the same on everyone. Some would argue that there are those who are affected more by gravity than others -- the effects of which are typically seen around age 30 or so. But in general, the law is the same across the board. Whatever system you develop for your development team needs to be consistent. Exceptions to the rules should be just that -- exceptions. Don't make exceptions all of the time. This will increase the variability, and decrease the overall quality of your product. More importantly, make sure that you as a CM engineer follow the rules as well. Don't exclude yourself (as if you were a member of Congress). Constant -- Gravity is always there. It does not turn off when we fall. Maybe there's that one guy on Ripley's Believe It Or Not who can somehow defy gravity -- but for the rest of us, it's a fact of life. In fact, it can be really painful at times -- but you've come to expect that it's there. And it will always be there. You can count on it. Understanding this, it can even be used to our advantage. The same should be true for your development system. It needs to be on all of the time. Even under pressure, you need to hold your ground and make sure the process is always running. We've all seen process go out the window when time -- or customer demand -- becomes an issue. But turning things off just postpones or prolongs the issue. Invisible -- We cannot see gravity. Ghosts, maybe. But not gravity. If we could see it, we might try to avoid it or find some way around it. If your system hampers or otherwise obstructs the process of your engineers -- and they aware that it is your system that is causing these problems -- not surprisingly, they will circumvent it at all costs. The best technology is invisible.
Types of triggers
Most configuration management tools have some kind of mechanism that allows
for automation of software development processes. In IBM® Rational®
ClearCase®, these mechanisms are called Triggers. Software developers can
be guided to follow process through triggers, which are scripts that are called
before (pre) and after (post) a specific ClearCase operation (check-in, check-out,
make element). For any operation that requires some kind of control, you first
need to determine whether it is a pre-trigger or a post-trigger.
Here's a quick run down of the reasons for triggers or other ClearCase mechanisms, such as locks:
Preventive
Don't allow users to perform specific things with your source code or artifacts. ClearCase allows you do anything you want to your artifacts. Well, almost anything. It also allows you to prevent things from happening to your artifacts. By using triggers and locks, you can prevent artifacts from being modified, checked in, checked out, or anything else you can imagine. This can be limited to branches, elements, and even versions of elements in the VOB. Most of the time, locks are sufficient to handle everything that you need.
One of the problems with the lock mechanism, typically, is that it is static. You can use triggers on most of the operations in ClearCase to prevent things from happening. To enable this, you need to use a pre-trigger. If the trigger exists with a non-zero value, for example, it will prevent the operation from running. Preventive triggers are closely related to Integration triggers.
Integration
ClearCase integrates well with other software development tools. Most of the
time, triggers are used to track the work that users perform in ClearCase, and
"record" them into other tools. One of the most popular integrations is combining
a defect tracking system with build and release tools and ClearCase. In this
case, keeping the other tools updated with changes in ClearCase is the primary
reason for triggers.
Triggers for "mkelem", "co", and "ci" are the typical operations that are written.
These triggers are normally post-execution commands (pre- and post-execution
commands can be any arbitrary command lines to be run before a job is started
or after a job finishes). Not only do you want to run the above operations in
post-exec triggers, but you probably also want to run them in the background.
Running post-exec commands in the background provides results from the post-exec
part of the trigger much more quickly. Remember, you want your triggers to be
invisible, if possible. Perceived speed can be just as good as real speed to
your users.
Interactive
The problem with this type of trigger is that it can consume mass quantities of your developer's time. That is, generally speaking, bad. When you need to ask the user for information, make it possible for the trigger to read environment variables as input, as well. This will give your engineering teams the ability to run operations in batch mode. A great example for this is the mass "check in." If you require that a comment be supplied from the user, you can allow the user to set an environment variable with the comment and read that in a pre-trigger.
Most interactive triggers are pre-triggers.
Pre-triggers
A pre-event trigger monitors the usage of a specified ClearCase operation or class of operations. For example, a pre-event trigger can require that some check be applied before the check-in command is allowed to run. It can allow the command to proceed, or it can cancel the command.
Pre-triggers are typically used to enforce process, or to disallow the operation from occurring if certain conditions are not met.
Again, try to avoid triggers that prompt the user. This can become annoying when engineers perform those mass "check-ins" by forcing your engineers to hit the return key for each check-in. If you require user input, make sure you can get the information from an environment variable or file. The prompt should be seen as a backup input mechanism, not as your leading solution. Another option would be to prompt once, using the input information for the rest of the triggers that are called.
Post-triggers
A post-event trigger runs after a specified operation completes. Typically, this type of trigger notifies one or more users that a command was executed, or attaches an attribute to an object. For example, a post-event trigger might send an e-mail notification to the QA department when a modified file is checked in, along with any user-supplied information or comments from check-in.
Running post-triggers in the background will decrease the operation completion time. This is not a big deal for checking in one or two files, but checking in hundreds of files at a time can waste a developer's time.
The other negative effect is speed. Nothing is more frustrating for an engineer than a slow file check-in. In fact, the result of a slow check-in process usually (and quickly) leads to developers ignoring the process, developing the bad habit of not checking in their files. Inevitably, this will lead to engineers forgetting to check-in a file in for a build later down the road. When this happens, of course, builds fail, and timelines are affected.
On the other hand, post-triggers are great for tool integration. If you have any integration with other tools, this should probably be done in the post-triggers of operations.
Controlling triggers
Where you put your triggers completely determines how they can be accessed. You need to ensure that they can be accessed at all of your sites, and by all of your VOBs. And you need to make sure that they are accessed the same way -- through the same methods and processes -- in each location. This will make things consistent and constant across you organization.
Conclusion
As outlined in our article entitled "CM is a many splendored thing," most software development standards have some kind of process requirements in place that must be followed and thoroughly documented. This is where event-driven triggers can help you manage your project. In the above article, we gave an example of working with the program Lint, used for checking in your source code for certain standards. If your requirement is for all of your source code to adhere to a specific coding standard, you can register a "trigger" to run Lint before it allows users to check-in their code. They can also help solve problems with event notifications or error handling. For example, triggers can send out e-mail notifications to a group of reviewers when code has been checked-in so that the team can review the modified code before approving it for a certain build. On the flipside, triggers can notify the team in the event that files are not checked back in before a scheduled build, or when an upload fails.
Some basic rules of thumb come into play when creating triggers: Performance
is king. Understand the scope of what you deploy. Simple is better. Here is
our advice on each:
Speed is good. One of the great unwritten rules about working with software developers is to, whenever possible, stay out of their way. And one of the ways to impede their progress is to develop slow and cumbersome triggers. If you do this, your software developers will complain, and, as is their nature, most of them will do everything they can to subvert your process. It is important to streamline your processes, creating triggers that improve, not impede. Ensure that your process improvement efforts focus on what is most important to the developers, and make performance your top priority. Have you thought it through? Maybe you've identified a problem area in your process -- but how do you go about making your triggers faster? One sure-fire design method is to first analyze the scope and purpose of the trigger. Far too many engineers jump into a problem without first understanding the full scope. If you understand the drivers behind the problem, you're more apt to find a long-term solution. If the trigger is used to disallow an operation from occurring, for example, it should be in the pre-trigger category (to be run before the operation is executed). In general, these triggers need to be fast. If you're looking for unabashed rebellion, make your developers wait to check-in or check-out code from a version control system. Not a wise move.
Another technique we recommend is to run all other triggers in the post-operation mode. Anything that can be run in the background will allow your engineering team to optimize their productivity. Without having to monitor the system, they can get back to work again much more quickly -- and they won't have to sit there and wait for all of the triggers to finish. They'll thank you for that. Try to solve one problem at a time. Finally, we recommend you only bite off what you can chew. Don't get "trigger happy." One of the biggest mistakes with trigger development is the interactive trigger. If you need to get information from an engineer, try to work directly with the source code management system, and allow for environment variables or other mechanisms that can be used to apply the same information to all files for a given operation. If you thought slowing down the check-in, check-out process frustrated your development team, you'll triple that pain by forcing your developers to answer the same question again and again for the hundred or so files that they just checked into the source code management system. Simplify your designs, and, as the section header states, try to solve one problem at a time.
As we alluded in our introduction, entropy "is the ultimate Natural Law because it deals with the very existence of the universe: It determines the flow of what we call "time." Entropy has the most profound effect on all events in human existence, including our ability to achieve happiness by aligning ourselves with Objective Reality." (http://www.rationality.net/)
So tell your spouse that they're not "love handles" -- they're just part of your "objective reality."
In our next article, we will share some additional information on triggers, providing links and reviews of online and offline resources and libraries, as well as third-party tools to help automate their use and management.
About the authors | | | Christian Buckley is a Principal of Red Hill Partners, a technology consortium and content provider. He is also co-founder of the East Bay I.T. Group, the San Francisco East Bay's premier technology forum. Christian writes on numerous business and technology topics, and has been writing for Rational since 1998. With writing partner Darren Pulsipher, Christian recently published his first book, Secrets of the Change Agent. He can be reached at buckley@redhillpartners.com. |
Rate this page
| |
