So you’ve seen some success with agile software development, and you want to continue making releases frequently (all while maintaining a relentless adherence to strict quality standards).
If you’re in the space, you probably know that this is easier said than done.
The good news? Adopting DevOps practices, which create efficiencies through automation, collaboration, and continuous monitoring, can decrease your time to market while subsequently decreasing the level of risk involved with each release.
Although creating cultural change sounds like an enormous, complicated task, it is possible to spearhead this change, and it is possible to gain the necessary buy-in from the rest of your team members.
Here are 10 things we’ve learned while implementing DevOps at Mindgrub that should be considered when implementing DevOps at your organization:
1. Understand your needs
Get feedback (and support) from everyone involved - including the non-technical people. A large component of DevOps culture is aligning your engineering practices with business goals, and without buy-in from operations team members, developers, and testers, DevOps simply won’t succeed.
2. Evaluate tooling
Does your existing tooling support what you are seeking to accomplish? Do you need to find new tools or partner with someone who has experience with the tools you need to help your team?
3. Implement automation
If they do something once, do they document it so they have it if they need to do it again? If not, start building these practices into your normal workflows, and be sure to explain how they fit into the bigger picture.
4. Store all configuration in a version control system
Eventually, DevOps will include automation and you don’t want people making changes that get blown away when your automation tries to apply other changes.
5. In addition to your version control system full of scripts, identify a non-technical resource hub
The version control system is great for storing configuration scripts the technical team uses and for tracking changes made to them. However, storing non-technical information (such as resource “playbooks”) in them means that the non-technical people who buy into your DevOps culture won’t easily be able to access them.
Consider an alternative wiki to hold the non-technical playbooks so everyone in the organization can access them.
6. Test, test, test
Have an environment to test your DevOps scripts, and make sure your DevOps scripts account for automated testing. Without automated testing, you can’t move to automating all things DevOps.
7. Consider how security fits into your DevOps model
If you have a security team, have they bought into this? Executed well, automation will make processes and releases more predictable, efficient, and secure.
Keeping anyone focused on security involved from the beginning will ensure that monitoring for security changes becomes a part of your ongoing process.
8. You don’t need to be a DevOps Engineer to start a DevOps revolution
Often, it can be launched by a Developer or an Operations person who just wants to make things better.
9. Be prepared for failure
Before implementing any DevOps practices, decide how you are going to deal with failure. Things will break. How you recover and how you learn from your mistakes will be critical.
How will you create a sense of accountability without blame? How will you document past failures and prevent future ones? What do you consider non-negotiable risks? These are all things that should be agreed upon ahead of your DevOps implementation.
10. Start small, but do something
The best way to get started is to stop talking about it and start doing it. That being said, don’t try and do everything all at once.
Set a manageable goal that can be accomplished in a week, and then do whatever it takes to accomplish that goal. Seeing the success of a quick win will encourage you to keep going.
