Schedule a Call

MyST Platform Lifecycle and Versioning


Rubicon Red MyST delivers automated platform provisioning and configuration management for Oracle Middleware, on premise and on cloud. MyST uses a declarative approach to automation, meaning users simply define the target state of the Oracle Middleware infrastructure to be deployed; which, at the push of a button, is automatically provisioned in minutes by MyST.

Within MyST, the target state is captured in the “platform definition”, which is divided into two layers. First, the Platform Blueprint defines an environment agnostic specification used to define the platform topology and configuration of your Oracle Middleware. Second, the Platform Model, overlays the environment specific configurations. This declarative approach to defining target state enables MyST to treat Oracle Middleware infrastructure as code.

Platform Blueprints and Models are put under version control, allowing us to easily propose, review, test, promote and deploy configuration changes. This means incremental configuration changes are simple to make and propagate across all environments. We just update the required target state; MyST will determine and perform the required steps to apply the necessary changes.

Since MyST acts as a single place for managing the entire platform lifecycle, it is important for us to understand how best to effectively manage our configuration and avoid pitfalls such as version proliferation, environment drift, etc.

In this post, we attempt to lay out a few basic concepts of platform lifecycle management and how they are supported within MyST.

MyST as a Development Environment

MyST is intended to be used as the development environment for defining platform configuration. It is the place where one would log in and start defining platform blueprints and models using provided UI constructs such as wizards, templates, etc. Because users define their configuration (as code) here, it is important that they are able to save their configuration periodically without actually committing or applying them to any environment. To allow this, we have built the ability to save configuration in draft form repeatedly, overwriting previous changes, before committing the changes permanently.

MyST as a Version Control System

As one would do with code, once a user has defined all his configuration and is happy with it, he would want to commit it permanently to source control. For this, MyST acts as a simple version control system for the platform configuration and hence allows one to explicitly commit a revision of the configuration whenever appropriate and start making subsequent changes in a newer revision.

The Release Pipeline

As a first step towards continuous delivery, one normally would set up a continuous integration server and a CI environment where code gets deployed to every time a commit happens. Similarly, every configuration change can be and should be applied continuously to a CI environment on a commit. For this, MyST plays the role of a CI server for configuration where it polls for committed code and configuration changes periodically and then applies these changes to the target CI environment.

Not only this, it also provides a full fledged release pipeline where both configuration and code can move forward and get promoted into higher environments, either automatically or through a manual approval and click-button deployment process.

From a platform lifecycle point of view, there is considerable significance of having a release pipeline tracking and applying configuration changes.

Firstly, it implies that a release pipeline should only automatically apply and promote committed changes to environments. Draft changes should not make way through the pipeline.

However, it is highly likely that we may want to try out our changes in an environment before we commit them. To accommodate this requirement, we would eventually start allowing certain environments (such as DEV) to be earmarked to allow provisioning of draft blueprint and model configuration. It goes without saying that these environments would be manually provisioned to and updated by the user and they will never be allowed to become a part of a release pipeline promotion stage.

Versions and Naming Conventions

Platform Blueprint - One platform blueprint can have one or many versions over time. Typically, one would have a max of two versions active at a time, one for main development (like a trunk in version control) and another one optionally for patches (like a production fix branch in version control).

Though not mandated by MyST, it is expected that we would work on a single version of a blueprint untill it gets applied to Production, at which point he would finalize it and start working on a newer version.

In MyST, a platform blueprint version obeys the naming convention, 1.0.0[pr3]. Here, 1.0.0 is the version of the blueprint, pr is the standard prefix for a platform blueprint revision and 3 is the current revision number for it.

Platform Model - For each Platform Instance that we want to create, we need to create a corresponding Platform Model in MyST. So for example if we wanted to create a DEV, TST and PROD environment, we would create three Platform Models.

For each version of a Platform Blueprint, we can have exactly one version of each Platform Model associated with it. Remember, the Platform Model is meant to track environment specific changes to the configuration over time (passwords, endpoints, memory settings, etc). Changes to this configuration can also be independently tracked through revisions, which again can be in draft state and then subsequently in committed state for them to become eligible for applying to the target environment (assuming it does not allow drafts).

In MyST, a Platform Model version obeys the naming convention, 1.0.0[pr3][pm4]. Here, 1.0.0[pr3] just refers to the Platform Blueprint version and its current revision, pm is the standard prefix for a Platform Model revision and 4 is the current revision number for it.

Please note that the Platform Model can be revised independently of revisions to the Platform Blueprint and there is no hard relationship between them. The association exists between the Platform Model version and the Platform Blueprint version while the revisions evolve independently.

Draft, Committed and Final States

Platform Blueprint and Models in MyST can be in one of three states:

  1. Draft - Means that the current revision of the Platform Blueprint / Model version being viewed is still in a draft state and is not committed, hence will not be acted upon by a release pipeline. It also implies that this revision cannot be applied to any environments (unless they allow drafts which is an exception rather than the rule and not supported as of now).
  2. Committed - Means that the current revision of the Platform Blueprint / Model version being viewed has been committed, hence will be acted upon by a release pipeline if configured to do so. It also implies, in the case of a Platform Blueprint that this revision can be applied to all environments. Any subsequent changes will automatically be saved in a new revision.
  3. Final - Means that the current version of the Platform Blueprint / Model being viewed is finalized (most likely because it has been promoted all the way to production). Any subsequent changes to configuration will have to be made in a new version.

Tying it all together - An example

We have a platform blueprint, SOA, having one version, 1.0.0 and the latest revision of 1 in COMMITTED state, i.e. 1.0.0[pr1].


We have 5 environments, CI, SIT, UAT, PREPROD and PROD, all of which do not allow draft configuration to be provisioned / applied to them (default behaviour)


We have 5 Platform Models for the above Platform Blueprint, one for each of the 5 environments. All of them have only 1 revision for the 1.0.0 blueprint version in COMMITTED state, i.e. [pm1] which when combined with the Platform Blueprint would read as 1.0.0[pr1][pm1].


We have an active release pipeline, DEFAULT_DEV_PIPELINE, tracking configuration changes through the 5 environments above.


As can be seen from above the CI and SIT stage are already provisioned while the UAT stage is pending approval.

Now make any change to the Platform Blueprint and save it. This will generate revision pr2 for the Platform Blueprint in DRAFT state. Take care to not use the Save+Commit option to commit the change.


If we go back to the release pipeline dashboard, it will continue to show pr1 as the latest revision for the Platform Blueprint. This is because we have not yet committed pr2.


If we now commit revision pr2 and return to the dashboard. It will now show pr2 as the latest revision available in the build column.


If we wait for the pipeline to execute (or click Run Now to force execute it), we can see that the new revision automatically gets applied to the CI stage.



This shows how only committed revisions of Platform Blueprints / Models are considered by the release pipeline for promotion.

In a similar manner, we can make a change to the Platform Model for the CI or SIT stage and see that these will not be applied by the pipeline until the changes are committed.

Note that the original manual way of managing the provisioning / updating of Platform Instances without using a Release Pipeline is still available, but will treat draft and committed changes in the same way. In other words, MyST will not allow draft changes to be applied.

Changes from MyST 4.x

  1. The Finish+Provision option has been removed from the Platform Model wizard as we now have to explicitly commit our changes before we can provision the corresponding Platform Instance. The wizard consciously does not auto-perform this for the user.
  2. For each version of a Platform Blueprint, we can have exactly one version of each Platform Model associated with it. Previously, for each Platform Model associated with a specific version of a Platform Blueprint, we could create multiple versions of the same Platform Model. This change is designed to simplify the user experience, but use draft and committed revisions to achieve the same use cases.

Future Improvements

  1. The ability to earmark certain environments to allow draft revisions of blueprints / models to be applied and tested on them. These would typically play the role of Developer environments and a playground where we can test our Platform Blueprint before deciding to commit.
  2. While editing a Platform Model, to be able to show not only the latest revision of the Platform Blueprint but also the latest committed revision of the Platform Blueprint (in case the latest is in draft state).