DevOps is more than just a buzzword; it’s about delivering value to customers faster and more reliably. Over and over again I have witnessed organizations that seem to go out of their ways to introduce practices that seem designed stop value being delivered efficiently. In the ten years that I’ve spent developing and releasing apps, I’ve learned that there are critical steps every IT organization should follow that ensure DevOps success.
While many of these may seem obvious, experience has taught me that at least one or more of these steps are overlooked. In this article, I will explain eight mistakes organizations make that can dramatically increase cycle time and slow the flow of releases to customers, which is counter to the goals of DevOps.
1. Not Planning For Scale
Think long term when you embark on the process of bringing development and operations closer together. Create processes that will scale from day one. An example of a process that won’t scale is having a single gatekeeper to approve all changes in an automated process. Having a single person able to approve work may work with a few releases per year but that person will become a bottleneck if there are many releases per week. If you’re successful, you’ll need to scale faster than you ever imagined. Not planning for scale is a fundamental problem I’ve seen over and over again. Simply put, even if you have amazing success when there isn’t as much work going through the system, if your processes don’t scale the processes will quickly become a bottleneck. Allies may quickly become disillusioned and your DevOps initiative may be seen as something that only works for small teams.
2. Not Preparing Your Codebase For Frequent Releases
Another problem I’ve witnessed, even in projects using the latest technology, involves the codebase. All too often there are a few key files in a codebase that need to be worked on for many, many changes. These can cause significant merge problems, which can result in time being lost on a daily basis. Refactoring is key to moving forward at this stage. Cries of “I can’t make this change because it will affect x,y,z," and "It will take several weeks/months...” are strong indicators that a codebase may have problems that can be solved by refactoring. Stakeholders must be involved when the product or feature needs to be refactored; the change involved can take time and isn’t without risk, although this risk can be reduced by having unit tests.
3. Not having Extensive Unit Tests
I’ve been astounded by how many times I’ve witnessed teams doing continuous integration (CI) without having unit tests. A CI build only proves that the codebase still compiles. If you don’t do unit tests, your automated system tests aren’t proving anything. And if you’re doing manual tests executed on a build that would never have passed unit tests, you’re just wasting valuable time and resources
4. Not Designing Automated Tests To Scale
A common problem encountered when writing automated tests is that before long test suites take too long to execute. Even seasoned veterans mistakenly create test cases that are dependent on the outcome of other tests. Tests with dependencies on the outcome of other tests do not scale. Soon, test suites that used to run in minutes will take hours to execute, and as the test coverage goes up, so does the cycle time.