我们无数次听到这类的抱怨：管理层不会去做、代码太过混乱、项目太大、有太多的监管障碍。由此种种，对于许多企业来说，在持续集成/持续部署的道路已步履蹒跚，但不得不说，仍有一部分企业做到了。
以Michiel Rook在2016 年的DevOps大会上的演讲为例，一起来看看关于持续部署的发展之旅。他们的项目被称为“San Diego Project”，但他们公司内部却被称为“大泥球”，因为它的代码库相当地混乱。
下图是实施持续部署前的状态：
该项目的压力很大。皆来源于它纯手动发布，脆弱的测试，频繁的宕机以及问题不断。这个项目团队大约由16人组成，但他们对修改现有代码并没有什么信心。
他们知道需要做什么，所以他们设定了以下目标：
减少问题
减少周期时间
提高生产效率
提高积极性
他们采取的方法是：整体修改，建立一个代理并添加一个服务，然后不断地增加服务，直到这个整体被取代。
他们以如下原则来指导这次持续部署之旅：
应用strangler模式
使用API的第一个方法
为每个domain设置一个服务
迁移单个页面
建立负载平衡器后的服务
访问遗留数据库
实施持续部署
运用docker
开发前端作为服务
从持续集成开始：开发和构建/测试，每次都产生一个工件。持续交付：从构建/测试到验收再到生产; 进入生产阶段是一个手动的过程，但代码是可部署的。最后，当整个流程实现自动化时，就达到持续部署的目标了。
关于持续部署的优点有以下几点：
小步推进
早期反馈
减少循环时间
风险减低
实验室环境
Michiel的项目落地后，他总结了几个实现持续部署的关键方面，如下：
l直接提交到Master。没有分支。我们都不希望延迟集成，且滥用版本控制功能分离。另外，分支上的所有内容都会增加冲突和延迟集成的风险。
每一次提交都要投入生产。
使用配对编码进行代码审查。这需要约束，但所有的开发人员都需要成对进行，混合搭配有经验的开发人员。
严把质量关。确保大量测试和代码覆盖率。
功能切换和A/B Test。确保一部分开发人员可以看到版本信息，一部分人不能看到，并促进A / B测试。但一定要把人员数量保持在一个合理的范围内。
Dashboards。显示是部署的关键，通过它我们可以获取很多信息，比如KPI、构建时间、页面加载时间、访问者数量、A/B Test结果，等等。
DevOps。心态是一种文化；dev和ops之间并无太多隔阂。团队内部都拥有所有权，但这并不意味着每个人都知道所有事。
自动化可重复的事。如果同样的事你需要做两次，那说明你已经浪费了时间。
连续测试。使用单元测试和冒烟测试来查看服务是否存在，并持续监控。探索性的测试很重要，因为你将继续测试最关键的路径。
管道作为代码。自动化流水线。最后，部署起来是这样的：
反馈–及时的反馈很重要，因为DevOps是在此基础之上建立的。举个例子，Michiel这个项目上有一个闪烁的红光，这表示失败。所以不管什么时候，及时反馈都是工作中的第一要事。
Michiel的项目时间跨度有一年之久。最终，他们将每个服务的构建时间减少到不到10分钟，显著改善了页面加载时间，同时他们自己也增加了自信心和加快了速度等。明白了团队需要接受和改变的重要性的真理。同时，他们还了解到，与业务优先级一致是关键，确保拥有一定工作经验的员工亦是至关重要，限制功能切换同样至关紧要。
总的来说，Michiel和他的团队实现了持续部署。在他的演讲结束时，Michiel也提到了他的无奈，想要取代的遗留系统仍在服务中。所以持续部署这条路还很长，但值得去做。
关于Ghostcloud
Ghostcloud（中文名：精灵云）坐落于成都天府软件园，是成都高新区重点扶持企业，国内首批从事容器虚拟化研发的企业，是西南地区唯一一家基于Docker的云计算服务商，为企业级行业客户提供针对互联网化、私有云管理平台、大数据业务基础架构的平台服务。
Ghostcloud因容器技术而生，以最新容器技术Docker为基础，为适应不同行业客户需求，全自主研发了一套调度引擎框架Newben，且全方位适配Kubernetes主流开源调度引擎，也是国内率先实现双调度引擎的企业，是一流的企业级容器云服务专家。Ghostcloud推出了企业级容器云PaaS／CaaS平台，命名为EcOS（EnterpriseContainer Operation System）。Ghostcloud将EcOS平台与微服务／DevOps相融合，运用至企业IT系统的全生命周期的开发、测试、运维及发布流程中，致力于为多个领域企业向“互联网+”转型提供针对互联网化、私有云管理平台、大数据业务基础架构的平台服务，帮助企业级客户降低成本、提升效率、简化运维及产品部署，并提升系统的可靠性和安全性。
