Residents of the software world know that new buzzwords seemingly appear out of nowhere, and just as suddenly proliferate news articles, water cooler banter and vendor FAQ sections. If you’ve heard the term DevOps being tossed around, you may think it’s just another hot topic that will succumb to time before long. However, this development method is taking everything from small development teams to large enterprises by storm and has only become more widely adopted since the term was coined in 2008 by Patrick Debois. So, what is DevOps, and how is it going to affect the future of development?
Get the Ultimate DevOps Primer
In this article, we cover a range of topics to provide you with a basic understanding of DevOps and how it works. Feel free to navigate to the section that most interests you:
Definitions and Comparisons
Before we can dive into the nuts and bolts of the many cultural changes brought on by adopting DevOps, we need an idea of what it is and how it works. As you can probably tell, the title itself is a merging of development and operations — there’s a reason for this:
Defined
Far more experienced experts than I have attempted to nail this topic down with an easily digestible definition, but doing so is a daunting task. Numerous moving parts go into this ideology, but it gets its roots from the Agile and Lean development styles and the Agile Manifesto.
The Agile methodology encapsulates the goal of quickly delivering applications and services while continuously innovating. At its most basic, the Agile method leverages a collaborative environment between development and QA that continuously improves, iterates, plans and tests through the entire lifecycle of a project.
Lean development got its start within the manufacturing industry and transformed from there into the world of software. The principles of Lean development rely heavily on eliminating waste (unnecessary features, task switching, etc.), delivering quickly, empowering teams and fostering an environment of learning. DevOps and Agile both share the Lean idea of improving both quality and delivery speed.
However, DevOps is differentiated from Agile and Lean development in a few areas. In many organizations, development and operations teams are siloed, work separately from one another, and rarely interact. This sort of isolation between groups working on the same project can lead to concerns and conflicts that slow down production. DevOps combines these teams (along with QA and security in some cases) and fosters a collaborative environment that puts the needs of the people and clients in focus.
Agile methods tend to focus on optimizing software development, while DevOps cuts out the difficulties operations teams face in this model by combining them with development.
Ultimately, the methodology combines cultural changes, best practices and suites of specialized tools focused on high-velocity application and service creation. Now, let’s take a peek under the hood to see how it actually functions.
Get the Ultimate DevOps Primer
Best Practices
Before jumping into the actual implementation of this new style of development, it’s important to recognize that DevOps relies on a foundation of cultural philosophies to achieve its goals. It focuses on a “People over Process over Tools” mindset, and making sure teams mesh and adopt the same workflows is where it all begins.
Culture
Adopting a new development strategy is tough, especially if that strategy calls for radically altering the culture of your business. To get the most out of DevOps, integrating some (if not all) of these cultural changes are necessary:
Collaboration
As you can probably guess, open lines of communication and collaborative teams are a key tenant of this strategy. One of the first and biggest cultural changes involves breaking down any walls between your development and operations teams. Doing this removes numerous problems from the development equation, including teams constantly playing the blame game when something goes wrong.
Sharing Responsibility
This takes collaboration to another level and makes every member of a project team responsible for aspects that go wrong, rather than blaming a specific individual or subgroup. Not only do dev and ops work together, but they also share workflows, tasks and information throughout the lifecycle of a project. When something is on everyone’s plate, it becomes impossible to write a problem off as “someone else’s job.” When a problem surfaces, it falls to the entire team to quickly solve it and move on.
Making Customer Needs the Primary Focus
While the needs of the customer are always critical, this methodology takes things to another level. Instead of worrying about the needs of your own business or stakeholders above all else, the development team focuses on making clients happy in a quick manner. As development goes forward, those who have adopted DevOps experiment and research throughout the process to present a final product tailored to their clients’ specific needs.
Automate, Automate, Automate
DevOps heavily leverages automation for good reason. Thinking back to this methodology’s Lean origins, cutting out waste of employee time and effort is a key step in moving forward quickly. Removing employees from tedious, time-intensive tasks and letting them focus on innovation and problem-solving means a stronger product when it comes time to deliver. However, keeping some manual testing tasks around isn’t a bad idea to ensure that any missed problems don’t make it through to your final product.
Embracing Failure
This may sound like the feel-good tagline of this week’s trending LinkedIn post, but in reality, it’s key to successful adoption. Failure doesn’t necessarily denote only negatives; it allows team members to take a feature back to the drawing board for more innovation. Failure should be used as a learning experience for everyone involved in the product. Placing the blame for mixups and coding failures on others only drives wedges between groups and fosters animosity. Failure belongs to the entire team, not one employee.
Get the Ultimate DevOps Primer
Autonomous Teams
Older development strategies like the Waterfall method place numerous restrictions on how teams operate and require constant approvals before the development process can move forward. DevOps lets teams prioritize tasks on their own and gives them the ability to take steps without waiting for permission to move down the chain of command. Resources aren’t continually moved in and out of teams for them to accomplish goals, so everyone can push on as the project requires.
As you can tell, adopting this strategy requires much more than picking up the latest trendy tools that you heard about around the water cooler. To get into the flow and really benefit from this method, executives need to be comfortable with some sweeping changes that can sometimes require a bit of proof to grease the wheels, but more on that later.
Execution
At this point, you’ve gotten your teams together and development and operations are ready to work collaboratively in peaceful harmony. Your employees are prepared to develop without constant approval from executives, tedious tasks have been automated and you’re in sync with the needs of the customer above all else. What now?
Now that you’ve mastered the cultural elements, let’s take a look at the practices that’ll make it all work.
Continuous Integration
This is another holdover from the Agile development strategy. It’s also a direct product of the collaborative nature of DevOps, as it requires developers to continually merge their code with the master branch. Normally, developers would slave over code for weeks or months at a time before merging it with the rest of the project. There are many problems with this older method, especially in regard to surface errors. If a developer doesn’t continually merge his or her code, there is a high likelihood of bugs being missed and then surfacing all at once. Continuous integration also makes delivery significantly easier by alleviating the need to release one final huge code dump that has to be corrected.
Continuous Delivery and Deployment
These two practices go hand-in-hand, as continuous deployment builds off of the idea of continuous delivery. Continuous integration deals with code being regularly integrated, while continuous delivery pursues the cultural adherence to automation and automatically deploys the new code into a testing environment. This way, new changes are quickly tested and prepared for release. To make this work, developers utilize a build artifact that’s deployment-ready at all times. That way, there’s no time spent getting a testing environment up to speed and things flow through the production line without resistance.
Continuous deployment continues this theme by building directly off of continuous delivery. It’s also often considered to be one of the most advanced practices of this method. Imagine continuous deployment as a kind of transcended nirvana that leverages constant deployment without human interaction throughout the production lifecycle.
Continuous Testing
As you can tell, constant progress is the name of the game in this methodology. Everything is done continuously throughout production, and testing is no different. Businesses leveraging the Waterfall development strategy would often see developers finishing their code and just handing it off to QA without a second thought. Here, however, everyone works as a team. This means that developers need to provide fresh testing data sets, and QA should be configuring automatic testing environments to continually work through the code that’s sent in. Automation is king, but when it comes to testing, it never hurts to keep some manual processes in place to ensure that nothing critical slips through the cracks.
Minimum Viable Product
Normally, a business would take a development project, work through it to the best of their ability, and then hand off a completed product with all the bells and whistles attached. On the surface, this sounds like a good idea, but there are several issues here. Keeping clients out of the development process limits creativity that could come from continually collaborating with them. There’s nothing worse than dragging your teams through a difficult development project only to have the client displeased with a final product they’re only now seeing.
DevOps takes a different path and boils the final idea down into a quickly deliverable core feature. Instead of spending months developing a full product, it gets a core deliverable into the hands of clients as soon as possible. It meets the client’s main needs and gives them a chance to see it in action, allowing them to collaborate with the development team. Once the core feature is in the hands of some users, who knows where it could go from there? The development team could discover an innovative way to tackle a new problem, or even conceptualize an idea for an add-on they would never have thought of otherwise!
These aren’t the only practices that make things run smoothly, but they are a good representation of what to expect. There’s a fair amount of variation in actual practices and methodology depending on how your company operates and how it chooses to adopt this strategy.
Now that we have an understanding of how this strategy works, what sort of benefits can you expect by adopting it?
Strategic Benefits
DevOps is much more than your typical flash in the pan, and some serious benefits go hand-in-hand with adopting it:
- Better Collaboration: Breaking down the walls between your teams fosters an open environment of communication and accountability. Let your teams share responsibility and workflows to not only produce faster but also innovate throughout the project.
- Increased Speed: Leveraging continuous integration and delivery lets teams utilizing this method to produce faster than ever before. Autonomous teams can push forward quickly without waiting through time-consuming approval processes.
- Scalability: Numerous points of automation help teams deal with changing complexity without sacrificing speed and resources.
- Deliver Faster: As one of the core philosophies of the strategy, delivery velocity is critical. Surface errors quickly, push out minimally viable products and continuously integrate to maintain a quick delivery pace.
- Improved Reliability: With continuous testing, both automated and manual, final products are reliably error-free. Constant code integrations keep problems to a minimum and give the team time to handle any issues that appear.
Even with the numerous benefits it provides, there are still some incorrect opinions about what adopting this strategy brings.
Misconceptions
One common misconception is that adopting this type of strategy puts developers above all else and takes operations out of the equation. DevOps isn’t here to run anyone out of a job or cause developers to completely take over operations. Sure, automation is critical and does take over a good chunk of operations, but this isn’t necessarily a bad thing. Operations members in a DevOps environment not only develop valuable critical development skills but are also freed up to tackle essential high-level tasks that could benefit from more devoted time and energy.
Another false pretense is that DevOps is simply a collection of tools. Sure, there are numerous specialized toolsets that can go into helping function, such as Kanban, Scrum, RedHat OpenShift, Slack and more. Tools help, but they aren’t the core of the strategy. Like we said earlier, it puts people first with its people-above-process-above-tools approach.
DevOps also isn’t only about development and operations coming together. It includes everyone who’s necessary to continually develop top tier products. QA and security teams are looped into the project as well because they are a critical part of the strategy.
Like any other methodology, DevOps depends on the people involved. It can’t solve every problem your company encounters by itself and requires sweeping cultural changes from within to be fully realized.
Get the Ultimate DevOps Primer
Next Steps
Interested in implementing DevOps methodology, but aren’t sure how to take the leap? First of all, start small. There’s bound to be some skepticism from members of the executive team, but beginning with a small group is a good way to prove the value of this development strategy. Have a small group of employees adopt it, push out a minimally viable product, and then analyze how things went. The proof should be in the pudding, and after the executive team sees how things work, you can head toward a large scale adoption of DevOps methodology.
Regardless of how jarring the cultural changes brought on by this strategy are, it’s hard to ignore the benefits. Take the leap, let a small team take up the flag, and see just how valuable the switch can be.
What do you think the greatest benefit of utilizing DevOps methodology is? Sound off in the comments below!