Recently, I was helping a client setup log management. While talking to the internal team, I found myself frequently arguing that you have to make the setup easy, otherwise it will not get done. As I found myself repeating this statement, I realized I was cutting right to what is needed to create a working DevOps solution.
DevOps is not about the setup of tools. It is about understanding the needs of customers and figuring out the solution for them, whether they realize it or not.
At Flux7, we repeatedly see how DevOps is a human problem as we move towards perfecting our developer workflow solutions that we’ve designed for multiple clients. We realize more and more that as much as the problem is about understanding the customers’ needs, even the ones they don’t realize they have, it is about understanding and allaying their fears and resistance to change.
Thus, the focus is on making our processes simple and straightforward to encourage use.
Easing the use of our solutions starts with the first step of developer onboarding. We want the onboarding process to be as painless as possible. This first step makes it extremely easy for initial adoption. The client team needs to check out one VM with their complete replicated local dev environment and find themselves hitting the ground running with the scripts for developing a Docker-based development environment. It also helps with bringing in new employees. Usually, this process involves many steps of permissions for various repositories and assets. This helps the employees get up and running faster.
After ramp up, we make sure not to affect the developers code editing experience. Developers already invest very heavily into mastering their text editors, learning shortcuts, and developing a flow that works for them. We don’t believe in interfering with the processes that work.
We do, however, set up multi-tiered, continuous integration. Having a basic set of smoke tests is necessary for a large software project. But, for smaller organizations, the initial overhead in setting up these suites is too cumbersome, and this part of the process gets delayed. To build up the test suites, you need to make the process of adding in new tests simple. The setup also needs to be multi-tiered because we want to maintain the quick feedback for the most important tests. Not having this feedback immediately results in developers waiting to run tests on aggregate commits rather than individual commits. It also increases the size of commits to be more monolithic, and harder to revert and understand. While in the short term there may not be a penalty, you pay for these actions in the long run when a catastrophic event occurs.
Many of you would argue that these problems can be solved with a little bit of discipline. My argument to that is the discipline comes at a cost of mental energy. Read this here to better understand my position. And wherever possible, we need to conserve energy so the developers can focus their discipline on what is important.
Developing working software is a hard enterprise with many moving parts and unknown interactions. We should not make it harder than it needs to be.