DevOps refers to a set of practices combining the development of software (Dev) and operations in information technology (Ops) with the goal of shortening the development lifecycle, implementing continuous delivery and developing high quality software.
With DevOps, processes are usually automated in the work pipeline between programmers / software developers and other members of the IT team so there is a continuous flow from building, through testing to software deployments, all with the aim of achieving faster, high-quality releases. With DevOps, teams collaborate more instead of functioning in silos, which increases trust between teams, making problem solving easier.
DevOps as a Culture and Philosophy
DevOps is meant to create a mindset of collaboration between development and operations so there is a closer-knit integration. It’s like a fusion of Agile, development, automation, continuous delivery, etc, so that programmers in the development team and team members in Operations work more collaboratively to deliver increased value that benefit stakeholders.
DevOps History
DevOps started as an offshoot of events called DevOpsDays. The first DevOpsDays conference took place in Ghent, Belgium in 2009. Patrick Dubois, a project manager and agile practitioner, set up this conference. It was quite a success, with presentations made by different speakers on IT-related work processes. It also was well-received, with reactions coming from many quarters in the IT industry. Since then, DevOpsDays has evolved into being hosted in different cities across the globe.
The Benefits of DevOps – What Teams Can Get out of It
A Collaborative Mindset
DevOps helps create a culture of collaboration and trust between teams. Team members adopt a sense of common goals and shared responsibility. Word done become more transparent and getting feedback becomes quicker.
Teams that operate as silos sometimes fail to see the big picture of what the overall project goal is. In really bad cases, teams may get over-protective of work processes or deliverables they think they should control or even defensive when information or explanation is requested by other teams. Other teams become competitors or adversaries. This type of silo mind-set is what DevOps helps eliminate by making team members see their contribution as part of the chain, or process. Team members get to see how their contributions impact the process and other teams, beyond their own immediate team.
Faster Releases, Smarter Work
DevOps adoption helps speed up releases. Faster releases mean more frequent releases, which means that applications become available quicker for meeting the needs of business.
For companies not using DevOps, creating newer code or updating existing codebase requires the operation team to set up separated chains of activities and processes, Â each of which delays response time. For example, without automated tests, the setting up of testing environments, with releases occurring only after testing is completed, takes a chunk of time, often leading to delays.
Quicker Issues Resolution
DevOps encourages transparency and, therefore, faster feedback. As a result, downtime is reduced and issues are resolved faster than they would otherwise be.
Without open communication, it’s easy for important issues to all through the cracks. This creates tensions between teams, further pushing them apart, which impacts projects negatively. Customer satisfaction drops when issues aren’t resolved in a quick manner and solutions are delayed. DevOps brings Dev and Operations in better communication so that issues fixed quickly, thereby opening the pipeline to quicker releases.
A Collaboration Culture
DevOps is all about creating a culture of collaboration such that teams become cross-functional and collaborative.
Tools and automation are great. But they mean little if humans in Dev and Operations who implement them lack the desire to work together. What DevOps does is to provide a paradigm for communication and collaboration. Since it requires the willingness on the part of humans to communicate and collaborate, it can be said that implementing DevOps as a culture requires the willingness to adopt the stops that can make it work. Here are a few pointers on making the DevOps culture work.
DevOps could be thought of as agile that has operations embedded. Team should be viewed not as functions-oriented but, rather, as project or product oriented. Product or project teams could include teams such as QA, Dev, design, project management, product management, operations, etc.
The aim is to encourage collaboration through common, shared goals and a roadmap to attain it together. Some companies may find it challenging making the shift from being function-based to project or product-based. In such situations, taking baby steps helps. Teams should invite the appropriate members of other teams to participate in their planning or knowledge sharing events. For example, Dev could ask Operations and QA to participate in sprint planning, standups and demos. Operations, and QA, could invite Dev to key events as well. Any time spent in understanding subject matter, ideas and challenges from other teams provides knowledge that could help in troubleshooting emergencies and solving problem, thereby creating faster, more efficient releases.
Stuff sometimes happens during product development, making emergencies unavoidable – everything from servers going done, critical errors detected in system configuration, show-stopper bugs that shouldn’t be deployed, etc. Although emergencies are not hoped for, they are a good way of testing the DevOps culture in a company. For example, is the problem jointly countered and resolved by the Dev and Operations teams? With DevOps, Retrospectives (post-mortems) are more about fixing broken or faulty processes, instead of finger-pointing.
In organizations where DevOps are practiced successfully, its culture cuts across various departments and job title levels. Everyone is product-focused. Communications are open between members of different teams so that the goals from different teams are aligned and adjustments are made where necessary. Customer satisfaction, for example, becomes a shared responsibility not just for only the product or sales team but also for the development or QA teams. Everyone takes ownership of, and responsibility for, the end result.