Now let's consider the fact that multiple revisions of a single BPM or SOA Composite Application can be deployed side-by-side. You may choose for each change to be a new revision or for only major and breaking changes to be a new revision. Either way, your automation will probably need to consider retirement of Composite Application revisions over time. After all, you don't want to have unused Composite Revisions hanging around in your Platform doing nothing but adding overhead.

For me, this matter's a lot. Let me explain and discuss some of the solutions for reliable Continuous Delivery of SOA and BPM Composites.

Don't make me think

Automation should focus on taking a desired state and applying it to a target environment rather than performing a specific task which only works under certain strict conditions. In other words, an operator shouldn't have to think too hard about whether their automated deployment is going to work, it should just work.

Idempotency

For automation to just work it should first be idempotent which means when executed with the same input more than once it should have no additional effect.

"Insanity is doing the same thing over and over again and expecting different results." - Albert Einstein

Now let's go back to our non-idempotent undeploy script. It will work the first time (provided no one has already undeployed)... but it will fail the second-time with an error stating it has already been undeployed.

Initial State before undeploy

Non-idempoment

Idempotent

Action Performed

Result

Action Performed

Result

Composite revision deployed

Undeployed

SUCCESS

Undeployed

SUCCESS

Composite revision has already been manually undeployed

Failed due to previous undeploy

FAIL

Skipped undeploy

SUCCESS

Composite removal happened in the last release

Failed due to previous undeploy

FAIL

Skipped undeploy

SUCCESS

Composite revision was never promoted to this enironment in the first place

Failed due to composite not existing

FAIL

Skipped undeploy

SUCCESS

Automation should not require human intervention for decisions it could safely make on its own

Your automated deployment should be part of a single automated release process so your undeployment step is just one part of a larger whole. If it fails, it will fault the remaining tasks until a human gets involved.

If you want reliable Application Releases, you should use a consistent approach. An undeploy script that only works once and then fails for future releases or for deployments to new environments just won't cut it.

Option 1: Scripting

If you're comfortable with scripting, there are of course countless ways to make your release process idempotent, if you are willing to invest the time.

For example, in our example with undeployment, you could build a wrapper Apache Ant project which does a stop of the composite first (which is interestingly already idempotent unlike the deploy) then if it displays a certain message that would indicate the Composite is not deployed then we can skip the undeployment step altogether. Of course, this approach requires processing on the output of a script rather than it's exit code which is not ideal... but alas, it's what we have to work with.

Scripts can be great for automation as they allow you to perform things quickly and consistently without needing manual labour. But there is still some labour to create them, test them, debug them and keep them up-to-date as new Oracle product releases come along.

Option 2: Rubicon Red MyST

An alternative is to use Rubicon Red MyST which is a DevOps solution for Oracle Middleware and SOA Cloud Services. MyST comes with out-of-the-box support for Automated Release Management and Platform Provisioning of Oracle-based solutions and you don't need to write a single script. Instead, you define your application deployments declaratively and manage the promotion of them through a Release Pipeline. If you'd like to learn more about MyST you can visit our pages on Continuous Delivery and Platform Provisioning.