For many of you, this may seem an easy question. “Of course dude, my team eat, sleep, and breathe DevOps.” This may be the case for your organization. Still, an interesting trend I’ve seen over the last years is that DevOps means different things for different people and companies, and many feel they are “done” with their implementation. I believe this isn’t accurate, as the practice itself aims for continuous improvement. Continuous as in never-ending, I would imagine.
I consider that implementing a DevOps culture is a learning and maturity process. You start crawling, then walking, and so on. But, as in life, there’s not a single dimension. Not because you already can run, you’ll stop improving in other areas in your life, right? Even when you reach a mature state, you can continue improving.
Even though many think they are in “good shape,” the reality is that many companies don’t follow the core principles. Some people haven’t even heard about them. Please, don’t roll your eyes at me when I say “principles.” I’m not saying this in a dogmatic sense; my goal is not to lecture you. But I believe that DevOps, as a philosophy, lays the ground on what you will be doing. It’s the actions your team does that matter. Else, you can print and hang working manifests or even buy trendy tools but not achieve the benefits you would expect. In that sense, I’ve seen common patterns resulting from this disconnect over the last years.
Common DevOps Implementation Pitfalls
CI for people that don’t integrate continuously
The team has implemented a CI process, where each commit’s changes are automatically built, tested, and so on. But the developers usually push changes once a week. The real value of the CI gets diluted.
Betting on the tools to transform your team
I think of tools as a means to ease processes. But often, we believe it is the other way around, and consider that by buying a product that promises some benefits, we’re good. While this may be true, the team is often not ready to reap the benefits yet. Tools aren’t magic.
Forget about software architecture.
Applications need to be designed in a way that can benefit from the practices you want to implement. Suppose you want to automate multiple types of testing. In that case, the software architect should consider in their design some ways to handle testing data, allow for service virtualization, and other things that make the testing process more effective.
The same goes for the deployments. If you aim for a fast release cadence, then the application needs to be designed so that the deployment is separated from the release.
For this to happen, the architect needs to get in touch with the whole team early in the process, including QA, Dev, Marketing, to know what needs to be considered when designing the application.
Disconnect in release goals.
You ask to have continuous delivery and deployment, but your business team isn’t interested in updating the application every day. The opposite is also true. Your product team aims for faster releases, but the team isn’t ready or confident; hence, their development practices hinder achieving this goal. You continue to live by the adage of “not deploying on Fridays,” which shows that you just don’t have confidence in your process.
Think of quality as “unit” or “functional” tests only
Part of the process is ensuring the application gets better quality. We need to think beyond manual or unit testing and consider what other quality gates need to be part of my process. Do I care about security? Maybe a vulnerability scan is required. Is my business subject to sudden spikes in demand or seasonality? You may want to ensure the application is ready before it crashes during peak time.
Bet on pipelines as the silver bullet
I’ve heard many times that DevOps is a matter of building pipelines. As if once you create them, you are in good shape. However, the reality is that they are only a part of the process and become worthless if the rest of the steps are broken, undefined, or unreliable.
Automate everything!
Automation is valuable when it reduces the burden of manual, error-prone tasks. But, if you currently have a mess, automating will most likely make this mess faster and even more chaotic. Of course, you don’t need to have everything well defined to start automating. However, it is essential to begin defining the processes to be followed and identifying where automation will make more sense.
Done != providing value
No pill will cure your headache while still on the counter. Similarly, the whole point of software is providing value to the users; they want working software. Teams need to remember that this is the goal, not just closing tasks. “Done” means that users can work with it, not that “my part of the process is done,” regardless if that part is testing, development, or any other step in the lifecycle.
Consider that adding DevOps engineers is the solution.
This one is tricky. In DevOps Topologies, Matthew Skelton and Manuel Pais describe having a DevOps engineer as one of the potential pattern configurations. They call it “Ops as Infrastructure-as-a-Service,” and recommend specific conditions for implementing it, meaning that it’s not a one-size-fits-all topology. Skelton and Pais also describe this problem, identified in their approach as the “DevOps Team Silo.”
Improving the success odds
Of course, none of these are fatal sins, nor is this a pointing fingers exercise. My point here is to illustrate what I’ve seen happening so you can identify it in your organization and maybe prevent it from becoming a hurdle.
“How can I do it?” you may ask. Well, there is no simple answer. The type of changes you may need to make will depend on multiple things. Things like your goals, team composition, and experience, and some other variables will most likely influence the process you require.
Nonetheless, here are some practices that I’ve applied with several teams with good results. They may help make the process easier for you.
Determine your goals.
What is the reason behind “devopsify” your organization or team? The things you will want to achieve will influence the activities and tools you will require to get there.
For example, a large financial company I was collaborating with last year wanted to have all their teams deliver features faster. Another company may want to reduce the disconnect between their system administrators and the development teams, causing conflicts and rework. Everyone’s context is different.
Set clear expectations from day one
Communicate clearly with your team on what are the goals your organization has from this process and what you expect from them. Evangelize, don’t impose. Someone may have a good reason for being against the change. Listen to them, but also convince them to try new ways.
A practice that I’ve found useful is, when the project starts, share with the team the methods, patterns, and principles we will be following, so we can all be on the same page. Of course, the first days will be maybe hard and confusing. Remember, it is a process. It is essential to go back to the agreements, determine what works and what doesn’t, and adjust accordingly.
Start small
It’s tempting to transform everything, especially when you start looking at things through a different lens. But the reality is that a big bang most likely won’t work for your team. You may find change resistance, confusion, and many other things that will hinder your transformation. Instead, start small. Make quick wins.
In the financial company I mentioned above, the strategy was to start first with the newer applications that a small team was building to get their toes in the water and see if it was for them.
This approach can also help you and your team build confidence and evolve more organically.
Aim for a Minimum Viable Process
There are many things in the software development lifecycle that can improve through DevOps practices. But it would be best if you didn’t try doing it all at once.
Define your current pain points and goals, and then start defining the minimum process you want to start getting benefits. It may be something like implementing Continuous Integration, which sounds simple, but it may be hard to change for some people. Then you can evolve and proceed with automated deployments. After that, you can start adding quality gates like automated testing. A phased approach may help your team to understand the practice better and gain confidence about it.
Think toolchain, not individual tools
Every tool you select needs to fit in the big picture. DevOps practices aim for a continuous flow of work and information, so each tool needs to allow for this, like a pipe allowing water to flow. You may start with some custom-built tools or scripts, then move on to some off-the-shelf product or service. Additionally, consider that no tool is eternal; you may need to change it at some point. Thinking on toolchain terms will help you make this transition smoother.
Don’t forget DevOps is also a learning process.
Try processes and tools without thinking they will always be the best option. Be open to change. Allow for experimentation, and continually evaluate how things are going with your team. Consider that “the cloud” can be a strategic partner because you can quickly test a concept or process without spending a lot of money or time on the infrastructure to support it.
And please remember, DevOps is not a mark to be checked.
Originally posted in LinkedIn