Post published over one year ago
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.
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
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”
Let’s use LEAN value chian as example.
Reason 1 : DevOps removed requirement of communication between multiple teams and save our time via automation:
Thus, to enable DevOps, we need to make the procedure from build to deploy automated:
Reason 2 : DevOps changes structure of testing:
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.
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:
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.
To master CI/CD, the code style itself also should follow these principles:
Declarative : Only write “do what”, rather than “how” in config. Like the God said : “Let there be light.”
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
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)