DevOps始于"敏捷系统管理"一文。 2008年, 安德鲁(Andrew Shafer)发表了"敏捷基础(Agile Infrastucture)" 的演讲,意图解决许多开发者和公司遇到的类似问题。
2009年,帕特里克(Patrick Debois)创立了"DevOpsDays"会议来推广DevOps的概念。然而,直到谷歌发布2010年趋势盘点一文后,人们才开始把DevOps当成一项独立的概念。
如今,DevOps的概念已经不止于开发、系统管理和基础,它包括开发、运维、敏捷、云、开源和商业化等等。
DevOps在不断演变。目前,DevOps不存在认证、角色、系列工具或是固定流程。没有规范,也不是一个产品或是职位的名称。没有一种权威的说法能定义DevOps是什么或不是什么。它关乎于态度、思想、习惯、行为、文化、范式、哲学。它是一种思考、行动、存在的方式。实践就是最好的布道。践行DevOps是一场对话,你将采取最佳的方式实践并将经验分享给他人。
以下有一些已经被验证有效的非常重要的质量标准、指导原则、技术要点,每个人都应该了解。从它们开始实践DevOps会是最好的尝试。
开始学习吧!
注:以下实践准则已经按它们最合适出现的阶段划分,以望读者能更容易地理解……虽然并不能保证这种划分一定准确
- 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
#Translate into Chinese