--- title: "Enterprise release management | Clarive" description: "Plan and deploy releases on your own servers, from the mainframe to Kubernetes, with approvals, deployment windows and a record of every step, including code written with AI." url: "https://clarive.com/enterprise" --- # Every change to production, approved and on record Banks and telecoms run Clarive on their own servers to plan releases and deploy them, whether the target is a mainframe, a Linux server or a Kubernetes cluster. Every step leaves the record an auditor asks for. In 2026 more of the code in those releases is written with an AI assistant, and it reaches production by the same route as the rest. [Schedule a demo](https://clarive.com/schedule-a-demo) [Talk to us](https://clarive.com/contact) ## More code from AI assistants, one route to production Ninety percent of the nearly 5,000 technology workers who answered Google Cloud's [2025 DORA survey](https://dora.dev/research/2025/dora-report/) use AI in their work. The same research found that AI now speeds up software delivery but still makes it less stable. The [2024 edition](https://dora.dev/research/2024/dora-report/) had estimated the size of that effect: a 7.2 percent drop in delivery stability for every 25 percent increase in AI adoption. DORA calls version control "a critical safety net" for teams that code with AI, and it found that AI does more for team performance where rollbacks are frequent. A release tool can't make the code any better. What it can do is hold every change to the same approvals and give each one a way back out. Clarive treats a change written with an assistant like any other. It belongs to a topic, travels in a release and is deployed by a job that waits for its window and its approvals. Clarive 7.22 has no AI model of its own. The assistants are the ones your developers already use. ### Configuration an assistant can read Since version 7.22 Clarive can also write its own configuration as text. Rules, roles, servers and per-environment variables export to [HCL files](https://docs.clarive.com/en/hcl/overview/) that refer to each other by name rather than by database id. An assistant can read those files and propose a change the way it edits code, and the team reviews the change in Git. Nothing reaches the installation until [cla import-plan](https://docs.clarive.com/en/cmd/cla-import-plan/) lists what would change and a person runs `cla import`. [cla diff](https://docs.clarive.com/en/cmd/cla-diff/) returns 1 when an installation no longer matches its files, so a scheduled job catches a change somebody made by hand. cla import-plan ``` $ cla import-plan ./cla-objects 1. CREATE generic_server.back-office (15 attrs) 2. UPDATE generic_server.front-desk (1 attr) 1 create, 1 update, 2 unchanged ``` `cla import-plan` works out what an import would change, and changes nothing. Output from the Clarive documentation. ## Who may change production, and proof of who did Since January 17, 2025, banks and other financial firms in the European Union have worked under the Digital Operational Resilience Act. Its technical standard on ICT change management, [Commission Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg%5Fdel/2024/1774/oj), asks for "the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes." It also asks for fall-back procedures for a change that fails. The rule makes no exception for code an assistant wrote. Clarive doesn't make a bank compliant. It enforces the steps the bank's own procedure sets out and keeps the evidence that each one happened. - **Roles scoped to an environment** A permission in a role can be limited to one environment, project, topic category or status, and any permission can be an explicit denial. The person who requests a change and the person who approves it can hold [different roles](https://docs.clarive.com/en/admin/roles/). - **Approvals inside the job** A deploy job can stop and [wait for a named person or role](https://docs.clarive.com/en/palette/job/request-approval/). Both an approval and a rejection are recorded against the job, with the approver's name and comment. - **Deployment windows** [Calendars](https://docs.clarive.com/en/admin/calendaring/) give each environment Normal, Urgent and No Job slots. A production freeze is a No Job slot, and a pipeline can ask for an extra approval when a job runs in an Urgent one. - **A way back** Moving changes back out of a deployable status starts a rollback job. A pipeline rule can also mark the steps that [need undoing](https://docs.clarive.com/en/guide/rollback/) if a deploy fails halfway. - **A record of every step** Each status change keeps the user and the date. The [job log](https://docs.clarive.com/en/getting-started/job-log/) shows what ran on which server, and the [Rule Designer](https://docs.clarive.com/en/admin/rule-designer/) keeps every saved version of a rule with the name of whoever saved it. - **Sign-in and secrets** People sign in through [LDAP or Active Directory](https://docs.clarive.com/en/admin/ldap/), or through a [SAML 2.0](https://clarive.com/blog/saml-2-0-support) identity provider such as Microsoft Entra ID. Password variables are stored encrypted, and [cla export --secret omit](https://docs.clarive.com/en/cmd/cla-export/) keeps them out of HCL files. cla-objects/prod/role.hcl ``` role "deploy-manager" { name = "Deploy Manager" description = "Runs deployments" mailbox = "deploys@example.invalid" grant { action = "action.job.create" bounds { bl = "PROD" } } grant { action = "action.job.delete" deny = true } } ``` A role from the Clarive HCL documentation. The people who hold it can create deploy jobs for PROD and can never delete one. ## From a request to production, in five steps This is the usual path of a change through Clarive at a large company. The statuses and approvals along the way are the customer's own. 1. **A change starts as a topic** Requests, defects and user stories are all [topics](https://docs.clarive.com/en/concepts/topic/). Each category has its own form, statuses and workflow. A field or a transition can be limited to certain roles. Code is linked to the topic it implements. 2. **Topics travel in a release** A release groups changesets from one project or several and has a workflow of its own. Promoting its changes into a [deployable status](https://docs.clarive.com/en/concepts/status/), from a form or by dropping cards on a kanban board, creates the deploy job for that environment. 3. **The job waits for its window** A job runs only in a calendar slot open for its environment, and only after the approvals its pipeline asks for. [Semaphores](https://docs.clarive.com/en/concepts/semaphores/) stop two jobs from running the same critical part of a rule at once. 4. **A pipeline rule deploys it** The rule runs the job's steps on each target over SSH, through the ClaX agent or through a [worker](https://docs.clarive.com/en/admin/worker/) that connects out from behind a firewall. One rule can cover every platform in a release, so production gets one job rather than one per technology. 5. **The record stays** When the job ends, the topic, the release, the approvals and the job log all point at one another. Jazztel used this to trace each production deploy back to the lines of code behind each change request. ## Mainframe, servers and clusters in one pipeline The banks we work with rarely retire a platform. They add one next to it. Clarive deploys to Linux, Unix and Windows servers and to AWS and Docker. Kubernetes and OpenShift take one step in a rule that runs kubectl or oc. Mainframe support, for z/OS with Endevor, ChangeMan ZMF and JCL, comes as add-ons to the core product. Banco Sabadell chose Clarive in 2014 partly for that range. Its case study lists Linux for the Bantotal banking core, AIX, HP-UX and mainframe systems, with changes built by a development center in Uruguay and delivered to Spain and Mexico. - [DevOps on the mainframe](https://clarive.com/blog/mainframe) - [Orchestrating Endevor](https://clarive.com/blog/orchestrating-endevor) - [Deploying to Kubernetes](https://clarive.com/blog/deploying-to-kubernetes-with-clarive) - [The ClaX agent](https://clarive.com/blog/introducing-clax-your-swiss-army-knife-for-remote-deployment) - [Bantotal](https://clarive.com/bantotal) ## What customers and analysts have said Our case studies, and the analyst reports that named Clarive. Each one carries its date. > "Clarive allowed us not only to orchestrate both Java and Mainframe delivery lifecycles, but also to save a lot of money by replacing expensive and underused legacy tools." Susana Soler, release manager at Banco Sabadell, 2017 Banco Sabadell went live in January 2015 with 170 users and had 250 by that October, running 600 deployments a week in the first phase. Clarive orchestrated 14 of the bank's tools. [Read the case study](https://clarive.com/resources/bank-sabadell-case-studies) > "Using Clarive's Top-Down Release Management support we were able to speed-up our release delivery by over 60%, reducing operational costs and overall process latency." Sarai M. Buil, configuration manager at Jazztel, 2016 About 150 people used Clarive at Jazztel, now part of Orange, and it ran more than 1,200 deployment jobs a month. [Read the case study](https://clarive.com/resources/jazztel-case-study) Ovum, March 2016 Ovum rated Clarive a leader in its Decision Matrix for DevOps release management. "Clarive is a relatively new player in the DevOps market with one of the highest performing solutions in the ODM," Michael Azoff of Ovum said in the report. [Read the report](https://clarive.com/resources/ovum-decision-matrix) Gartner, 2015 and 2016 Gartner named Clarive Software one of five Cool Vendors in DevOps in April 2015\. A year later Gartner included Clarive in its first Magic Quadrant for Application Release Automation, published August 1, 2016. Customers have included Banco Sabadell, BNP Paribas, Telefónica, Capgemini, Jazztel and the Bank of Spain. Ovum Decision Matrix: Selecting a DevOps Release Management Solution, 2016-17, Michael Azoff, March 2016\. Ovum is now part of Omdia. Gartner, Cool Vendors in DevOps, 2015, Ronni Rosenstein, Joachim Herschmann, Lydia Leong, Colin Fletcher, Dennis Smith, Vivek Bhalla, Thomas Murphy, 21 April 2015\. Gartner, Magic Quadrant for Application Release Automation, Laurie Wurster, Colin Fletcher, David Paul Williams, 1 August 2016. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and COOL VENDORS and MAGIC QUADRANT are registered trademarks of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. ## On your own servers, with support behind it Clarive runs on your own Linux servers next to a MongoDB database, inside your network. The [dispatcher](https://docs.clarive.com/en/admin/dispatcher/) can run on several servers for failover and load balancing, and MongoDB can run as a replica set. - [Install Clarive](https://clarive.com/install) - [Read the support SLA](https://clarive.com/sla) - **Standard support** Comes with the first year of a license. It covers business hours, Monday to Friday, in the customer's own time zone, with a first response to an outage within four hours. - **Gold support** Runs around the clock. It answers an outage within an hour and adds phone support and emergency patches. ## See a release go from request to production Tell us which platforms you deploy to, and we'll show you Clarive running a release across them. [Schedule a demo](https://clarive.com/schedule-a-demo) [Talk to us](https://clarive.com/contact)