It's very simple:
- Increasing speed
- Improving quality
- Cutting overhead
Anything and everything we do MUST cater to at least one of the above given three reasons. If that is not happening, you can consider it as DevOps going in wrong direction!
If you wish you can consider this as the only principle of DevOps. But let's understand how we can align our DevOps activities towards these core reasons.
To begin with even with minimalistic resources, you first need to find out the most painful part of the project, which is causing the team a slowdown. If it is getting approval from client or slow internet speed, certainly DevOps is not solution. But if doing a deployment takes a lot of time, or developer code collaboration is the problem, or running the test cases take a lot of time, we can think of putting in DevOps in action and start with the most severe problem first.
For any business, next to speed the top concern is quality. Quality comes from various factors starting from running automated test cases to logging defects properly. If we can implement a system which makes the quality of the work better by any means, we are doing the DevOps right.
At times, you can improve the speed and quality in a reverse way i.e. instead of doing something in better way, if we can at least stop doing things in bad way, that also is great contribution to project. If we find out the work team is doing, which can either be removed or be automated or modified to make things either faster or better in quality, we are doing DevOps right.
How to do DevOps (Theoretically)
Needless to say, that automation is core of DevOps from the implementation perspective. Most of the speed, quality or overhead de-cluttering we achieve using automation. We try to automate as much as we can, so that we can reduce the human error and increase the speed. Except code automation, almost everything has some kind of automation which we try to integrate with the system, be it unit test execution, deployment, functional test (including UI and API), security test, or anything else. You name it and you get it. From the cloud point of view, we also get into infra provisioning automation along with configuration automation. So there is a lot of automation in DevOps.
One major push in DevOps, talks about - going beyond your regular boundary and come out of the very famous mode - the code works on my system. Being the developer of a given functionality, you are responsible for its behavior, no matter what the environment is. You should know what makes or breaks the functionality. On the other hand, the ops team should also not immediately give up if something is not working. Both the team Dev and Ops should work closely to resolve the problems faster. [So much of expectations !!]
I guess talking about this is no more relevant but for the sake of theory, it goes something like this. The development teams should be habitual of few things, as their core culture:
- Committing the code to a code repository regularly; in best cases, on daily basis.
- Keep the habit of checking if the central build is fine after your code commit.
- Ensure nothing breaks due to your code commit by running the regression test cases, if available.
- After testing the code on your machine, test it in the central environment, say Development environment.
Keeping these level of practices are generally termed as culture for development team. Similarly, there are cultural aspect for testing team:
- Creating bugs in the bug tracking tools immediately after getting a bug.
- Ensuring test automation suites are available for functionalities which are manually tested.
- Ensuring to have regression test suite availability.
- Ensuring the seed data creation automation, as long as possible.
- Ensuring test automation execution and reporting on each deployment.
These were little extra work at one point in time. These are mostly the default expectations now a day.
It is expected from the developers to be able to understand the various environments e.g. Dev, QA, Perf, Prod, etc., beyond their own laptops. This enables them to debug the problem in any centralized environment. They should be able to understand how the application is deployed, the relevant infrastructure and networking. This not only makes them more knowledgeable but, in few cases, it helps them to see what implementation will work and what will not work.