Introducing DevOps to Your Organization
Your organization struggles with manual activities around provisioning and configuring servers –updates aren’t applied consistently, changes are time consuming, and software is running on many different platforms which require special attention. There are costly mistakes being made in the form of outages and defects. Code behaves differently on development machines when compared to production. You’ve heard about “DevOps” and related concepts, but you’re unsure about how it will fit in your organization, or how you’ll preserve the separation of responsibilities that exists today. Maybe you’re not sure if “DevOps” is what you need. In this first of three posts related to DevOps, I’ll discuss the concept and its goal.
What is DevOps?
DevOps is a term used to refer to a collection of concepts and best practices based around how operations engineers and software developers efficiently work together during a software development lifecycle typically used in agile development environments. DevOps practices borrow from those common in the application development space – treating configuration as code that can be version controlled, automating repetitive tasks, and integrating into Continuous Integration/Delivery processes. In addition, this agile approach to traditional operations activities allows teams to increase frequency of deployments, shorten the amount of time required to deploy, and eliminate inconsistencies between environments.
The Goal
Like many efforts, after a problem is identified, a solution is required. However, before a solution can be chosen, we need to identify our goals. It is important to determine an appropriate, achievable, and justifiable DevOps goal, tailored for your organization.
From a DevOps perspective, in an ideal world, an organization would be comprised of teams of developers and engineers working together throughout the development lifecycle, continuously delivering well-tested and production-ready code to servers provisioned and configured with the click of a button.
Depending on your current environment, full-blown DevOps may not be exactly what you need to fix the items your organization is struggling with. A business constraint might exist that prevents you from continuously delivering software to production multiple times per day, or maybe for the time being operations engineers don’t fall under the same management as application developers and the idea of them working ‘side by side’ isn’t easily doable. Maybe all that’s required is automating some configuration management activities and increasing visibility into what changes are applied and when. It’s perfectly valid to adopt a subset of DevOps practices.
In my next blog post on DevOps, I will explore how a DevOps solution can be broken into two components: practices and tools.
