What is DevOps and What isn't

Posted by Riino on

What is DevOps?

DevOps = Development + Operation?

Actually, DevOps is not the combination of development and operation. The key point is “Developing , while operating”

And, DevOps highlights that development and operation should be hold in same place, rather than 2 individual teams.

Final Goal: Continuous Delivery（CD）

*1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.*

------12 Principles Behind the Agile Manifesto

Continuous delivery is the ability to get changes of all type, including new features,configuration change, bug fixes and experiments, into production, safely and quickly in a sustainable way.

------Jezz Humble , Continuous Delivery

For Continuous delivery, we must build deployment pipeline, which means that every changes will go through all test before deployment. (DOD, definition of done), and we call it Continuous Deployment , and DOD means “ready for deploy”

image-20200823120603092

Why DevOps

Let’s use LEAN value chian as example.

Reason 1 : DevOps removed requirement of communication between multiple teams and save our time via automation:

image-20200823120401029

Thus, to enable DevOps, we need to make the procedure from build to deploy automated:

image-20200823120501543

Reason 2 : DevOps changes structure of testing:

image-20200823120623622

The left is traditional test and the left is DevOps, the larger the area is, the more efforts there should be .

The key point is to move UI test into more standard interface test. And break down project into maintainable modules.

CI with DevOps

image-20200823121600179

To archive our goal of CD, we need CI: Continuous Integration. CI defines a serious methodologies as a guidance for developer about how to maintain development procedure. The CI and CD always be regraded as a whole unit called CI/CD. Because **to enable CD we must build CI, and the CI’s goal is exactly to archive CD **, in this way, you can not isolate CI and CD

CI is a hard thing to do, and many people think that they are using Ci, but it’s not true.

To archive complete CI, you have to follow these basic principle:

  1. If you are using feature branch, you are NOT using CI.
  2. Everyone commit to master branch. (Every change will be in deployment finally.)
  3. If build and test fails, it can be repaired within 10 min.

Deployment Toggles

In most cases, release procedure won’t follow deployment procedure. So there’s should be manual toggle to let us switch the case of release environment (proc environment), while the real deployment may have be done several weeks ago. And PM can decide when to release next update if client don’t like to get updates frequently.

Via such toggles, we can easily modify proc environment, while make no effect and without any issues.

Now, some technology are trying to make this automated too, like Auto Scaling in remote servers.

Code Style

To master CI/CD, the code style itself also should follow these principles:

  1. Declarative : Only write “do what”, rather than “how” in config. Like the God said : “Let there be light.”

  2. Immutable : When develop next version, checkout into a new branch, them merge it to old version(always have a functional version). Keep everything in version control

Improvement

If you can’t quantify it , you can’t improve it.

To improve CI/CD pipeline, you have these tools as examples:

  • Time between change commit to deploy

  • Mean time to recover (mttr)

  • Failure rate

  • Cycle time

    etc.