关于DevOps，目前在国内，BAT 阿里巴巴，腾讯，百度，京东，美团，在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP，HPE等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事？我们先来了解一下DevOps的前世今生吧：
2007 年：比利时，一个沮丧的独立IT咨询师
DevOps的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois，他喜欢从各个角度研究IT组织。
2007 年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中，他负责测试和验证工作。所以他不光要和开发团队（Dev）一起工作，也要和运维团队（Ops）一起工作。他第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作氛围的切换令他十分沮丧。
他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异：开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者，他渐渐的明白如何在这种状况下改进自己的工作。
2008 年 6月：美国旧金山，第一届 Velocity 大会和 The Agile Admin博客
2008 年，在美国加州旧金山，O'Reilly出版公司举办了一场名为Velocity的技术大会，这个大会的话题范围主要围绕Web应用程序的性能和运维展开。这个会议被设计用来分享和交换构建和运维Web应用的性能、稳定性和可用性上的最佳实践。
这一年是 Velocity 大会举办的第一年，这个大会吸引了来自Austin的几个系统管理员和开发人员。他们对大会中分享的内容十分激动，于是记录下了所有的演讲内容，并决定新开一个博客分享这些内容和自己的经验。他们同样也意识到敏捷在系统管理工作中的重要性。于是，一个名为 The Agile Admin 博客诞生了。
2008 年 8月：加拿大多伦多，Agile Conference 2008 大会埋下了DevOps的种子
同年 8月，在加拿大多伦多的 Agile Conference 2008（敏捷大会）上，一位名为 Andrew Shafer 的人提交了一个名为“Agile Infrastructure”的临时话题。由于对这个临时话题感兴趣的人不多，Andrew 认为没人会对如何 跨越 Dev 和 Ops 的鸿沟 这个话题感兴趣。所以当这个话题时间开始的时候，作为话题提交人的 Andrew 并没有出现。
但是话题开始的时候，仅有一个人出席。这个人就是上文提到的IT咨询师 Patrick 。Partrik 在这次会议上分享了自己的话题：如何在运维工作中应用 Scrum 和其它敏捷实践。他十分想把这些经历和别人分享。
最终，Patrick 在会议厅的走廊里找到了 Andrew，并进行了一场漫长的讨论。他们意识到在这次会议之外会有很多的人想要继续探讨这个广泛而又系统化的问题。
尽管在这次会议中，持续集成的流行已经使敏捷实践慢慢走向部署了。可是这仍然把运维工作和开发完全割裂开。于是他俩决定在 Google Group 上建立了一个 Agile System Adminstration 的讨论组继续这个话题。虽然有一些话题和参与者，但是访问者寥寥。
2009 年 6月：美国圣荷西，第二届 Velocity 大会上一个轰动世界的演讲
这一年的 Velocity 大会最大的亮点是一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，几乎所有的和 DevOps 相关的资料都会把这个演讲作为 DevOps 的引用。这个演讲的内容可以作为 DevOps 萌发的标志。这个演讲提出了了 DevOps 的“一个中心，两个基本点”——以业务敏捷为中心，构造适应快速发布软件的工具（Tools）和文化（Culture）。
Patrick 在网上看到了这个视频后很兴奋，因为这就是他一直致力于的领域。于是他在Twitter 上问如何才能参加 Velocity 大会。
其中有个人回复: 嘿，Patrick，你想在比利时召开自己的 Velocity 吗？我们都会去参加，这一定会很棒。
2009 年 10月：比利时根特，DevOpsDays 和 DevOps
于是，Patrick 就想通过 Twitter 召集开发工程师和运维工程师在比利时举办一个类似于 Velocity 的大会。但如果要召开一个会议，就得有一个名字。Patrick 首先就想到了Dev和Ops，由于这个会议会持续两天，所以他加上了 Days，于是就有了 DevOpsDays。由于 Twitter 上有140个字符的限制，因此他想用 DOD 作为 DevOpsDays 的缩写以提醒自己“死在交付上”（Dead On Delivery），但不知什么原因，最后没有这么做。
虽然这是一届“社区版 Velocity 大会”，但这届大会出乎意料的成功。人们从世界各地蜂拥而至，除了开发工程师和运维工程师，还有各种IT管理人员和工具爱好者。两天的会议已经结束后，参与 DevOpsDays 的人们把这次会议的内容带回到了世界各个角落。
然而， DevOpsDays 的讨论仍在 Twitter 上继续着。由于 Twitter 140个字符的限制，大家在 Twitter 上去掉了 DevOps 中的 Days，保留了 DevOps。
于是， DevOps 这个称谓正式诞生。
2010 年：The Agile Admin博客发表“ What is DevOps ”
在 DevOpsDays 之后，DevOps 被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式，DevOps 成为了一种促成开发运维合作的运动。人们在各种场所和活动中不断分享自己的经验和见解，并催生了很多工具和实践的产生。但是，每个人对 DevOps 的理解都有所不同，争议在所难免。
这些争议促社区统一化 DevOps 的见解的需要。于是 The Agile Admin 发表了“ What is DevOps ”这篇文章。该文给出了详细 DevOps 的定义，并且依据敏捷的体系构造出了DevOps 的体系: 它包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了 DevOps 的历史和对DevOps 的一些误解。
现在通过Google 搜索 DevOps，“ What is DevOps”仍然排在搜索结果的第二位（第一位是维基百科对DevOps的解释）。
2010 年：德国汉堡，第二届DevOpsDays：对不起，《持续交付》来晚了
2010 年，《持续交付》的作者Jez Humble参加了第二届的 DevOpsDays 并做了 “持续交付”的演讲。
从本质上说《持续交付》中所提到的实践给 Patrick 和 Andrew 最初所遇到的问题给出了最佳实践。如果《持续交付》早两年问世，也许不会出现 DevOps。然而，随着 DevOps 理念的传播，DevOps 的概念的外延越来越广，已经超出了《持续交付》本身所涵盖的范畴。
“持续交付”是“持续集成”的延伸，而这点恰恰和2008年敏捷大会中的观念一致。但由于发生时间的先后关系，“持续交付”被看作是敏捷以及 DevOps 文化的产物。而今，持续交付仍然被作为DevOps的核心实践之一被广泛谈及。
以上就是DevOps的“前世今生”，DevOps发展至今，可以说还没有形成标准。所以，关于DevOps的说法也是各种各样。这样，对于想了解DevOps的人来说，就会产生较大的困惑。
DevOps的不同理解
我们从互联网上收集了10个DevOps的定义并专家的一些点评，希望能对要了解DevOps的人有所帮助~
1、DevOps=自动化运维（道听途说）
专家点评：这个定义太简单了，虽然我们经常听到这个说法（特别是做运维管理的人），但它真的不准确。
2、DevOps就是开发（Development）和运维（Operations）这两个领域的合并。（来自互联网）
专家点评：这个说法比较绝对，也比较片面，实践中也不太可行。
3、DevOps旨在将不同的社区，比如开发和运维社区，联合起来变成一个更有效率的整体。(来自《DevOps实践—驭DevOps之力强化技术栈并优化IT运行》一书）
专家点评：这个说法比上一种说法有了一点进步，但还是没有跳出开发和运维整合的圈子。
4、DevOps就是使用一些自动化工具解决开发人员、QA、运维人员之间那些磨磨叽叽的事。（来自简书）
专家点评：这个答案与前两个相比已经有了较大的进步，因为它提到了开发、QA和运维三方，还提到了自动化工具。但只靠自动化工具去解决“那些磨磨唧唧的事”，层次就有点低了，而且效果也不会很好。
5、DevOps是一套最佳实践方法论，旨在在应用和服务的生命周期中促进IT专业人员(开发人员、运维人员和支持人员)之间的协作和交流，最终实现：持续集成、持续部署、持续反馈。（来自知乎）
专家点评：这个定义一看就是熟悉ITIL的人写的，因为里面提到了最佳实践、生命周期等概念。定义中提到了协作和交流，但开发人员、运维人员和支持人员这个三方的说法有点不妥，运维和支持应该属于一类，缺了QA人员。
6、DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。（来自互联网）
专家点评：这个定义比较简洁，提到了文化、交流和协作、更快、质量更好、运动等关键词。但没有提到开发、QA和运维这三方，稍有遗憾。
7、DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。（来自InfoQ）
专家点评：这个定义其实我已经挑不出什么毛病，如果“沟通合作”的人员中加入QA人员就更好了。
8、DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。（来自维基百科）
专家点评：这个定义也很专业，基本上无懈可击。
9、DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。（来自百度百科）
专家点评：这个定义与上一个一样，也很完美。
10、DevOps是一组方法、过程与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。这种协作可以提高应用的开发速度，减少开发和运营之间的摩擦，从而快速部署软件或应用程序，并且可以快速检测。（对上面多个定义整合的结果）
专家点评：这是我最喜欢的DevOps定义，它的表达很准确，也很全面。以下是维基百科权威的DevOps的解释，我觉得很贴切准确，分享给大家。
DevOps is a cultural shift and collaboration (between development, operations and testing), there is no single "DevOps tool": it is rather a set (or "DevOps toolchain"), consisting of multiple tools.[12]Generally, DevOps tools fit into one or more of these categories, which is reflective of key aspects of the [software development]Code — Code development and review, version control tools, code merging;Build — Continuous integration tools, build status;Test — Test and results determine performance;Package — Artifact repository, application pre-deployment staging;Release — Change management, release approvals, release automation;Configure — Infrastructure configuration and management, Infrastructure as Codetools;Monitor — Applications performance monitoring, end–user experience.
Though there are many tools available, certain categories of them are essential in the DevOps toolchain setup for use in an organization. Some attempts to identify those basic tools can be found in the existing literature.[15]
This guide is for you if ….
You’re in tech, you’re a product manager or an MBA. Your team A/B tests, feature toggles, and you have a dog in the office! Of course you understand what feature branches are, what CD is and what a DevOps culture looks like. Right? Uh … sure.
You’ve gone Agile. Engineering teams now meet with your product people every week to discuss stories and iterations. They collaborate well and what they’re building feels better than ever. But your customers still don’t get those features any faster. You still have to wait for the release train to leave the station. You’ve heard about companies like Etsy, Flickr and Google who deliver a 100 times a day. How do they do it?
Your development team wants to “do CD”. You’ve heard some good things but you’re also concerned about changes going to production without them being properly tested or not being able to market the changes properly. What is this CD thing?
I am here to demystify these practices, tell you just how important they are to you “on the business side” and help you get involved. It’s not that complicated, we have pictures and everything.
Let’s start with some definitions and examples
Continuous Integration (CI)
In traditional software development the process of integration generally took place at the end of a project after each person had completed their work. Integration generally took weeks or months and could be very painful. Continuous integration is a practice that puts the integration phase earlier in the development cycle so that building, testing and integrating code happens on a more regular basis.
CI means that one developer (hi Steve!) who writes code on his laptop at home, and another dev (hey Annie!) who codes on her desktop in the office can both write software for the same product separately, integrate their changes together in a place called the source repository. They can then build the combined software from the bits they each wrote and test that it works the way they expect.
Developers generally use a tool called the CI Server to do the building and the integration for them. CI requires that Steve and Annie have self-testing code. This is code that tests itself to ensure that it is working as expected, and these tests are often called unit tests. When all the unit tests pass after the code is integrated Steve and Annie will get a green build. This indicates that they have verified that their changes are successfully integrated together, and the code is working as expected by the tests. However, while the integrated code is successfully working together, it not yet ready for production because it has not been tested and verified as working inproduction-like environments. You can read more about what happens after CI in the Continuous Deliverysection below.
To be considered to be practicing CI, Steve and Annie must check-in to the main source repository, integrate and test their code frequently and often. Usually many times an hour, but at a minimum once a day.
The benefit of CI is that integration becomes a non-event. Software is written and integrated all the time. Before CI, integration happened at the end of the creation process, all at once, and took an unknown amount of time; now with CI, it happens everyday, takes minutes and is just “the way we work”.
It’s most likely the your team is doing CI (or at least they believe they are). You can confirm by asking them whether they integrated code once a day (https://s.w.org/images/core/emoji/2.3/svg/1f642.svg) CI is the first practice that is required to do Continuous Delivery. In fact, if you’ve ever checked in help text, documentation or images, then you may have been continuously integrating!
Continuous Delivery (CD)
Let’s go back to our two developers, Steve and Annie. Continuous Delivery means that each time Steve or Annie makes changes to the code, integrates and builds the code, that they also automatically test this code on environments that are very similar to production. We call this progression of deploying to – and testing on – different environments a deployment pipeline. Often the deployment pipeline has a development environment, a test environment, and a staging environment, but these stages vary by the team, product and organisation. For example, our Mingle team has a stage called “Cupcake” which is a staging environment, and Etsy’s staging environment is called “Princess”.
In each different environment, the code that Annie or Steve wrote is tested differently. This gives more and more confidence to them, and to you, that the code will work on the production environment when the code is deployed there. Crucially, the code is only promoted to (tested on) the next environment in the deployment pipeline if it passes the tests of the previous environment. This way Annie and Steve get new feedback from the tests in each environment and, if there is a failure, they can understand more easily where the issue might be and get it fixed before the code gets to the production environment.
Continuously Learning
This process is very empowering for those of us in the business. It means that if Annie’s tests pass on all the environments, you know that her code is likely to be work as intended when it gets to production. Once the tests pass in all environments, you get to decide whether your end users get it or not, right away. Do we want this green build in production now? Yes! And with that, new, fully tested, working software is readily available for customers as soon as your developers finished building it. Woot!
Continuous Deployment
This is a practice where every change that Steve or Annie makes, and which passes all the test stages, automatically goes to production. Tim Fitz has a great explanation of it as it was first coined. Some companies do this and others do not. To achieve continuous deployment you first need to get to continuous delivery, so it’s not a priority to decide which is better for you until you’ve starting practicing CD. Either way, I’m of the opinion that continuous delivery is about empowering the business as a whole, and so at the very least you should be involved in deciding if you should use continuous deployment or not. After all, if you’re reading this then you’re probably on the “business side”.
DevOps
The word ‘DevOps’ comes from the combination of the words ‘development’ and ‘operations’. DevOps is a culture that promotes collaboration between developers (hey Steve and Annie, you’re back) and other technology professionals, often called operations or just ops (high-five ops star Joey!). Specifically, communication and collaboration during the software delivery and deployment process, with the goal of releasing better quality software more quickly and more reliably.
Common traits of organisations who have a so-called DevOps culture are: autonomous poly-skilled teams (Steve, Annie and Joey are all on the same team), high levels of test and release automation (a la continuous delivery) and common goals between the poly-skilled members.
One way you may see this working in your organisations is that our developer friends Steve and Annie will workwith ops people like Joey to deliver software into production, rather than just “hand off” their code to Joey for release when they’re done with it. Likewise Steve, Annie and Joey will all act as part of a* common product or service team* who will all be responsible for the support and maintenance of the product, rather than support being a solely ops-team responsibility.
You will also see automation of activities becoming increasingly important to an organisation doing CD and DevOps. This is because, in order to achieve the repeatable, regular and successful process of releasing software that we expect from CD and DevOps, organizations must move to an automated process. Manual processes are simply too error prone and inefficient.
DevOps culture is commonly associated with Continuous Delivery because they both aim to increase collaboration between developers and operations teams, and both use automatic processes to build, test and release software more quickly, frequently and reliably. All things that people like us want.
What’s Next?
While development teams often see the most immediate benefits of process improvements, there are lots of benefits of CI, CD and DevOps to the rest of us. Put simply, I believe that organisations practicing CD and embracing a DevOps culture will deliver more valuable, reliable software to their customers, more often. That’s got to be good, right? Especially if you’re on “the business side.”
Next time I will talk more about why you should care about these concepts. I’ll address the impact it can have on your business and how to get involved. If you have any questions, talk to me in the comments. The whole point of these posts is to empower you and inform you about technical practices that are meant to be business-relevant. Questions are great!
Useful Terminology
Checking in
The process of pushing local development code changes to the common source repository.
CI server
A tool used to build and test source code. The CI server will tell a developer if their latest code builds were successful and if they continue to pass tests.
Development environment
Where developers create, integrate, build and test code.
Deployment pipeline / pipeline
This is a set of stages that Steve and Annie’s code changes go through before they are done and ready to be delivered to production. Commonly these will be “build”, “unit test”, “functional tests”, “performance test” and “deploy”. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production.
Green build
Green is an indication of success. A green version or build is one where it has passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline unless it is “green”. The opposite of a green build is a red build (see below).
Incremental development
Not to be confused with iterative development (see below). Incremental development is where a little bit of the product gets built at a time until it is all complete. Pieces are added on in each increment, and those increments may be small or large. You can use CI with incremental development but it can be harder to achieve Continuous Delivery or Continuous Deployment with incremental development, as you must wait until all increments are completed to deliver value. A great illustration of the difference between Incremental and Iterative development is Jeff Paton’s Mona Lisa.
Integration
All code that is written by individuals or teams needs to be combined. We call this integration. In continuous integration, we generally mean software from individuals needs to be consolidated on a regular basis. In continuous delivery, we often mean software from different teams is integrated together to create the whole product.
Iterative development
Not to be confused with incremental development (see above). Iterative development is where a little bit of the product gets built at a time and is refined until it is complete. The product is built iteratively where the same pieces are reworked each iteration. Change is expected and planned between features in different iterations. You can use CI, Continuous Delivery or Continuous Deployment with iterative development. A great illustration of the difference between incremental and iterative development is Jeff Paton’s Mona Lisa.
Master/trunk/mainline
The “master”, “trunk” or “mainline” branch is the main branch of the source repository. Most people do trunk-based development,* *meaning that they will always integrate their changes to main line. Others do branch-baseddevelopment when individually developers will have their own branches, or teams will have branches for different features.
Production environment
This is the place where software gets deployed or released. Customers using your product or website are most likely using this environment. Also referred to as “in production”, “in prod” or “live”.
Red build
Red is an indication of failure. A red version or build is one where it has not passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline if it is “red”. The opposite of a red build is a green build (see above).
Source repository
This is where the source code lives. Steve and Annie have their own local version of the code that they are working on (meaning on their own machines), but the source repository will contain all the code after developers check in their changes to it.
Test automation
High quality test automation is needed to do continuous integration and continuous delivery. Tests are ways to check that the software will work as expected. Automated tests are tests that are coded and automatically run once code is checked into the common source repositories.
In the CI world, the unit tests are run each time the software gets integrated and built. If the tests don’t pass, that version of your software is determined as “not working”, “red” or “broken”. In some workplaces “red lights” or sad sounds occur when this happens.
In the case of a broken build, Steve or Annie (whoever committed the malfunctioning code) need to “fix it”, “make it green” or “get it working”. They can either do this by making a change to the code to fix it, or removing the prior change that broke it.
Unit tests
Unit tests are automated tests in code that test low-level, single pieces of code to ensure that they are usable and working as expected. Unit tests are considered a prerequisite for practicing CI and CD.
