How did this application deploy one year ago? How was the pipeline logic configured? What infrastructure model did it use? What application servers was it point to?

These questions all point to the same issue: enterprise application delivery is a changing business. New languages, new infrastructure, new platforms and services. Adapting the delivery process to satisfy every changing business or technology option requires careful change management strategies. Clarive helps deal with complex change by enabling careful configuration versioning.

Versioning is not something that needs to happen only at the source-code level. It needs to be taken seriously as organization-wide application delivery management issue. Every platform, every application parameters, every environment and infrastructure

Versioning In Clarive

Clarive implements several versioning mechanisms that allows for version control, with diff comparison, export/import, reuse and rollback features.

The two main versioning mechanisms in Clarive are:

  • Instant Versioning: when saving a rule or CI, they are versioned by the system.
  • Snapshots: manually (or automatically) triggered captures of environments, logic, configuration and/or templates.

You can use one or the other or both with Clarive. They are not mutually exclusive, and, in fact, it does not hurt to have separate strategies to using both of them at the same time.

Instant Versioning

Every time a user makes a change to a rule in Clarive that rule is saved as a version.

Versions can be tagged and compared. So you can compare the pipeline from a few days ago to the pipeline of a year ago if you wish. Rules can then be rolled back or copied.

But the main advantage of instant versioning is that, as we develop and work, we can rollback to a previous version.


Snapshots are the most complete and secure way to materialize the state of Clarive, be it current or already past.

Snapshots are a powerful configuration ……………………..

Advanced Versioning With Git

Now here’s the zenith of versioning delivery configuration: maintain a source-code repository, such as Git, with snapshot export files. And just commit the relevant changes.

This method then can be combined with Clarive changesets, releases, tests and deployment jobs to deliver changes in one instance of Clarive to other instances, creating a fully operational, enterprise-wide continuous delivery pipeline for your continuous delivery pipeline.

How about that for a change?



During his session about Lean Application Delivery, Eddy Pauwels spoke about DevOps being very similar to marriage: You want to unite 2 distinct entities (Dev and Ops, or man and woman) into something that adds more value (DevOps, or “married couple”). As within marriage, this is a cultural/behavioral journey without an end; it requires constant investment and adaptation. Every married person knows that this can only happen if you can communicate/collaborate well with each other.


Broken windows is a criminology theory that says that if you let one window to be broken in an unoccupied building, more windows will be broken — as the building degrades, sooner or later a band of squatters will settle in. In a short time, the broken-into building becomes a hub where crime gravitates in the neighborhood. The theory suggests that, by tackling petty offences, police officers can effectively reduce citywide crime.

But broken windows theory goes deeper that just patrolling officers and crime watching.

It deals with changes in the cultural and social fabric of a community. It deals with social boundaries and how people adapt to the increasing diversion that starts with one seemly trivial incident such as a broken glass (or graffiti, littering, etc.). When a person walks by a broken window, perception of the surrounding changes. The domino effect starts with how a person reacts to the proliferation of rundown areas. Most avoid them. Some feel detached from that part of the community. Others join in and break more windows.