First, let’s establish this fact: DevOps is a movement. Scan through any current software magazines or websites and you may come to this conclusion: DevOps is the most important subject in IT today. A movement that began to take shape around six years ago still manages to create a huge buzz around the IT industry.
Most people involved in IT may be able to describe the general framework of DevOps, but lack a concrete understanding of the When, What, Why, and How of DevOps. DevOps is, always has been, and always will be a movement. This gives us, an idea what DevOps isn’t: it is not a product, it’s not a job title, and it is nothing you can point to. It is not even a goal.
What is DevOps?
So, what is DevOps? DevOps is a cultural movement that takes place between Dev and Ops.
- The term Ops embraces all people that operate, monitor, and scale technologies and services. It includes a myriad of job titles such as systems engineers, system administrators, DBAs, network engineers, release engineers and various other sub-disciplines.
- On the other side of the coin, the term Dev, encompasses everybody that is involved in the development of a product. It includes developers, testers, business analysts, product managers, product owners and, again, a truly long “et cetera”.
Together, DevOps literally means development and operations. The term stresses the union of the disciplines. This statement declares that DevOps is a cultural movement that takes place between Dev and Ops.
What Gave Rise to the DevOps Movement?
DevOps aims to form a friction-less cross-team collaboration between two groups. It is intended to enable a willingness on both sides to change current processes. DevOps is about the collaboration of people and convergence of processes that together aim to enable continuous delivery (as an example among many others).
DevOps is seen as the Holy Grail of tech. DevOps, however, is not continuous delivery as many might think. Rather, it promotes a bridge between Dev and Ops in order to lay the foundation for continuous delivery. You could say that DevOps clears the way for continuous delivery. DevOps is expected to revolutionize the way technology is done on a cultural level in all of our organizations.
DevOps co-founder Patrick Debois puts it this way:
“Where we are right now just sucks.”
While that may be true, that leaves vast room for interpretation. So, what exactly sucks and drives the DevOps movement to keep growing ever faster and ever louder?
First, let’s remember that the DevOps movement was started as an observation. The observation was that the unspoken expectations in software development projects manifested themselves as bad habits – really bad habits. It was, and still is, habit to assume that a project will run late, and when the product is delivered, (if it is delivered at all), to assume that it will fall short of expectations. It is simply expected to under-perform.
Secondly, DevOps is about breaking these bad habits. A deep fear of change usually emerges in traditional development projects, which further exacerbates the problem when it comes to critical decisions, such as risky deployments. What is even worse is that the root cause has a name:
By dividing an IT organization, a network of splits emerge. Although this doesn’t sound bad initially, call to mind that these divisions have countless inter-dependencies, making it practically impossible to coordinate all their collaborations. That is what DevOps reminds us of quite clearly. It reminds us that breaking teams apart due to the division of labor creates separated silos such as Dev and Ops – or rather, each of their sub disciplines.
From a process point of view, this seems to be irresponsible, as the silos create innumerable walls of confusion. Each of these walls interrupt the flow of the development pipeline from deployment to stakeholder feedback at numerous distinctive points. Each of these walls becomes a critical barrier to effective teamwork, preventing communication around a common goal.
How Does DevOps Help?
DevOps seems to provide the right answer, by suggesting how to implement the right culture. Above all, it is worth noting that DevOps suggests an approach – it is not inventing an approach.
DevOps reminds us that a culture is a group of people with a common set of shared:
In rough terms it goes like this:
- First, determine your core values and let Dev and Ops, as well as all your stakeholders, know about them.
- Secondly, create clear and comprehensible goals which meet your business objectives and are consistent with your values. Start with the “why” in everything you do. Only then, and not before, move to the how.
- Thirdly, establish practices that let the processes of Dev and Ops converge and move straight towards your goals. (More on that in a moment.)
- Lastly, don’t forget to test all these against the attitudes of your Dev and Ops teams.
Implementing such a culture is a big challenge, but maintaining it is even more difficult. DevOps reminds us that we need to listen constantly and carefully to these attitudes in order to determine which values are not being embraced and which may need to be changed.
Never forget for whom you are building your product! DevOps further reminds us not to panic when goals need to be re-examined and practices need to be adjusted in order to continuously move forward. Taking actions like that is what motivates Dev and Ops to collaborate.
What lets the processes of Dev and Ops converge? At its root, it’s all about efficiency and effectiveness. It’s about focusing on the right things in the first place, so you don’t simply become more efficient at tasks that don’t really matter. It’s about pairing modern Lean and Agile concepts with good old-fashioned management principles such as systems thinking, systems dynamics and the theory of constraints, among many others. DevOps is an ensemble of concepts that, while not all new, are catalyzed into a movement.
Well, cultural change for the fun of cultural change makes no sense. DevOps gets into the game whenever cultural change is required to help you meet your business objectives. But, when is the right time to change? Always! Never stop changing! It’s a continuous change. Why, you may ask?
You always want to be the most innovative player in the market and the leader in quality of customer service, increasing market share and your customer database. So adapt, then adapt again, and see your company reap the benefits of a DevOps culture.
Agile Defined For Software Testers
Learn what the Agile development methodology involves and how it impacts software testers. Read more.
Tricentis Tosca: Testing The Missing Piece In DevOps
DevOps in combination with Continuous Delivery (CD) has been gaining traction over the past few years. It ensures teams are focused on actual problems. Read more.
DevOps / ALM Tool Integrations
Integrate with your DevOps/ ALM tools for CI testing and synchronization of requirements/user stories, defects/issues & test results across your toolchain. Read more.
Continuous Testing For Agile And DevOps: 5 Key Takeaways From Gartner
How can you overcome the challenges of Continuous Testing? And what testing best practices are critical for achieving Agile & DevOps objectives? Read more.
Stop Wasting The Efficiency Potential Of Test Automation And DevOps
Everyone knows the dual productivity powers of automated testing and DevOps practices are essential for driving large-scale software delivery in high performing teams. Why aren’t we using them? Read more.
New Gartner Magic Quadrant For Software Test Automation: Tricentis Named A Leader
Tricentis was named a leader in the new Gartner Magic Quadrant for Test Automation for the 3rd year in a row—with the highest position in Completeness of Vision. Read more.