Find the original here article here: Devops Best Practices
DevOps started out as "Agile Systems Administration". In 2008, Andrew Shafer did a talk called "Agile Infrastucture" addressing issues around involving more of the company in the same disciplines as programmers.
In 2009, Patrick Debois created "DevOpsDays" conference to help to bring it to light. However, it wouldn't begin to trend until about 2010, when people would begin to describe it as a standalone discipline.
Today, DevOps goes beyond just developers, systems administration and infrastructure, its about dev, ops, agile, cloud, open source and business, everything.
DevOps is a movement. There's no certificate, role, set of tools or prescriptive process. There's no specification, it's not a product, or job title. There's no one true voice on what DevOps is or isn't. It's about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It's a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It's a conversation. It's about taking the best experiences and sharing those with others.
There are some very important qualities, principles and techniques that have proven to work, that everyone should be aware of, they are the best practices.
Let's explore those...
Note: Though not necessarily accurate, the practices are broken down into their evolutionary stages to make it easier to digest...
- People are the key - Get everyone together at the beginning. Keep meeting. Make it easy for everyone to see what’s happening.
- Products not projects - Delivery teams run software products, not projects, that run from inception to retirement.
- Keep everything in version control, all code should be under version control, allowing for code development and review, source code management tools, code merging.
- Culture - There's t-shirts, songs, music videos, podcasts, books. DevOps is as much about preaching as it is practicing.
- Kanban - Being able to limit the flow of work to a given worker is key, you must limit work in progress.
- Domain Driven Design
- System metaphor
- Systems thinking
- Two Pizza Teams
- Prioritisation - Work on the most important thing first
- Use analogies to communicate important concepts
- Blameless Post-Mortems
- Release early, release often - until code is in production, no value is actually being generated. If it hurts, do it more often, and bring the pain forward.
- Release often - How to eat an elephant - one bite at a time
- Listen to customers - Close the loop, focus on building a great product that people want to use
- Specification by Example
- Shu-Ha-Ri - Follow the rule, break the rule, be the rule.
- Sacrificial Architecture
- Embrace failure
- Apply Conway's law
- Continuous Improvement - An “improvement,” or “change for the better” which refers to a philosophy or practices that focus on continuous improvement of processes in manufacturing, engineering, game development, and business management.
- Reduce waste
- No silos - Cross-functional teams and T-shaped people, an attitude of shared responsibility is an aspect of DevOps culture that encourages closer collaboration.
- Key Performance Indicators - Management thinker Peter Drucker is often quoted as saying that "you can't improve what you can't measure".
- Non-Functional Requirements as user stories
- Minimum viable product
- A journey, not a destination
- Embrace change
- Build the right thing, then build it the right way
- Lean startup
- People over process
- Test at the appropriate level
- High trust culture
- Address Technical Debt
- "cattle rather than pets" - the paradigm of disposable server infrastructure.
- Achieving 10 deployments per day - the story of how Flickr adopted DevOps.
- Continuous Integration - When the build fails, it’s usually back to green within ten minutes.
- Quality Built In - Build quality in, from start to end. Quality is not something you tack on the end.
- Zero Bugs
- Don't fire the QA - Are we building the correct product? If so, are we building it correctly?
- Automation
- Test Automation
- Automation over documentation
- Shift left
- Testing as code - Use the gherkin language "Business Readable, Domain Specific Language", for manual as well as automated. Keep all your tests with your code, use version control to track changes.
- Continuous Delivery - Continuous Delivery is a key part of the evolution of adopting a DevOps culture.
- Deployment Pipelines - Get humans out of the deployment business. Create a repeatable, reliable process for releasing software.
- Trunk based Development - Moving to trunk-based development is an (essential step in getting to continuous deployment).
- Production-ready software - Fast, automated feedback on the production readiness of your applications every time there is a change - to code, infrastructure, or configuration.
- Everything as code - Infrastructure as Code, Security as Code, Compliance as Code, Testing as Code.
- Reduce the risk of releasing
- Automate (almost) everything
- Securing Software through Continuous Delivery
- Focus on mean time to recovery
- Pipelines as code
- Decrease lead time
- Feature Toggles rather than feature branches, avoiding merge hell and more control over features and deployments.
- Infrastructure as Code - Using orchestration and provisioning tools such as Terraform, Docker, Kubernetes, Ansible, Chef, Puppet.
- Done means released
- Everybody is responsible for delivery
- Blue Green Deployments
- Put devs on call - Developers are responsible for monitoring and alerting
- High Scalability
- Moving from Monoliths to Microservices
- Data-driven products
- Performance testing as a first-class citizen
- Embrace NoSQL
- Immutable infrastructure
- Big data
- Platform as a service
- Cloud
- Design for failure