DevOps is the practice of combining software development (Dev) philosophies and tools with software operation (ops). DevOps includes every aspect of a software system for better or worse, including real source code, infrastructure, setup, information, testing, implementation, staging, manufacturing, etc.
Finding and applying the best DevOps processes that are commonly accepted can, therefore, be a challenge, as there is no method that is totally “right.” Instead, enhancing the DevOps process of your teams involves just as much implementing a philosophical shift as changing the system’s code or scripts.
DevOps is a word that emerges from two significant associated trends that collide. The first part was also called “agile infrastructure” or “agile operations;” it stemmed from the application of Lean and Agile methods to operations work. The second part is a much extended knowledge of the importance of cooperation between dev and ops staff during the creation and operation of a service throughout all phases of the software development lifecycle and how significant activities have get in our service-focused world.
Each new environment has to be established from scratch in a traditional development scenario, making it a very tedious and long process. Nevertheless, releases are more frequent in a DevOps environment and therefore time for testing and quality assurance is much shorter. Therefore, performing all these tasks manually significantly undermines the DevOps approach’s efficacy.
A “best practice” concept is an enigma. Who gets to decide whether a practice is actually the best? And for whom is it best? While in most frameworks a mentality of “adopting and adapting” is advocated, there is still a tendency to benchmark attempts against and comply with published best practices. Whether supporting “best in breed,” “world-class,” or “best practices,” many organisations are swinging around these terms as some sort of competitive advantage.
Is that really? Should business outcomes not be the true competitive advantage and evaluate whether IT practices are the “best” to satisfy client’s needs?
The DevOps Institute was established in 2015 for emerging DevOps practices as a worldwide teaching society. They have deliberately prevented any reference to “best practices” of DevOps since their launch. DevOps methods are constantly emerging and are proven in the wild in many cases.
Through the Regent’s and partners’ research, interviews, conferences, and experience, DOI’s objective is to define, capture, and share evolving DevOps practices through information, education, and certification models that best serve the teaching community and enterprise IT. Certifying an individual as an “Expert” or “Master” is premature when the skill and mastery required for effective DevOps is unclear and may not be suitable in a single individual.
DevOps is quite young. It has no single knowledge body. Whether it’s a philosophy, movement, or structure, there’s disagreement. Nevertheless, DevOps is moving quicker than any other IT framework from innovators to the early majority. Why? Maybe it’s because DevOps speaks to many of the cultural and technical difficulties IT has accumulated for years.
So let’s agree on the key values of DevOps instead of concentrating on best practices:
- Go faster
- Experiment and learn
- Cultural transformation
- Shorten feedback loops
- Deliver business and customer value constantly and consistently
Certain practices have obviously emerged as critical to the realization of the key values of DevOps:
- Agile software development
- Improved communication and collaboration
- Proactive monitoring
- Continuous integration
- Automated and continuous testing
- Continuous delivery pipelines
However, DOI has witnessed additional practices gaining interest over the previous year
- DevSecOps/rugged DevOps
- Agile service management
- DevOps teams
- Immersion practices (Garage, Lofts, Dojos)
What’s going to happen next year? Who knows, but that is the interesting thing about DevOps. There’s less contradiction and more supplementation as time goes by. Every evolving practice seems to fine-tune and complement what came before.
DevOps is already encouraging organisations to examine their own methods, identify gaps, evaluate their automation and, most importantly, participate in cooperative debates, even without a standard definition. Without defined best practices, transformations have taken seed. That’s fantastic! By attaching a static set of best practices, let’s not quench the momentum.
Will the best practices of DevOps finally be agreed? Maybe. DevOps covers nearly all aspects of IT management – people, procedures, and automation. This is a high order for a number of best practices.
Certainly some will attempt to release their version of a knowledge-based “definitive” DevOps. Even “The DevOps Handbook” was constructed as a cooperative attempt among many of the early founders of the DevOps movement, a significant book publishing later this year. Their insight and outlook will be fantastic, but not finite.
The frustration by the lack of a single body of knowledge and prescribed best practices is understandable. The body of information was both an enabling tool and a restrictive limitation in previous frameworks.
Some of the best practices for DevOps:
- Version Control for all
- Break the silos in IT
- Automate Your Infrastructure
- Use Software Automation wherever you can
- Embrace the principles of Chaos Engineering
- Adjust Performance Reviews
- Create real time project visibility
- Deploy to Temporary Environments
- Choose tools that are compatible with each other
- Implement Continuous Environment Testing
Knowledge bodies are hard to maintain up to date. For DevOps, let’s adopt spirit ideas of sharing, cooperation, and ongoing innovation by encouraging an inclusive and collective knowledge body of emerging methods.
DevOps’ genesis emerges from a growing requirement for system side technology work’s innovation. This movement starts from the Enterprise Systems Management (ESM) movement and Agile System Administration movement.
Since it focuses on providing value in a project lifecycle much earlier, DevOps can be viewed as an optimal strategy for national and government IT projects as well as massive private sector projects. It enables accelerate new services through continuous improvement and flexibility in operation, offering innovative and cost-effective methods to deliver value through new aspects of growth and operations.
DevOps arose from these stuffs coming together as a “perfect storm.” The increasing toolchain and automation strategy fed by better surveillance and supplying tools, the necessity for agile procedures and dev & ops cooperation with the failure of ITSM / ITIL’s big / heavy implementations – all 3 layers that you need for agile movement i.e. principles, procedures, and processes, and caught fire collided and unconsciously brought together. Since then, DevOps has evolved further, most particularly through the incorporation by many leaders of Lean concepts.