DevOps Day 1: You’ve Committed Your Team to DevOps. How Do You Start?
You’ve looked at DevOps. Maybe you’ve worked in a DevOps environment in a previous job or situation, and love the way it brings people together to create great software, faster.
You understand that the leading web-scale businesses and developers, Google, Etsy, Amazon, all practice DevOps to continue to grow and stay at the head of the pack.
Now you’d like to implement DevOps for your team. How do you get started?
DevOps Champion
“We recommend that your organization should have a DevOps Champion in management, someone in leadership who understands and supports DevOps,” said Brandon Cipes, vice president for DevOps practice at Cprime.
“DevOps is primarily a culture, a culture of collaboration and sharing insight into each other’s work. Cultural change is driven by leadership, from the top, and must be maintained by management so it doesn’t evaporate.
“This is especially important for starting a DevOps practice, because it means drawing together two separate groups, Dev and Ops. Developers and IT Ops people are usually on separate tracks, and may never even talk to each other.”
Find a champion, or become the champion internally. Then start educating your team on DevOps and cultural change. cPrime provides training and strategic consultation to help guide you through this area, making the right decisions for your circumstances. cPrime’s DevOps Strategy Sessions are free of charge.
DevOps can be difficult to define because each team is different: what works at one company might not be a good fit for yours. But DevOps is not about a rulebook or a model, it’s about your goals, and how to reach them faster and more efficiently.
“Some organizations start the DevOps journey by looking at tools they might potentially use,” said Cipes. “Time enough for tools later. More important is the practice, the culture, the mentality of DevOps – of constant collaboration, of visibility, of sharing, building bridges, breaking down silo walls. If you’re not breaking down walls, it’s not DevOps.”
Start Small
cPrime recommends that a new DevOps team starts small. Put together a small team on a single project. Work together with a high level of autonomy, which is easier at first with a smaller project. A certain degree of independence is critical to the functioning of a DevOps team, and is part of the definition of DevOps. A DevOps team creates software and post updates at a fast pace, quickly and routinely, without constantly needing approval from a manager.
Self-empowerment is critical. This is not common sense, but a learning from years of experience and training. The effective and productive DevOps team is a self-empowered team, that can try new ideas and experiment wildly and creatively. The team can iterate on its own without needing constant, incremental approval of managers.
Some DevOps teams might start with a strategic project, something big and important to their company, to truly test the DevOps process. You’ll have to decide which is the best approach for your group. This is an area where cPrime’s DevOps Strategy Sessions can help you make a decision that leads to a DevOps win.
Measure everything
Now you can think about tools, and automate testing of your iterations. Build in test automation from the start. Take the time to start right, and you’ll stay ahead if code needs to be rewritten or patched.
Start early! Don’t wait until it’s too late – build-in automation when your start and test your scripts, immediately. Then your team can scale as your business takes off. Take the time necessary to be scalable before you start. Test, and understand where you are now and where you’re headed right from the beginning.
If you’re new, some of the things to keep track of immediately are:
- Frequency of deployments
- Frequency of failed deployments
- Mean time to recovery (MTTR)
- Mean time to discovery (MTTD)
- Lead time
- Up time
- Customer complaint volume
- Service performance
Automate everything – use analytics to correct issues. Save manual management for high-level, strategic issues that demand conscious decision-making. Let automation take care of the rest.
You can also evaluate and test your process as well as the software you’re producing. How can it work better? Where can it be improved? What part of it can you dispose with?
Good luck with Day 1!