Source Code Maturity levels

Have you jumped into DevOps wagon already? You probably have. But perhaps you still not sure if you are lacking a certain tool in your toolbox if you are working currently with DevOps.

Or maybe your organization or team is starting to plan to fully embrace DevOps and your team is researching what is exactly what to need to install in order to have the perfect toolchain. Perhaps you have a gap in some processes that you are not even aware of. Establishing a good and solid DevOps toolchain will help determine ahead of time the grade of the success of your DevOps practices.

In this blog post, we will be exposing maturity level checklists for different DevOps areas so you have an idea where you at in terms of Continuous Delivery.

We will review the maturity levels from the following DevOps aspects:

  • Source code management
  • Build automation
  • Testing
  • Managing database changes
  • Release management
  • Orchestration
  • Deployment and provisioning
  • Governance, with insights

Source code management tool

Commonly known as repositories. It works as a version control and can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.

This is the maturity level checklist. we go from a none or low maturity level to a high maturity state:

  • No version control
  • Basic version control
  • Source/library dependency management
  • Topic branches flow
  • Sprint/project to branch traceability

Source Code Maturity levels

Build automation tool

Continuous Integration (CI) is a software development practice that aims for a frequent integration of individual pieces of work. Commonly each person integrates at least once per day giving place to several integrations during the day. Each integration should be verified by an automated Build Verification Test (BVT). These automated tests can detect errors just in time so they can be fixed before they create more problems in the future. This helps to reduce a lot of integration issues since this practice allows to develop faster and in a more efficient way.
This is the automation maturity checklist to see how you are doing in your CI:

  • No build automation. Built by hand. Binary check-in.
  • Build automated by central system
  • Reusable build across apps/projects
  • Continuous/nightly builds
  • Feedback loop for builds

Automation Maturity Levels

Testing framework

Testing automatization can be in code, systems, service etc. This will allow the testing each modification made in order to guarantee a good QA. Even the daily or weekly release of code will produce a report that will be sent every early morning. To accomplish this you can install the Selenium app in Clarive.

This checklist will help to determine your testing practices level:

  • No tests
  • Manual tests
  • Automated unit/integration tests
  • Automated interface tests
  • Automated and/or coordinated acceptance tests
  • Test metrics, measurements, and insights
  • Continuous feedback loop and low test failure

Testing Maturity Levels

Database Change Management

It’s important to make sure database changes be taken into consideration when releasing to production. Otherwise, your release team will be working late at night trying to finish up a release with manual steps that are error-prone and nearly impossible to rollback.

Check what is your team’s database management current state:

  • Manual data/schema migrations
  • Automated un-versioned data/schema migrations
  • Versioned data/schema migrations
  • Rollback-enabled data/schema migrations

Database matutity levels

Since databases schema changes are sometimes delicate, make sure to include your DBA team into the peer review process, so that changes are 1) code; 2) can be merged and patched; 3) can be code reviewed.

Release Management and Orchestration

You can fully orchestrate tools that are involved in the process and manage your release milestones and stakeholders with Clarive.

Imagine that a developer makes a change in the code after this happens you need to promote the code to the integration environments, send notifications to your team members and run the testing plan.

Are you fully orchestrating your tools? Find out with this checklist:

  • Infrequent releases, releases need manual review and coordination
  • Releases are partially automated but require manual intervention
  • Frequent releases, with defined manual and automated orchestration and calendaring
  • Just-in-time or On-demand releases, every change is deployed to production

Orchestration Maturity Levels

Deployment tool

Deploying is the core of how you release your application changes.

How is your team deploying?:

  • Manual deployment
  • Deployment with scripts
  • Automated deployment server or tool
  • Automated deployment and rollback
  • Continuous deployment with canary, blue-green and feature-enabling technology

Deployment Maturity Levels


As part of deployment, you should also review your provisioning tasks and requirements. Remember that it’s important to provision the application infrastructure for all required environments, keep environment configuration in check and dispose of any intermediate environments in the process.

Yes, provision has also several maturity levels:

  • You provision environments by hand
  • Environment configuration with scripts as part of deployment
  • Provisioning of disposable environments with every deployment
  • Full provisioning, disposing and infrastructure configuration as part of deployment
  • Full tracking of environment-application dependencies and cost management

Provisioning Maturity Levels

We have come a long way doing this with IaC (Infrastructure as Code). Nowadays a lot can be accomplished with less pain using technologies such as containers and serverless, but you still need to coordinate all cloud (private and public) and related dependencies, such as container orchestrators.

In your path to provision automation and hands-free infrastructure, make sure you have a clear (and traceable) path to the Ops part of your DevOps team or organization, making sure to avoid bottlenecks when infrastructure just needs a magic touch of the hand. One way of accomplishing that is to have a separate stream or category of issues assigned to the DevOps teams in charge of infrastructure provisioning. We’ll cover that on a later blog post.

With the right reports, you’d be amazed by how many times releases get stuck in infrastructure provisioning hell…


Clarive has also productivity and management tools such as with Kaban swimlanes, planning, reports and dashboards that give managers tools to identify problems and teams a way to quickly check overall performance of the full end-to-end process.

Here are the key points to make sure you evolve the overall governance of your DevOps process:

  • There is no end-to-end relationship between request (why) and release (when, how, what)
  • Basic Dev-to-Ops traceability, with velocity and release feedback
  • Full traceability from request to deployment
  • Immediate feedback and triggers

Maturity Levels of Source Code Management

There you go, let’s devops like the grownups do

In this post, we have exposed the main Continuous Delivery aspects that every DevOps team should be looking forward to improve and their respective readiness levels. So go with your team and start planning a good DevOps adoption plan 😉

Schedule a demo with one of our specialists and start improving your devops practices.

Releases Across Pipeline

ARA is a key DevOps discipline that deals with managing the software and infrastructure changes brought about by a new release. In order to gain a clearer understanding of ARA, we could say that the development lifecycle involves two main areas:

  1. Component packaging release and environment planning

  2. Readiness and delivery pipeline automation

Efficiency in moving releases between environments is an important feature, which we can break down into the following seven subcategories.

1. Deployment Flexibility

Deployment needs to be flexible enough to accommodate options (across all platforms and for all environments) such as the following: mapping of dependencies, notifications, creation of shared components, handling of possible manual steps, dealing with concurrent releases, prioritization, window management and integration.

Clarive’s rule-driven deployment model approach, which is based on decision trees, allows the system to keep track of the relationship between all artifacts and their configuration, thanks to its graph database. Decision trees may include other releases.

Clarive integrated graph database keeps track of the relationship between all artifacts and their configuration. Rules support orchestration of both automated and of manual activities.

Clarive features a rule design palette containing the necessary controls for configuring the orchestration scenarios needed: pause job for manual tasks, add approval steps in the job pipeline, Clarive traps an error during the job pipeline rule execution and ask for manual input decisions from the Ops team or equivalent (retry, abort and rollback, skip and continue…)

2. Release Readiness

Release readiness features include deployment risk analytics, impact analysis, integration with testing tool results and automated triggering of quality gates based on test case results and pipeline execution governance.

Clarive provides support for release readiness, including impact analysis, deployment risk analytics, integration with testing tool results and automated triggering of quality gates based on test cases. It allows users to customize their experience using dashboards, rules, pipelines and custom reports.

Orchestration tracking readiness, which is used to track how close a release is to being production-ready is only possible in an end-to-end orchestration tool model.

3. Deployment Plan Management

There should feature a complete GUI for creation and management of role-based deployment plans, and the underlying logic of these should be displayed as transparently as possible.

Support for application deployment plan management that should include the following:

  • Control Logic – to enable unrestricted and flexible automation

  • Pipeline Diagram Support – graphical representation of logic

  • DevOps IDE Platform – an Integrated Development Environment for designing development plans

A decision tree structure/rule design, containing collapsible sections for each phase, is used in order to provide an overview of the end-to-end build, deployment, and post-deployment process. Should more sophisticated activities be required, nested deployment plans (reusing rules) can help promote readability and logic reuse.

4. Pipeline Governance

Pipeline governance includes support for root-cause analysis (RCA) and execution profiling, which serves as an aid when improving software performance.

RCA is a method used for problem solving by identifying root causes of faults or problems, and its implementation should be capable not only of tracing a failure to a specific version of a specific component, but also of incrementally patching the component, while highlighting any other components that require similar patching.

Clarive Root Cause Analysis Graph

Clarive Root Cause Analysis Graph

Deployment pipelines may be monitored through the built-in monitoring service, and individual steps can be traced and analyzed for execution failures, together with any details available from the OS or tool with which interfacing is performed.

Clarive comes with a root cause analysis (RCA) algorithm, whereby the tool contains an extensible database of root causes, and can match failures to said database.

5. Pipeline Recreation

Pipeline recreation refers to the ability to rerun a deployment using a previous version of an environment model and/or rule logic, and should also be a supported feature of an ARA application.

Clarive can determine which versions of which components were used during the delivery process by capitalizing on our software’s configuration management capabilities. The system can use the exact version of the delivery rules that was used for the deployment at the requested time.

6. Deployment Scenarios

Application Release Automation tools should offer flexibility in their support for full-featured deployment styles, thereby ensuring extensibility.

Some typical deployment scenarios one should take into consideration:

  • Canary deployments

  • Blue/Green deployments

  • Rolling or phased deployments

  • Hot deployments

  • Dark launch modes

Clarive supports any deployment scenario/strategy, including partial deployments, rolling and phased, as well as canary and hot, blue, green, and dark launch modes.

7. Test Data Management

Test integration is an important feature, therefore automation of test data preparation and integration with test management suites need to be supported.

Clarive release models can include test case and test data selection, with the ability to select the correct test strategy according to the type of release and release contents, as well as control which test data and test sets are to be deployed into an environment, and to scheduling when said deployment is to take place.

It is also capable of orchestration and working with any virtualization, automated testing tool and test data management tool featuring a CLI, REST or SOAP interface.

How Clarive Lives Up to Moving Releases

Clarive greatest strength is moving releases between environments while offering enhanced deployment flexibility, tracking release readiness and management of the release pipeline.

clarive changeset timeline

Clarive tracks every stage of releasing a change

There also features pipeline governance and recreation coverage, with built-in support for rerunning deployments using an earlier version of a given environment model.

In short

Application Release Automation has a very defined set of criteria for release pipeline management. Clarive matches every one of the standard criteria, and indeed surpasses them if we take into account extra features such as Kanban boards, advanced error control and a complete DevOps IDE platform for creating end-to-end automation, orchestration and collaboration of all the teams and assets involved in the organization of DevOps initiatives.

Want to know more about ARA? Check our presentation: Why ARA Matters and learn how to to take control over complexity to deliver a great workflow.

Running pipeline jobs to critical environments often requires a scheduled execution to take place. Clarive scheduled jobs run always in 3 main steps, called “Pre”, “Run” and “Post”.

Why run a pipeline in phases?

Most of the time the entire deployment job should not run all of its tasks at the scheduled time but as soon as the job is scheduled.

There are several phases or stages to every scheduled deployment, most of which can run as early as it’s scheduled. Tasks such as building, packaging, testing and even provisioning infrastructure can take place earlier if they do not impact on the productive environments.

When defining a pipeline, always think of what can be detected in earlier phases so that the evening deployment run will not fail on something that could have been checked previously.

Separating your pipeline into diferent stages

Separating your pipeline into different stages


Pipeline phases

Here are the different pipeline deployment phases you can run in Clarive.

Deployment preparation (PRE)

The deployment pipeline will take care of:

  • Creating the temporary deployment directory

  • Identifying the files changed to be deployed (BOM)

  • Checking out the files related to the changesets to be deployed from either code repositories (code) or directly attached to the changesets (SQL).

  • Renaming environment specific files (i.e web{PROD}.properties will be used just for deployments to the PROD environment)

  • Replacing variables inside the files (i.e. it will replace ${variable} with the real value of the variable configured for the project affected for the target environment)

  • Nature detection Clarive will identify the technologies to deploy analyzing the BOM

Common deployment operations

Common deployment operations


Deployment operations (RUN)

Actual deployment operations will be executed in this phase of the Clarive job (movement of binaries, restart of servers, check the proper installation, etc.)

Deployment operations

Deployment operations


Post-deployment operations (POST)

After the deployment is finished Clarive will take care of any task needed depending on the final status.

Some of the typical operations performed then are:

  • Notify users

  • Transition changesets states

  • Update repositories (i.e. tag Git repositories with an environment tag)

  • Synchronize external systems

  • Cleanup temporary directories locally and remotely

  • Synchronize related topics statuses (defects, releases, etc.)

Post deployment operations

Post deployment operations



Regardless of if you use Clarive or not, when defining your deployment pipelines always think on these three stages or phases.

  • PRE – everything that can run as soon as it has been scheduled
  • RUN – crucial changes that run at the scheduled time
  • POST – post activities or error recovery procedures

Happy DevOps!

Try Clarive now and start with your DevOps journey to continuous delivery.

In today’s fast-moving world of DevOps, we need ARA more than ever to take control over complexity to deliver a great workflow that can unite teams at different speeds in the enterprise.

These slides go over why, when and how ARA may apply to your enterprise.


Visit our documentation to learn more about the features of Clarive.

We’re pleased to present our new release Clarive 7.0.12. This release contains a variety of minor fixes and improvements from 7.0.11. It is focused on refactoring interface.

NPM Artifact Repository management

Clarive team is proud to release this version with artifact repository enhancement. This new functionality allows NPM packages management.

  • Now is possible to surf the NPM repository folders through the artifacts interface, content visualization and distinguishing the new packages that have been included in the repository.

Create artifacts tags in order to sort them out

  • Use Clarive NPM repositories that serve as proxy to the global NPM store in or just use them as local, so you can control which public packages are available for your developers
npm install angularjs --registry http(s):///artifacts/repo/
  • Use Clarive Groups of repositories to categorize packages and access several local repositories with just one registry
npm install angularjs --registry http(s)://<clarive_url>/artifacts/repo/<npm_repo_group>
  • Directly publish in Clarive NPM repositories with npm publish command
npm publish ./ --registry http(s):///artifacts/repo/
  • You can also publish packages through rulebooks
- publish:
repository: '' # repository name
from: ''
to: ''

Take a look to our docs website and learn how to configure your artifact repository in Clarive

NPM repository events exists in Clarive. So, for example, when the *npm publish* command is executed in one repository, the artifact will be published in Clarive, sending a notification email to your team. For more information go to our documentation and learn all you can do with events.

Improvements and issues resolved

  • [ENH] – Project menu revamp
  • [ENH] – Plugins code structure and formating
  • [ENH] – Owner can cancel and restart jobs
  • [ENH] – Interface plugins standarization
  • [FIX] – Docker images cache management
  • [FIX] – Show subtask editable grid only during edition
  • [FIX] – Differentiate environments and variables in menu

Ready to upgrade?

Just follow the standard procedure for installing the new version. Click here to get it from our Install page.


Join us in our Community to make suggestions and report bugs.

Thanks to everyone who participated there.

Get an early start and try Clarive now. Install your 30-day trial here.

This video shows how .net applications can be deployed with Clarive

For this deployment a SINGLE pipeline is used to deploy to the DEV and QA environment.
Assuring a consistent way of deploying.

In a next video this changeset will be related to a Release and deployed together with a mainframe application change and a Java application change into production. Again with the SAME pipeline.

Visit our documentation to learn more about the features of Clarive.

We’re pleased to present our new release Clarive 7.0.11 with two new administration features. 

Rulebook Variables

Now you can keep your rulebook variables private with secret variables. The content is not visible to the user and the data is encrypted to the database.

Variables also now have multiple scopes. Define the scope in the variable and it will only be available for rulebooks that run under the given scope.

clarive variable definition

Users can only manage variables for owned projects

Docker Admin Interface

Clarive rulebooks can download, install and run shell commands within Docker images with the image: op. Starting with this release, you can manage all Docker images and containers installed and available to rulebooks on the Clarive server.

The Clarive Docker admin panel can manage both instances and containers. A complete list is shown including the current status of each one of the containers.

Using the containers list you can do over them actions like start, stop and delete. You can delete Docker images too to keep your image registry tidy and remove old images.

Improvements and issues resolved

Other small fixes and enhancements added to the release:

  • ENH – Small Kanban improvements
  • ENH – Update js libraries
  • ENH – Variable management for rulebooks
  • FIX – Topic grid filter bugs
  • FIX – Rulebook sed op fixes
  • FIX – Push to git repositories allowed with no project related to repository (Enterprise Edition Only)

Ready to upgrade?

Just follow the standard procedure for installing the new version. Click here to get it from our install page.

Cloud images have been updated automatically in case you are a user of our cloud.


Join us in our Community for suggestions and bug reports.

Thanks to everyone who participated in making this release possible.


The next release, 7.0.12 will come out on the first week of January 2018 with mostly bug fixes and small enhancements.

And a major release, 7.1 is coming up later in January packed with some awesome additions:

  • A brand new navigation interface, with tabless project-oriented navigation
  • A revamped Git repository interface
  • A new admin interface
  • Revamp documentation
  • And much more!

Visit our documentation to learn more about the features of Clarive.

Clarive SE 7.0.10 Release Notes

Release date: 5 December 2017

We’re pleased to present our latest Clarive SE product release: 7.0.10. This release contains a number of minor fixes and improvements from 7.0.9. We are also excited that this release includes two unique brand new features.

Feature Highlights

  • Custom Kanban swimlanes

  • User Inteface enhancements

Custom Kanban swimlanes

The Clarive DevOps Kanban is the most flexible and comprehensive board for managing and tracking delivery. In this release we are including a substantial representation improvement: Now you can create and customize your own swimlanes.

Custom swimlanes can be defined only by the board owner. Users can either clone a board or notify the owner if they want to customize a swimlane

Configuration has been made simple: You can select the fields that you want to use as swimlane and select the values that can be used as a lane in the Kanban board.

In 7.0.10 introduces a new type of swimlane, release parent topic.

With this you can get for example a quick glimpse of what features are included in each release by simply opening the board. Of course, you can filter according your preferences in swimlane mode.

Kanban boards allow dragging and dropping of topics from one lane to another across all swimlanes. Such an event, as expected, will update topic data and relationships automatically.

Kanban view with parent topic swimlane can allow you move topics from one Sprint/Release to another one easily.

User Interface enhancements

User experience is key for us, so the product team is continually focusing on how to improve the Clarive interface and UX. At present we are making small changes such as increasing menu paddings, buttons redesign, and overall layout distribution. Our greatest effort in UI enhancements in this release has gone into improving two screens: the job monitor and the topic list.

In the pipeline Monitor you can now even more easy identify the relations between code, topics, environment and deployments, job-by-job, with links to log data, generated artefacts and job profiling and scheduling information.

With the new right side row action menu we simplified the job action UI and the way to interact with each job row from the row itself.

Job statuses can have colors in order to better identify and distinguish what is the current status of your deployment. All our job filters are still available in the toolbar.

Click on job or go to Menu->Deploy to have a look to job dashboard. See full job log clicking on Menu->Log.

In the Topic list we simplified the toolbar moving topic actions under the “more options” menu . “More Options” basically covers any action not related to view display.

As with the monitor, we want the user to easily correlate deployments and topics, so this release includes a new column that assists users to determine the current status quickly.


Each circle icon has a specific meaning:: “MR” is Merged (green if the topic has been merged), “CI/CD” for Continuous Integration/Deployment, and “NB” indicates the release Nightly Build status.

Improvements and issues resolved

  • [ENH] – Cleanup and delete expired sessions in purge
  • [ENH] – Get free license website opened in new tab
  • [ENH] – Round user avatar
  • [ENH] – New server log colors
  • [ENH] – Publish internal plugins
  • [ENH] – Remove repository revisions in repository deletion.
  • [FIX] – Small profile changes
  • [FIX] – Rulebook sed operation tests
  • [FIX] – Allow all REPL languages unless role action limit it

What else is new?

We are now sharing our documentation on Github. We appreciated your valuable help and feedback to improve our documentation. Pull requests are welcome, just clone and/or submit them through our github site.

You can also directly edit the documentation through the documentation page.

Ready to upgrade?

Just follow the standard procedure for installing the new version. Click here to download and install the latest version.


Join us in our Community for product suggestions, feature requests and bug reports.

Thanks to everyone who participated in delivering these great release.

Visit our documentation to learn more about the features of Clarive.