Habits are the human mechanism for simplifying decisions which drive what we do daily. When thinking about habits, it is essential to recognize they can be good, bad and with respect to our goals.

Heads of technology always have a love-hate relationship with DevOps. A solid DevOps team can provide cutting edge speed, collaboration and delivery but the kind of changes in the culture it brings along is difficult to accept and adapt in some organisations. Despite this, DevOps is being adopted across many organisations due to the good features it brings to the table. Hence, it has even become the new hack to get investment from IT investors these days. But in no way is the importance of DevOps being overstated by organisations that do abide by it. Future of organisations is highly dependent on their ability to deliver software faster and faster while not compromising on security and stability. This article on “10 Habits of all successful DevOps” will familiarize you with 5 best and 5 worst DevOps habits that your organisation can imbibe. ‍

The Good

1. Fail fast, learn fast: Failure is not a sin, it is something you should strive for to succeed in DevOps. Success by failure sounds contradicting. But it is executed by having failure built into the testing process. DevOps means a shift from the worry of failure to a desire to a fail-fast and learn. This does not mean that your goal should be to fail. Rather, you need to look at failure as an opportunity to learn and improve without playing the blame game. The sooner issues are discovered the cheaper it is to fix them, thus making failing early on a benefit. Once you fail fast, you need to learn fast and for this, the 2 most effective techniques are to make sure that you include strong Application Performance Monitoring tools (APM) which help you in identifying what caused the failure and feedback loops that raise immediate alerts in case of failures using tools like Slack to communicate.
2. Architect your delivery pipeline: Organisations need to treat their delivery pipeline like a product rather than a separate set of tools used to move a feature from idea to deployment. For this, they need to have a product owner for the pipelines who define stories and owns prioritization just like business products’ owners. Apart from this, the choice of the right stack matters too. The next great tool for CI/CD is always round the corner and they need to be a part of a company’s DevOps stack for a well-architected pipeline. But they need to be integrated using standard integration patterns and technologies that are model-based so that your workflow isn’t disrupted and the tools work the way they were intended. Customisation creates a dependency that will cost you in future when you need to replace or upgrade certain tools.
3. CI-CD: From being an added star in a company’s tech report card, CI-CD has now become the norm. The discipline of validating a project through automated regression testing whenever there's a commit into the version control system enables the development of quality solutions in small, safe and uniform steps. Continuous deployment helps development teams to scale back the time between a new feature being ideated and deployed in production which ensures responsiveness in companies.
4. Standardising and simplifying the environment: There ` things can be done making standards necessary while adopting DevOps. There is a need to have some rules around how the architecture and unfractured is configured. However, there is a reason why standardising and simplification are mentioned together. Sometimes, when adopting such standards, organisations hit an axe on their foot by overengineering. If teams are not given a certain autonomy, it leads to lower productivity. To prevent this, a right balance can be to have guardrails around how the infrastructure is architected but let teams choose what technologies they think is most effective for their needs.
5. Inculcate good programming habits: This point focuses on some habit changes in programmers that help. A strict no for programmers should be doing something manually even if it automated just because it is one time. This includes builds, merges, deletion of old files and so on. Another habit that should be made mandatory is writing documentation, the lack of which, while might not hurt in the short term, can be a disaster in the long term. Good documentation will make your code better incrementally. Such habits matter because long term maintainability should always trump over short term execution.  ‍

The Bad

1. Making DevOps one person or team’s job: The major failure in DevOps come when it is a one-person or team responsibility. With agile being adopted across the board, changes that occur in one team affect the entire organisation. Along with this, you will also be changing how deployment, monitoring and customer support happens. Thus, for DevOps transformation to truly succeed, silos never work and everyone should be involved and engaged. An easy way to do this is to simply redefine success as a satisfied customer from the current metric of a feature being shipped which will lead to everyone being accountable in the success measurement.
2. Trying to be Netflix: Netflix deploys multiple times a day and tries all new tools, so you should too. Right? No, you could not be more wrong. Organizations need to understand that business value is in observing the impact of each change and the way users react. Patterns of multiple deployments might even end up having negative business value if there are no behavioural patterns formed in end users that businesses can track and measure to make decisions. Ultimately, DevOps is not about being ‘cool’ and not all organisations have the resources that Netflix does.
3. Ignoring security early in the development cycle: There is a tendency of many organisations of being narrow-minded in DevOps with the focus being on faster releases but this usually comes at the cost of ignoring security during the development cycle and in production. The result of this is that there are security loopholes in the product and infrastructure that get missed by the team which leaves the product exposed and additional time is needed to apply fixes upon a breach, which makes security a game of catch up. It is thus a great practice to make security a core part of DevOps goals at your organisation.
4. Overdoing automation: Organisations need to understand that automation is about converting a manual process to automatic using technology. This means that if the manual process itself is flawed so is the automatic one. Automating this flawed process would just make it possible for mistakes to happen at a faster rate. So, organisations should know that overdoing automation would lead them to an unproductive extreme and that the primary focus has to be on understanding the requirement, developing, testing and then automating a process.
5. Making speed your only goal: In today’s world, the constant focus on releases without qualitative improvements is useless. Deployment automation should not be a focus for organisations without test automation. A focus solely on speed shows that while there might be an understanding of the aspects of automation in the organisation, the cultural groundwork of having developers, testers and operations team build automation collaboratively is missing.

The goal behind effective DevOps habits is to enable DevOps teams to maneuver fast with a continuous delivery workflow. Building a DevOps culture isn't an instant process, you can’t simply pull it out of the box. But if you're taking a thoughtful and incremental approach, DevOps becomes a strong combination of culture and tools which will elevate your business to a level of agility and quality that your competitors would find hard to beat. And adopting the above habits of highly effective DevOps will get you there.

It’s your turn now. Tell us in the comment section the habits that drove DevOps success at your organisations and the habits that you make sure are avoided at any cost. For more such articles, follow us on LinkedIn, and if you have queries specific to your business or want to leap into the cloud, drop in your contact details in the comment box and we’ll reach out to you.