Shulou(Shulou.com)05/31 Report--

CALMS and its relationship with the database DevOps is what, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

CALMS is an acronym for framework that allows companies to assess their readiness for a DevOps trip and what they can improve. CAMS (without L) was first introduced by Damon Edwards and John Willis after their first US DevOps Days in 2010. Jez Humble later added L to stand for Lean, and now the full meaning of the acronym is:

Interestingly, advances in database development software now mean that the same framework can be used to assess whether enterprises are also ready for database DevOps.

Culture

When talking about DevOps, culture is at the core of the transformation it can inspire. The DevOps culture has changed the way companies work, enabling teams to produce excellent results to the satisfaction of users.

An important part of the culture is to break down the islands that exist within the organization so that Dev and Ops can better work together to achieve the same goal-happy users. It is no longer working on my machine or it is not my problem atmosphere. Now, let's work together to provide the best experience for users. This is to enable the team to do the best thing for users and to ensure that they can publish as needed.

This is very important for the database. Traditionally, DBA has been isolated in its own department and is often seen as a bottleneck in releasing changes faster. They take full responsibility for the performance of the production database and the security of its data. Now the entire team-developers and DBA---should consider how to release as smoothly as possible, how to run in production, and where to build security.

Automation

Automation is the key to DevOps. If you want to publish more frequently, the publishing pipeline is ideal for automation. It is completely repetitive, and automation will help eliminate any manual errors.

Another benefit of automation is the traceability it provides. You will be able to see exactly which environments and when which changes were applied. You can even see who made the changes and why; maybe they have something to do with user stories, or they may be needed for bug fixes. If you have any manual approval steps in your pipeline, you can also see who reviewed the changes and signed the release.

Continuous integration of a series of automated tests is important for automated versions. The output of CI is a package containing all the files needed for publishing and will be used for deployment to other environments, so you only need to build once and the deployment is consistent. Automated testing (unit, smoke, integration, performance, GUI) is also important to provide release confidence and identify any problems before they reach production and affect users.

Automation does not mean continuous deployment. In continuous deployment, every time a change is committed, it flows through the release pipeline until it is deployed. To do this, you need to have a lot of trust in automated testing.

Instead, I'm talking about continuous delivery, where automation is used to make changes so that changes can be released as needed after review. This is becoming more and more common in application development, and the process looks like this:

A typical deployment pipeline that treats database development as an isolated process

Many DBA get scared when they hear that automated database changes are released to production. But again, I'm talking about automation and continuous delivery, not continuous deployment. It is also easy to include audit steps as part of the automation pipeline so that DBA can know exactly what happens before any changes occur in production.

It actually looks much simpler to include the database in continuous delivery rather than complicating the process. If the tools for database development are integrated and inserted with the tools already used for application development, it is much easier to introduce it:

Deployment pipeline with database development as part of the continuous delivery process

Another benefit of automation and databases is the ability to automate test deployment in a temporary / pre-production environment as close as possible to production. This provides the best chance of success by testing the deployment script for the last time before running the deployment script in production.

Shit.

Streamlining is added after the initial conversation and is an important value of DevOps. Lean focuses on incremental improvement and divides the work into small batches. Small batches allow you to release frequently during development. This is important so that you can get real user feedback and learn from it so that you can adjust and adjust to your learning needs.

It is difficult to apply Lean to the database. You really should care about the whole system. The database is part of the system. This further emphasizes the importance of databases as part of the culture (breaking islands) and automation so that you can improve on these frequent incremental versions.

Measure

Measurements are important for getting quick feedback and continuous improvement, because only when you have a benchmark to measure can you know if you have made a difference and need to improve. The first area to start measuring is your internal process, such as the time it takes to commit the code to run in production, the frequency of release, the failure rate, and the average time to recover from the failure.

You can also include telemetry-how users use your system, whether they have discovered new features, and how to improve them.

The second aspect to be measured is the health of the system, which needs to be monitored. In this way, if something goes wrong, you can react quickly, or even better, proactively fix content that may be a problem, so that you can satisfy your users.

For databases, measurement internal processes and telemetry are done as part of the system, because your database should be included in your release process. Monitoring databases allow you to ensure that they are executed correctly and can be configured to provide alerts about performance problems or insufficient disk space before problems occur.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.