As you almost certainly know, Entropy is defined as "the propensity for all matter and energy in the world to evolve toward a state of inert consistency." You can see examples of this in nature -- from something as easy as water running downhill, to interplanetary matter collapsing and transforming into some kind of physical mass. Debatably, entropy may also give details the "love handles" and other physical attribute frequently 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 turn out to be rather common in the world of software development. It can be credited 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 most likely tired of the finger point whenever there are question about the excellence 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 continuing fight against disorder and chaos. The key is to obtain the relevant knowledge by a normal thought procedure in order to take benefit of it.

In order to optimize the efficiency of our actions, it is helpful to appreciate the implication of entropy. Look at one of the most universal powers in the universe: seriousness. It is one of the main forces that reason matter and energy to come together. It keeps the universe from totally dispersing and becoming a whole lot of nothing. So how does gravity help your software engineers expand better code? First, it keeps your engineers from floating out to space (physically, not mentally). That's forever a plus. But we should look at why seriousness is so successful at what it does. It is consistent. It is constant. And it is imperceptible. The goal is to develop something similar to significance to help your software growth team keep their feet on the earth 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 belongings of which are characteristically seen approximately age 30 or so. But in general, the law is the same across the board. Whatever system you expand for your expansion team needs to be reliable. Exceptions to the rules should be just that -- exceptions. Don't make exceptions all of the time. This will increase the unpredictability, and reduce 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 someway defy gravity -- but for the rest of us, it's a fact of life. In fact, it can be actually painful at times -- but you've come to expect that it's there. And it will forever be there. You can count on it. Considerate this, it can even be used to our benefit. The same be supposed to 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 procedure go out the window when time -- or customer demand -- becomes an issue. But turning things off just postpone or prolongs the issue.

Imperceptible We cannot see seriousness. Ghosts, maybe. But not gravity. If we might see it, we might try to avoid it or find some way approximately 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 precise Clear Case operation (check-in, check-out, make element). For any operation that requires some kind of control, you first need to decide whether it is a pre-trigger or a post-trigger.

Here's a rapid run down of the reasons for triggers or other ClearCase mechanisms, such as locks:

Preventive

Don't permit users to perform exact things with your source code or artifact. ClearCase allows you do anything you want to your artifact. Well, almost anything. It also allows you to stop things from occurrence to your artifacts. By using triggers and locks, you can prevent artifacts from being customized, checked in, checked out, or anything else you can imagine. This can be limited to branches, rudiments, and even version of elements in the VOB. Most of the time, locks are enough to handle all that you need.

One of the problems with the lock device, of course, is that it is static. You can use triggers on most of the operation in ClearCase to put off 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 carry out 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 previous to 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 almost certainly also want to run them in the background. Running post-exec commands in the background provide results from the post-exec part of the trigger much more rapidly. Remember, you want your triggers to be imperceptible, if probable. Perceived pace can be just as good as real pace to your users.

Interactive

The problem with this type of activate is that it can consume mass quantity of your developer's time. That is, normally speaking, bad. When you need to ask the user for information, make it possible for the trigger to read surroundings 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 necessitate that a comment be supplied from the user, you can allow the user to set an environment changeable with the comment and read that in a pre-trigger.

Most interactive triggers are pre-triggers.

Pre-triggers

A pre-event trigger monitors the practice 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 allowable to run. It can allow the command to go on, 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 need user input, make sure you can get the in order 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 punctual once, using the input information for the rest of the triggers that are called.

Post-triggers

A post-event trigger runs after a particular operation completes. Characteristically, 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 customized file is checkered 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 trying for an engineer than a slow file check-in. In fact, the result of a slow check-in procedure usually (and quickly) leads to developers ignoring the process, developing the bad habit of not inspection 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 exaggerated.

On the other hand, post-triggers are great for tool integration. If you have any integration with other tools, this should almost certainly be done in the post-triggers of operations.