2008 年 6月：美国旧金山，第一届 Velocity 大会和 The Agile Admin博客
这一年是 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 年，《持续交付》的作者Jez Humble参加了第二届的 DevOpsDays 并做了 “持续交付”的演讲。
从本质上说《持续交付》中所提到的实践给 Patrick 和 Andrew 最初所遇到的问题给出了最佳实践。如果《持续交付》早两年问世，也许不会出现 DevOps。然而，随着 DevOps 理念的传播，DevOps 的概念的外延越来越广，已经超出了《持续交付》本身所涵盖的范畴。
“持续交付”是“持续集成”的延伸，而这点恰恰和2008年敏捷大会中的观念一致。但由于发生时间的先后关系，“持续交付”被看作是敏捷以及 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.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.
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.
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!
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”.
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.
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!
The process of pushing local development code changes to the common source repository.
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.
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 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).
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.
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.
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.
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.
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 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).
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.
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 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.