One of the most common threads I see when discussing devops with an enterprise is how quickly people forget that it’s supposed to make their lives easier. People may have picked up a book like The Phoenix Project and understood that automation is good. Perhaps engineers also get that businesses need to adapt quickly. What they forget is that devops is supposed to make their jobs easier and less stressful in the long run.
I think the reason for this is the transition from a traditional model to one where devops is implemented and thriving. It can be a tough transition, especially for teams in a larger organization that may not be ready for such changes. The trick is to make sure the high stress of transition time doesn’t become the norm.
Let's take a look at some of the tools available to a devops team in the enterprise. One big one is the container. Docker containers provide a great deal of flexibility to developers and operations teams. A fully automated deployment might be one where the developer pushes code, it gets tested, and put into production all in one action. In this scenario the operations team acts as a maintainer of process but has no say, outside of the automated tests when things go to production.
These tests would typically be done with a CI like Jenkins or perhaps a home-brew system. The changes would kick off as a trigger from a code commit or perhaps a timed event. Changes are approved or denied based solely on the code commit and the tests.
Some enterprises are uncomfortable with this. Especially since if a dev pushes the code to production at 5:00 pm on a Friday, things that go wrong over the weekend might not get noticed. This is where the process is important. Devops doesn’t mean there is no ops team. In most enterprises there still remains a fairly strong separation of the reporting chain for the operations and development teams. Instead, what it means for an enterprise is more collaboration and trust between those teams. One of the best ways for that trust to flourish is through accountability.
In the earlier example, the developer mentioned might push a release on a Friday afternoon that broke things. He should probably be in the on-call rotation if he’s going to do that and he has to be available for it. It’s a simple rule change. Going to push code to production? You need to be on-call and accountable for it. It might make everyone think harder if the change really needs to go to production on a Friday afternoon.
There’s more accountability to go around. Not only does the problem need to be fixed, tests need to be updated to ensure it doesn’t happen again. Kaizen, the art of continuous improvement, is critical and everyone’s responsibility. Tests should be added and owned by all teams involved including the security teams, quality teams, operations teams, dev teams, etc. Every one of those teams should be trying to automate themselves out of a job. They’ll never get there, but having worked in environments where continuous integration went from nothing, to something, after about the 6 month point people really start to change the way they think and act.
For teams wanting to go the full devops route, OpenShift-v3 provides all of the tools required. There are integrated build features, deployment, and team features. Devs can go straight to prod. Some enterprises may still want to put manual pieces in place. For them we have Red Hat Enterprise Linux Atomic Hosts. A great blending of container and operating system technology that gives enterprises the ability to implement their own solutions.
Configuration management places an important role here too with technologies like puppet and satellite getting better integration. Understanding how these techniques can drive policy changes is a complicated but important step to utilizing a devops mode. For customers wanting to know more, come see my session at the Red Hat Summit titled “Applied DevOps: Tools & techniques to change your enterprise.” It’s currently scheduled on Wednesday, June 24th starting at 3:40 in room 200, and is also available for DevNation attendees, too. I’ll be covering this topic in greater detail and will answer any questions you might have. Hope to see you there.
Last updated: August 31, 2016