“Building a DevOps Culture” by Mandi Walls
This is a really short read. Here are some quoted notes:
- “A DevOps culture is one created through lots of discussion and debate.”
- “A team taking a more DevOps approach talks about the product throughout its lifecycle, discussing requirements, features, schedules, resources, and whatever else might come up.”
- On the topic of on-call: “The people who are empowered to directly make an improvement are the ones who are alerted to the defect”
- “The team is rewarded when the product is awesome, and shares in the improvement process when the product could be more awesome”
- “Trust is a massive component of achieving a DevOps culture. Operations must trust that Development is doing what they are because it’s the best plan for the success of the product. Development must trust that QA isn’t really just there to sabotage their successes. The Product Manager trusts that Operations is going to give objective feedback and metrics after the next deployment. If any one part of the team doesn’t trust another part of the team, your tools won’t matter. Additionally, if you don’t trust the people who work for you, why are they working there? Why are you”
- “The one question you must ask is “What is our primary business goal.”
- “In an ideal situation, you’ll have some sort of consensus. Even if you have two related goals you’re doing mostly OK. The comedy of errors starts when you have several divergent ideas of what the company is actually trying to accomplish. The reasons for this often include poor communication from management as to what the company is driving toward. It’s also possible that fuzzy goals like ‘serving the customer in the best way possible’ are different for different teams in your organization, especially if they have different ‘customers'”
- “Articulating upfront what your goals are will help you with other phases of your DevOps roll out”
- “Your new DevOps-style standup meeting includes everyone. Your developers, your QA engineers, your system administrators, all of them get together to discuss what they’re working on.”
- “When everyone knows up front what new features are in the pipeline, it will be less likely for any of these topics to be missed. This makes your product more reliable and gives your customers a better experience.”
- “If your team is not permanently collocated, bring them together for as long as you can at the beginning of the project.”
- “every bump, burp, or error in the code would report back to the person who wrote that code and is most likely to understand what is wrong in order to start the process of fixing it”
- “engage the people who are fighting in a constructive discussion, work through the sticking points, and mediate a compromise if one is warranted”
Dave's Blogs 