When I began research for this post, I was unprepared for the amount of passionate, baffling, over-the-top definitions, descriptions, and workflows concerning what makes DevOps, DevOps. I read blogs of general definitions, witnessed Twitter arguments for and against the implementation of DevOps, read the oft-touted The Pheonix Project and learned that love it or hate it, DevOps carries a lot of baggage in many IT communities.
But at its very essence, the core of DevOps philosophy is this: Creating a work environment where dev, operations, and QA can not just exist in harmony but thrive, allowing projects to flow down a work pipeline until hitting the consumer promptly and without (or with minimum) issue.
For many, this sounds like a goal that’s often mired in project management and confusing tools and terms — a reality that can bring any DevOps dream hitting the ground of harsh reality before ever getting to real results. DevOps needs an initial time commitment, wherein the requirements and expectations of all teams are considered, and a workflow is created with concern for the whole. The Phoenix Project compares this to working at a factory — reviewing where projects hang up, and creating systems, so everything works as part of a well-oiled machine. And while IT workers may not want to compare their job to something like standing in a factory line, it’s a valuable comparison. While developing and operations may, at times, seem like solitary work, the project is always bigger: It’s not just the code that’s written or the platform it’s on; it’s not the people checking for bugs or even the end users. It’s all of it — and DevOps forces things to be considered as a whole, and employees can plan their work so deadlines and release dates can be hit with accuracy and greater reliability.
DevOps is often conflated with the tools and processes closely associated with it. These are version control programs, testing tools, infrastructure management solutions, project management methodologies, and more. But it’s important to remember that one set of instruments may enhance one company’s DevOps culture while suffocating another. The goal is not just to use the tools touted by DevOps professionals, but to make an active change in company culture that makes the flow of work, work better. While this often goes hand-in-hand with tools like Jenkins (continuous integration), Salt (infrastructure management) or Vagrant (virtualization), it is never a one-size-fits-all scenario.
Those new to tech or newly enchanted with all the connotations and possibilities DevOps can often become dragged down with all that it seems to entail. But the primary goal of DevOps isn’t to remove operations, disempower employees or micro-manage projects — all fears often associated with trying to make a culture shift in a company. It’s to find a harmony in a pipeline that works. It’s finding processes that allow a company to succeed. It’s a combination of culture and actions that improve the workflow across IT teams. It’s finding what works for your workplace, and nurturing it into something better.
DevOps isn’t without its toolchain, however, and next week on the Linux Academy blog, we’ll step into DevOps once more by defining common tool types used to enhance workflow.