Where Do You Start When It Comes to DevOps?
DevOps can be a loaded term. Sometimes, you’re just referring to the agile relationship between development and operations. Other people, when discussing it at a conference or in meetings, point toward more frequent releases, to the rate of hundreds of times per day or even per hour.
Sherry Chang, chief architect for Intel IT's DevOps initiative, gave a smart, succinct definition for DevOps in a recent interview with StickyMinds.
“DevOps is about transformatively improving IT organization performance by enhancing collaboration between traditional development and operations silos and by employing better engineering practices such as test-driven development, continuous integration, and continuous delivery,” she explained.
The desired benefits are clear, even if the definition is often lost among the noise—people want better performing IT organizations more able to achieve speed and stability concurrently. If you can institute a new idea into your company or team and see faster releases, more communication, better structure, and overall better quality, why wouldn’t you immediately go all in on DevOps?
Like agile and waterfall before it, shifting your mindset or adjusting how things are done is never as easy as snapping your fingers and watching your software teams fall perfectly in line. So, here’s the big question: If you want all these benefits, where do you start?
Chang has been preaching the good word of DevOps for quite some time, and she understands why some teams might be hesitant to go forward with it. However, she clearly outlined what she feels to be the best blueprint to get started.
“I suggest starting out with continuous integration. The reason I like CI is because you have an automated system that helps reinforce the right behavior,” she said. “I suggest starting out with build automation and at least one test validating success of build. Keeping the build green for a few weeks with minimal criteria should get the feet wet and instill confidence. After that, they can layer in TDD, more automation and refinement of their automated path to production pipeline.”
Again, it might not be easy within your situation, but know that the bigger risk when it comes to DevOps is refusing to adapt. In software, things change in the blink of an eye, and if you’re not optimizing your releases, processes, and quality, you’ll be quickly left behind.
