Continuous Build and other DevOps anti-patterns, and how to overcome them

Abstract/Description

Software development is hard and poorly implemented or broken tools, techniques, and patterns just make it worse. Learn to spot DevOps anti-patterns and how to work your way back to a sane way of working.
Continuous Build is an anti-pattern that I have often seen where a team will have what they call Continuous Integration (CI) in place but it only builds the code, there are no unit tests or static analysis run. Certainly, this is better than not building but it leaves a lot of health check information on the table that is considered part of CI. Without this information, you can never really gain the confidence that your build is healthy. The whole goal of CI is to feel that your build is healthy so not tests and analysis means you aren’t doing CI.

Just like CI, other DevOps practices can be hard to understand, implement, and get right. Even with the best of intentions, we make mistakes or misinterpret the implementation of a technique. Learn how to spot common DevOps anti-patterns and how to correct them. These patterns include
1. Continuous Build – CI without tests isn’t CI
2. Turning unit tests off to build the release
3. Don’t automate that, it is my job
4. Different build process for developers and high environments
5. Different deployment process for developers, test environments and/or production
6. Not having a production-like environment to test in before production
7. Saving performance testing for the end of the release
8. Saving security testing for the end of the release
9. Never asking the users about the software
10. Only automating build and deployment, not testing
11. Not having retrospectives
12. Restricting retrospectives to only the development part of the process
13. Running analysis and never looking at or acting on the findings
14. Reduce coverage or static analysis gates to get a build to pass

We have all experienced a time where we wanted to believe we could make an anti-pattern work but it never does. It is better to learn how to spot these and how to correct them than it is to try to keep tweaking a broken process hoping this time it will be better.

You must be a Member to view this post and you are currently not logged in.