CALMS for DevOps and Databases

Many companies already apply the CALMS framework to their application code or front-end development process. Advances in database DevOps software and processes now mean the same framework can be used to for database code or backend process so that you can apply CALMS to the full stack.

What is CALMS?

For those of you that aren’t familiar with CALMS, here’s a quick primer. CALMS is an acronym for: Culture, Automation, Lean, Measure, Sharing. In IT, you fight acronyms with acronyms. Prior to CALMS, ITSM (Information Technology Service Management) principles reigned supreme in the IT world. With ITSM, repeatability is a main component, but the structure and processes are not primary objectives.

In practice, CALMS is a DevOps framework. Where ITSM is focused on documentation and change control, DevOps focuses on the people and culture aspects of software delivery.

Culture

In CALMS, culture is the key component. It’s a nod to the fact that at the end of the day, the most important (and arguably the toughest) part to get right in DevOps is putting the culture in place to remove barriers and facilitate collaboration to hit team objectives. Culture takes time to cultivate by rewarding helpful behaviors. If you can get this part right, everything else tends to fall into place easily.

Culture for the whole stack

Most companies implement the culture change for DevOps within the development team first, which is great. The next step is to make sure the culture is in place throughout the entire process, including the data layer. Most of the time, DBAs are separated into their own silo. The database side may as well be in a completely different universe.

Since the development team is running smoothly, when it comes time to incorporate ops teams into the DevOps culture, groups such as DBAs and security are forced into the existing culture. This doesn’t go well. Now, this doesn’t mean you need to start from scratch to fit these teams into the model—just understand that everyone will need to make adjustments as other groups such as the database team are incorporated. This will take time.

The goal is to get the whole team—developers, security and DBAs—to share responsibility for smooth release cycles, including overall performance and where to build in security.

Automation

The whole reason most organizations adopt DevOps is the promise of faster releases. In order to go as fast as possible, you need the help of your robot friends. Enter Continuous Integration practices and the Continuous Delivery pipeline (aka CI/CD).

Small + Fast = Better

Some benefits of Continuous Delivery:

• Speed time-to-market
• Increases quality by eliminating manual errors
• Limits work-in-progress
• Decreases lead time for changes
• Improves mean time to recover
• Everything is traceable (hello, easier audits!)
• Increases release confidence

DevOps automation for database changes

To make your Continuous Delivery pipeline work at its full capacity, you have to consider everything as code. This includes the data layer.

Continuous integration pipeline when you don’t include the database.

Continuous integration pipeline with the database included.

When you include the database in continuous integration, the process is much simpler. Application code and database code follow the same release process, time market for new features is accelerated and database code quality is greatly improved.

Lean

You may have heard of Lean Manufacturing or Lean Startups. Lean principles originated in the Japanese manufacturing industry. The Lean in CALMS helps translate Lean to DevOps. At the most basic level, it’s the systematic method for eliminating waste without sacrificing productivity.

In DevOps, you don’t want to move big chunks of changes to production. DevOps helps create a constant flow of small, easy-to-control changes.

Lean for the database workflow

See the whole! Database changes and application changes often go hand-in-hand; they are an essential part of the overall continuous delivery process. Since the whole system matters, it’s crucial to consider applying Lean principles to the database team’s workflow. Lean further emphasizes the importance of automating database change automation so that there are frequent incremental steps along the way to ensure your team delivers as fast as possible in small chunks.

Database rework

In a recent survey, participants were asked how often they must re-work a database change before it’s released to production. Database rework numbers are staggeringly high. For teams with daily or weekly release cycles, 93% say they have to rework database changes multiple times.

Measure

It’s not possible to improve if you’re not measuring. A successful DevOps implementation takes three different areas into account:

• Performance metrics
• Process metrics
• People metrics

The most successful DevOps organizations don’t just track technical metrics, they also look at measurements of team health and performance.

Measuring the data layer with database deployment information

To truly realize full-stack DevOps success, most organizations need a clearer view into their database deployment process. How many database changes have been made? How many database changes are pending? How many build failures are happening because of database rules violations? Learn how Datical makes database deployment measurement possible.

Sharing

Sharing improves communication flow and helps people work together more effectively. It’s important to share ideas, experiences, and thoughts within the team and with the whole organization. Sharing key performance metrics with all stakeholders in your organization lets everyone monitor your DevOps efforts and prove success at every stage.

Sharing between the development and operations

DevOps exists to bridge the gap between developers and operations teams. A big part of that process is to ensure that both sides are sharing responsibility for the overall quality of the application. That means no more finger-pointing about database changes moving too slow or developers not following DBA rules. It’s no longer us vs. them. In order to get to that happy place faster, it helps to have the right tools and processes in place to facilitate this relationship.

When you take advantage of including the database in your DevOps processes, barriers will come down and DBAs will see the value of working on complex changes with development teams early in the development process, instead of finding problems when the changes reach production.

Liquibase helps improve the developer-DBA relationship by helping these functions work closer together in the process so that they are sharing the responsibility for the application as a whole.

Liquibase Makes DevOps Teams Successful

It’s true that DevOps success relies on software tools and processes, but ultimately, it’s about enabling people and shaping culture. Liquibase tools and processes empower your DBAs and developers so your whole team can enjoy DevOps success. Request a demo

Want to have a handy downloadable version of this topic? Get a detailed white paper about Applying the CALMS Framework to Database DevOps.