Releasing a new version of an application, configuration or infrastructure in Clarive is done by executing the given release (or changeset) Topic as a deployment Job.
This Job executes a combination of all automatic tasks and orchestrates all the manual tasks needed to deploy a release.
Releasing can adapt to a set of strategies:
- Big-bang releases.
- Gradual releases.
- Stepped deployment.
Deploy all of the changesets at once in a single Job.
This is the best strategy for production environments, because it makes changes "transactional". This means Clarive guarantees that it can roll back the full Job in case of failure.
To implement big-bang releases:
- Add "Bind Releases" in the Status Resource where you want to avoid deploying gradual changesets, i.e.
- Develop a Job pipeline Rule that takes full advantage of Job rollback strategies.
- If necessary, add manual deployment ops to your deployment Rule: approvals, pauses, etc.
Gradual releases mean deploying changesets individually into an environment.
This strategy is typically better suited for preproduction environments. The main advantages is that we can cherry pick releases that are going to be deployed into an environment.
This means that the gradual release steps are implemented through pauses, traps or approvals during the deployment Job.
We recommend using stepped deployment if the release execution not going to take more than 24 hours.
Having a Job running for over 24 hours means having the job processes taking up resources in the Clarive server (and related targets).
To schedule release deployments, Clarive uses its calendaring engine to process what can be deployed and when. Use the
Calendaring admin interface to define available Job slots by any Scope or Job content:
- Global schedule.
- Environment-based slots.
- Specific dates (i.e. holidays) as exceptions.
- Project or Resource-based calendar slots.
Release Infrastructure Relationship¶
Releases and Changesets hold relationship to Resources in the Clarive Graph. This enables, for instance, identification of which releases may be affected by certain infrastructure outage.
To use the CI Graph dashlet, add it to the Release Topic category Dashboard:
1) Create a new Dashboard Rule in the
Rule Designer by clicking . Fill out
Name field, and set the
Type field to Dashboard, then click
Done. Open the newly created Dashboard Rule
and add the
CI Graph dashlet from the
Palette by dragging over the name of the Dashboard Rule. Click
further details, see CI Graph.
2) Open the
Admin dropdown, and select
3) Select the Release Topic.
4) Select the Dashboard created in step 1 from the dropdown menu in the
Dashboard field. Click
Once you open the Release Topic, the user can drill down through the related Resources, including infrastructure, for a given environment or project for that release.
Infrastructure that will be necessary for deploying a release is also available when creating a
Redeploying a Release¶
If a release fails, or the environment is rebuilt from the outside, a release can be redeployed to that environment using either of the following:
- Job rerun.
- Creating a new deploy transition into the environment.
Either way, release will be redeployed to the environment.
By rerunning the job through the Job Monitor (select
Monitor), the same variables and values used in
each step will be reused. That means the same version of the configuration will be deployed to the environment.
A Job Rerun also allows the user to control which Job step is going to be re-executed. This allows users to rerun only
RUN phase of the job.
If the release is already in an Environment (e.g. DEV), and the transition from and to the status exists in the workflow
for the release with
Job Type static, then Clarive can redeploy a release to an Environment where it is already
To set up static redeploys, edit the workflow for the Topic category:
- If it is a simple workflow, activate the
Admindropdown menu and select
Categories, followed by a Topic. Then go to the Workflow tab, and from the
From Statusdropdown, select a workflow transition with Job Type static from and to the same status e.g. from QA to QA (click to maximize left-hand Lifecycle bar if minimized, then select
statusand Job Types. Set
Typeto Deployable and click
- If it is a Rule workflow, modify the workflow rule so that it has a transition from and to the same status, set
Deployment Typeto static. Select
Rule Designerand . Set
Typeto Workflow and click
Done. Open the newly created Workflow Rule, and select
Palette. From there drag the
Change Topic StatusWorkflow over the name of the Workflow Rule. Click on this and set
Deployment Typeto Static, then click
Provision / Decommission Configuration¶
Using catalog repositories, users can add provisioning tasks to releases changesets.
Provisioning is executed when the Rule executes. Make sure the Rule has a
Provision Task operation configured at some
point, otherwise no provisioning tasks will be executed.
A good strategy for setting up provisioning during the release process is to setup the deployment during a
step operation to deploy provisioned tasks before the scheduled time (
Federation After Deployment¶
Federate important application configuration information with external CMDBs if you have one.
Add webservices and federation calls to your deployment rule that will federate the configuration changes deployed by your last deployment job.