Until now, there is an idea that DevOps is such an advanced sysadmin who knows more than any other sysadmin. In fact, DevOps – Development Operations is the culture of development processes. It includes everything: how you set priorities, which technologies you use, how you interact with customers, etc. The goal of DevOps is to deliver a product as quickly as possible. It is a product that works the way the customer needs.
Constant feedback from the customer
To say “the more deployments, the better” is like saying “the more lines of code, the better”. The whole world uses Continuous Delivery, an approach in which software is made in short iterations. But engineers often forget that the business itself must be included in the process. The CD will not be complete if you don’t get continuous feedback – does the product work the way the customer needs it to? Are the new features in demand? Do they help in solving business tasks?
You should always warn your customers how often the product demo will take place. Even if you have changed the “one button color” – be sure to show it at the next meeting and argue your decision. This approach allows us to find problems in integration much earlier and solve them at the development stage. The sooner you find a bug, the less time it will take to fix it. This means that your company will save resources – staff time, server capacity, etc. For the client to give normal feedback, the feature you have just released should work well. And our next principle is related to this.
Success Delivery
What good is it for frequent deployments if the product is unstable? Our other principle is successful delivery. If during or after the deployment nothing works or works badly, the customer will have many questions. So success delivery directly affects the trust in you.
If we talk about approaches, we should mention the Blue-green deployment. Blue-green deployment is the creation of a copy of a product with new features next to the previous version, on the same server. At the right moment you just switch the client from the old version to the new one. The beauty of the pattern is that if something does not work in the new version, you can do it all back.
Another approach is the Canary deployment. When you use it, you only give 5% of the load of the new version and 95% of the load of the old version, and then we evaluate how users interact with the new features and how the system manages the load. Previously, Canary deployment could only be done on expensive devices, today everyone can use the approach.
Maximum Fast Feedback for Developer
A person cannot be multitasked. Usually happens this way: the developer makes a commit, and then decides not to drag and go to the next task. Now it will take him time again to dive into the details of the previous one. And if you commit and immediately see a message that something is broken, you can quickly go back to the context and fix it. So you should give very fast feedback, ideally in a few seconds. Of course, it doesn’t always work that fast. Your frame is no more than 5-10 minutes. This is the time a person will not have time to move the focus.
To do this, you should use automation, to be more precise, automated tests. If there are too many tests, you decide: maybe they should be paralleled? Or should they be broken into pieces? Shall we give the test results one by one, in groups? All best practices are stored in an internal knowledge base. If you want to hire specialists, use devops service providers. This will allow you to quickly and efficiently implement the technology in your company.