DevOps is a hot topic right now, and amidst the marketing hype and buzzword-frenzy it can be hard to get to the essence of the concepts it introduces.
What really is at the heart of DevOps? Perhaps my 3 sentence summary of the "DevOps mindset" can help...
The DevOps Mindset:
Make your software-building process into an automated pipeline and optimize it for speed of delivery.
The software pipeline should ensure security, quality and stability by automating the building and testing of infrastructure and applications and progressively prove their fitness by providing feedback (via tests), and when ready, deploy it to end-users.
Work to continuously improve the flow (speed) and feedback of the software pipeline
Okay, so I cheated on that 2nd sentence... it's more of a paragraph :)
The key elements of the pipeline are:
- It automates the building of both infrastructure and applications.
- It applies a series of automated tests to both infrastructure and applications (unit, integration, performance etc) to prove they meet their functional and non-functional requirements.
- When proven to be fit to release, it automates the deploy to end-users.
The Business Value of DevOps:
- DevOps primarily applies to businesses that build or assemble their own software, versus just using pre-built software.
- DevOps offers the greatest value to businesses where speed of delivery provides a significant competitive advantage.
Additional Insights:
- To increase speed without compromising quality, limit the size of the changes pushed through the pipeline at any one time.
- Errors should cause the pipeline to fail dramatically, forcefully calling attention to the change that caused the breakage.
- To achieve speed, eliminate slow, repetitive and error-prone human effort. Limit human intervention to decision-making, analysis and other creative effort (ex. exploratory testing).
- Departmental silos (Product/Development/QA/Operations) are antithetical to software pipelines. Taking a software build through the pipeline successfully requires cross-functional expertise and collaboration. Thus DevOps requires changes in org. culture and team structure.
- Build infrastructure and applications via a version-controlled codebase for traceability and repeatability.
- Build security into the product by integrating it into the pipeline.
- Software architecture matters: DevOps is most effective when you can build, test and deploy discrete components of your product.
- To improve the pipeline, make it's health and metrics visible to stakeholders.
DevOps & Happier Teams
Obviously this is a very high-level overview of DevOps concepts and principles -- applying them and building a solid software pipeline is a challenging but worthwhile goal.
Did you know that peer-reviewed research shows that DevOps reduces the pain/stress involved in releasing software, thus reducing engineer burnout? Adopting DevOps can improve the quality of life for your key engineering teams.
Did I miss or misstate something? Feel free to let me know your thoughts & comments.
Top comments (7)
Thanks Ash! I agree that custom development gets the DevOps and CI/CD spotlight, however, I see many customers applying these same processes and tools to packaged software and achieving the benefits you described. An example is Oracle E-Business Suite which is a packaged ERP that is customized heavily. Monolithic and 'legacy' technology, absolutely. But the speed, quality, feedback, and other benefits are there for the taking. Not the least of which is Happier Teams, great call out.
+1, agreed. I have heard of Mainframe teams adopting and benefitting from DevOps as well. I tried to include use cases like your example by using the more generic term "software building" vs "software development". Also when talking about business value: "DevOps primarily applies to businesses that build or assemble their own software...". Thanks for highlighting this key point!
Sounds more like you are describing continuous integration and deployment.
To me DevOps is so much more than that. It is empowering teams, entrusting them with larger portions of the SDLC than traditional models do.
What larger portions of the SDLC would a cross-functional team constituted from Product, Development, QA & Operations be entrusted with?
This is actually very much a whole process like Ash describes very well. While CI is where this is usually seen as examples, it can be successfully applied to multi-stage periodic releases as well.
I wrote an article this morning about how we implemented this on our team: scatteredcode.net/application-life...
Every point, right on target!
Additionally, since "every company is a technology company" every organization can benefit from adopting DevOps practices.
I look forward to your future articles.
That’s a great breakdown!
And to be fair, your first sentence was the cheater—it’s a compound sentence!