關于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.
