u010230019的博客

入口精益运动敏捷宣言1. 敏捷、持续交付和三步法1.1 制造业价值流1.2 技术价值流1.2.1 聚焦于部署前置时间1.2.2 关注返工指标——%C/A1.3 三步工作法：DevOps 的基础原则2. 第一步：流动原则2.1 使工作可见2.2 限制制品数2.3 减小批量大小2.4 减少交接次数2.5 持续识别和改善约束点2.6 消除价值流中的困境和浪费2.7 小结3. 第二步：反馈原则3.1 在复杂系统中安全地工作3.2 及时发现问题3.3 群策群力，战胜问题获取新知。

【代码】《持续交付：发布可靠软件的系统方法》 - 目录。

持续交付：发布可靠软件的系统方法（十五）第 15 章 持续交付管理15.1 引言15.2 配置与发布管理成熟度模型15.3 项目生命周期15.3.1 识别阶段15.3.2 启动阶段15.3.3 初始阶段15.3.4 开发与发布15.3.5 运营阶段15.4 风险管理流程15.4.1 风险管理基础篇15.4.2 风险管理时间轴15.4.3 如何做风险管理的练习15.5 常见的交付问题、症状和原因15.5.1 不频繁的或充满缺陷的部署15.5.2 较差的应用程序质量15.5.3 缺乏管理的持续集成工作流程15.

DVCS背后的根本性设计原则是，每个使用者在自己的计算机上都有一个自包含的一等（first-class）代码库，不需要一个专属的“主”代码库，尽管根据惯例，大多数团队都会指定一个（否则的话，持续集成就做不了了）。从这一设计原则出发，引入了很多有意思的特性，如下所述。在几秒钟内就能开始使用DVCS了，即只要安装一下，并将修改提交到本地代码库就行了。可以单独从别人那里拿到他们的最新更新，却不需要他们将其修改提交到中央代码库。可以将自己的修改推送到一组人的代码库中，而不需要他们每个人自己来拿你的修改。

持续交付：发布可靠软件的系统方法（十三）第 13 章 组件和依赖管理13.1 引言13.2 保持应用程序可发布13.2.1 将新功能隐蔽起来，直到它完成为止13.2.2 所有修改都是增量式的13.2.3 通过抽象来模拟分支13.3 依赖13.3.1 依赖地狱13.3.2 库管理13.4 组件13.4.1 如何将代码库分成多个组件13.4.2 将组件流水线化13.4.3 集成流水线13.5 管理依赖关系图13.5.1 构建依赖图13.5.2 为依赖图建立流水线13.5.3 什么时候要触发构建13.5.4 谨慎

无论是为开发人员创建一个新的本地数据库，还是为测试人员升级系统集成测试（Systems Integration Testing，SIT）环境，或者作为发布过程的一部分迁移生产环境中的数据库，都应该能够使用这些脚本来管理交付流程中的每个数据库。比如，对于那些操作数据集只是某种暂存方式（transient）的项目，或者数据是预定义好的那些项目（比如，某个系统在运行时把数据库仅作为只读的数据源），只要清除前一个版本，并用一份新的副本代替它，或者从已存储的版本中重新创建一份新的数据就行了。这是一种简单有效的策略。

因为它是目前最流行的开源工具（当然CfEngine和Chef也很流行）。对于其他工具来说，基本原则是相同的。Puppet通过一种声明式的外部配置信息领域专属语言来管理配置。对于那些复杂的企业级配置信息来说，可以通过常见模式将它们抽取成可以共享的模块。这样就可以避免大量的重复配置信息了。

这样，如果某次提交的代码通过了所有的自动化测试，就直接部署到生产环境中。如果想让这种做法不引发问题，自动化测试（应该包括自动化的单元测试、组件测试、功能性和非功能性验收测试）就必须异乎寻常的强大，覆盖整个应用程序。必须先写所有的测试（包括验收测试），然后再写代码。这样你才能做到，只有用户故事完成的最后那次代码提交才能使验收测试通过。

这里所说的“受控”是指，可以为每个测试创建正确的初始化状态。然而，遗憾的是，对于我们创建的大多数系统来说，它执行得非常慢，因为除了那些最简单的软件系统以外，其他软件系统都要花相当长的时间来清理它的状态，并启动应用程序。实际上，这里的 “有状态”是指为了测试应用程序的某个行为，应用程序必须处于某种特定的起始状态（就是行为驱动开发中，“假如”那段所描述的内容）。然而，正如本章后面会讲到的那样，当使用XUnit Test这类测试框架时，可以将验收条件写在测试的名字中，然后通过XUnit测试框架直接运行验收测试。

记住，计算能力是廉价的，而人力是昂贵的。可在现实中，我们从来没看到过这么复杂的东西，但曾经做过下面这样的事：写一个脚本，当某次构建的编译警告的数量比前一次增多或者没有减少时，就让提交阶段失败（这就是“渐进式”实践），如3.6.4节所述。当然，如果重复代码的数量超出了某个事先约定的限制，或者有关代码质量的其他度量项不符合约束条件时，就令提交阶段失败，这是完全可以接受的。问题是，在这种设计得比较好的模块化系统中，为了测试一个在关系网中心的某个类，可能需要对它周边的很多类进行冗长的设置。

持续交付：发布可靠软件的系统方法（六）第 6 章 构建与部署的脚本化6.1 引言6.2 构建工具概览6.2.1 Make6.2.2 Ant6.2.3 NAnt 与 MSBuild6.2.4 Maven6.2.5 Rake6.2.6 Buildr6.2.7 Psake6.3 构建部署脚本化的原则与实践6.3.1 为部署流水线的每个阶段创建脚本6.3.2 使用恰当的技术部署应用程序6.3.3 使用同样的脚本向所有环境部署6.3.4 使用操作系统自带的包管理工具6.3.5 确保部署流程是幂等的（Idempoten

从某种抽象层次上讲，部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。对软件的每次变更都会经历一个复杂流程才能发布。这一流程包括构建软件，以及后续一系列不同阶段的测试与部署，而这些活动通常都需要多人或者多个团队之间的协作。部署流水线是对这一流程的建模，在持续集成和发布管理工具上，它体现为支持查看并控制整个流程，包括每次变更从被提交到版本控制库开始，直到通过各类测试和部署，再到发布给用户的过程。

这类测试常常需要很多的资源，比如需要比较特殊的环境来运行测试，并且可能需要专业知识来建立和实现测试，另外它们还通常需要花更长时间来运行（无论这些测试是否是自动化测试）。如果使用测试驱动开发和持续集成，并有一个全面的自动化测试集，其中包括系统级别的验收测试，以及单元测试和组件测试，在测试人员和用户发现缺陷之前，开发人员就应该能够捕获它们。从根本上讲，测试与“完成”的定义是相互关联的，而测试策略应该在对每个功能特性的测试上都体现出这种关联关系，并确保在整个流程之中到处都有测试活动。

界面类测试，简称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。

它也会让运维团队将持续集成作为集中式服务，统筹服务器资源，管理持续集成和测试环境的配置，以确保这些环境的一致性以及与生产环境的相似性，还能巩固一些好的实践，比如第三方库的配置管理，预安装一些工具（用于收集代码覆盖率和质量的统一度量数据。在本地开发环境上运行应用程序时，应确保所使用的自动化过程与持续集成环境中的一致，与测试环境中也是一样的，且生产环境中也是一样的。虽然对于某些团队来说，这已经是非常大的一个进步了，但是，假如能够有一定程度的自动化测试，会让你更有信心说：“我们的应用程序是可以工作的。

对于应用了这些工具的系统来说，根本没必要登录到服务器上去操作，所有的修改都可能通过版本控制系统来发起，因而你也能够得到每次变化的完整记录，即谁在什么时候做了什么样的修改。比如Windows 属性文件的键值字符串就是以不同的heading来组织的，而YAML文件在Ruby领域非常流行，Java中的属性文件虽然在格式上相对简单，但在大多数情况下还是能够提供足够灵活性的。在软件项目中，最常见的外部依赖就是其使用的第三方库文件，以及该软件需要用到的正由其他团队开发的模块或组件间的关系。所有这些都需要考虑。

验收测试是可以自动化的，数据库的升级和降级也是可以自动化的，甚至网络和防火墙配置也是可以自动化的。将构建、部署、测试和发布的整个过程中所需的东西全部保存在某种形式的版本存储库中，包括需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、应用程序所依赖的软件集合的配置脚本、库文件、工具链以及技术文档等。在交付过程中，整个团队应该定期地坐在一起，召开回顾会议，反思一下在过去一段时间里哪些方面做得比较好，应该继续保持，哪些方面做得不太好，需要改进，并讨论一下如何改进。

关于DevOps的书有很多，但不幸的是，大多数都是描述在网站和产品开发中是如何应用DevOps的。很少有相关资料讲述DevOps如何应用于企业体系。企业往往同时拥有交互型系统（SoE）和记录型系统（SoR）。SoE系统关注的是速度，SoR系统关注的是业务连续性。问题是SoR系统也受到面向速度的SoE系统频繁更改的影响，SoR系统如何适应频繁更改影响的同时还要保持业务的连续性？Gartner公司把这称为“双峰挑战”（Bimodal challenge）。

DevOps有自己的起源以及存在的前提。到2010年，随着条件成熟，形成了对信息科技中开发与运维进行管理的需求以及可能性。这引发了DevOps运动的兴起。正如众多布道师经常提及的，DevOps并非包治百病的良药。缩短市场响应时间；减少技术债务；消除信息科技的脆弱性。DevOps构建在精益产品开发和敏捷软件开发两大坚实的基石之上。然而，说DevOps只是采用已有知识是不对的；相反，DevOps不只是扩展了精益产品开发以及敏捷软件开发基石，而且引入了很多重要的新原则。

DevOps 精要:业务视角（五）第5章 应用实践5.1 DevOps适用性及限制5.2 COTS5.3 架构演进5.4 DevOps与ITSM5.5 货物崇拜5.6 从当前所处位置启航，迭代推进5.7 以价值流为核心5.8 小结第5章 应用实践5.1 DevOps适用性及限制也许，前面几章给读者的感觉像是神话，如果参与在内的话就太棒了！自组织团队的员工会被完全激发起来；业务和IT将一同探索如何取悦于挚爱的客户（以及他们的钱）；IT系统将变得牢固并具有反脆弱性；变更与发布将稳定流动，与此同时，技术债务

DevOps 精要:业务视角（四）第4章 关键实践4.1 和传统实践的关键区别4.1.1 发布是日常活动4.1.2 发布是业务决定4.1.3 一切都是自动化的4.1.4 事件要立即4.1.5 缺陷是立即被修复的4.1.6 流程是持续更新的4.1.7 像初创公司一样行动4.2 非同寻常的团队4.3 工作可视化4.4 限制在制品（WIP）4.5 减小批次大小4.6 留意运维需求4.7 尽早检测并修正缺陷4.8 管理的而不是受控的改善和创新4.9 为创新提供资金4.10 任务优先级4.11 持续识别、发掘并评估约

普通员工对工作的日常态度，可以大致定义为下面两个阶段：我在工作和我完成工作了。的确，员工由于他/她们所完成的工作而获得报酬。分析师定义功能需求就算是工作完成了。开发人员写出程序代码就算是实现了整个业务中其所负责的部分。测试人员进行了测试也完成了其所负责的部分，以此类推。然而，在DevOps中，这一切截然不同。有一个关键原则，不是说当有人干完了他/她们那个部分的工作，就可以算是“完成”，而是要等到客户接收到或者开始接收其所预期的价值。如图3.4所示，这意味着整个价值流已经被完整地流经，一直到生产环境；

餐馆里的员工生产同样的菜式的过程，则接近于流水线，根据提供的食谱包括需要的食材列表及烹饪技术，来生产这个产品。Philippe Kruchten（菲力浦·克鲁切顿）2011年在敏捷十周年会议上总结了敏捷想法在最初那些年的表现：“敏捷运动在有些方面有点像一个十几岁的青少年，比如有很强的自我意识，总爱照镜子观察自己的外表，不太愿意接受批评意见，只有兴趣和自己的玩伴在一起，拒绝过去的所有智慧只因为它们来自于过去，喜欢时髦并引入新的术语，有时候显得自大和傲慢。理所当然的是，成功的故事应该被复制。

IT管理方法不是一成不变的。如今，信息系统开发和运维所使用的方法明显区别于几十年前的。这些方法一直在演进，明天可能又会出现下一代基于新的知识、经验和技术的方法。大多数时候，管理方法会基于某些基本的原理和假定，打磨之前已有的模型并使之体系化，逐渐地演进。但是，时不时也会出现一些非连续的情况，个别领先组织在信息技术的有效与高效应用上，已经大步向前迈出了重要的步伐。IT管理从聚焦于IT系统，转变为聚焦于IT服务的管理，就是一个很好的例子。

从ITIL的发展历程不难看出，ITIL的开发初衷确实是以IT基础设施为核心的，并且ITILV2的广泛应用也是聚焦于IT运维领域，但ITIL已经发展到第4个版本，已经超越了对于IT运维业务的管理，在数字化转型下已经可以对整个IT部门的整体业务进行全面管理，以引领组织业务发发展、创造新的商业模式，最终向客户交付的是价值。专家的研究和大量企业实践表明，在IT项目的生命周期中，大约80%的时间与IT项目运营维护有关，而该阶段的投资仅占整个IT投资的20%，形成了典型的“技术高消费”、“轻服务、重技术”现象。

后来，Patrick 又深受 John 和 Hammond的“每日 10 次部署：Dev 和 Ops 在 Flickr 的协作”演讲的鼓舞，于 2009 年在比利时的根特市，举办了第一次 DevOpsDays 活动，创造了“渐变的曲线显示了为什么“一个 30 分钟的简单变更”通常却需要几周的时间才能完成。我们认为 DevOps 正在得益于一场令人难以置信的管理实践大融合，各种实践相互促进和衔接在一起，并形成了一种独特的实践集合，它能对组织的软件开发转型和 IT 产品或服务交付模式的转型产生极大的帮助。

第六部分探讨了如何将 DevOps 原则应用于信息安全，帮助我们实现目标，并确保安全是所有人日常工作的一部分。更好的安全性确保了我们能防护数据、理智地对待数据，能在安全问题酿成灾难以前恢复。最重要的是，我们可以让系统和数据的安全性变得比以往更好。我们已经对 DevOps 的原理和技术实践进行了详细的探讨。在这个安全漏洞频发、交付周期不断缩短、技术大规模转型的时代，在技术领导者们要同时应对安全性、可靠性和灵活性的挑战时，DevOps 应运而生。希望本书能对读者深入理解问题并找到解决问题的方案有所帮助。

无论有意还是无意，组织的领导者都会通过行动来加强组织文化和价值观。审计、会计和道德专家长期以来一直认为，“高层的声音”可能意味着欺诈和其他不道德行径。为了加强学习和评估风险的文化，领导者需要不断强调：每个人都应该坦然面对失败并承担责任，并能够从失败中学习“我和一个同事谈论了 Netflix 刚刚发生的一次大规模服务中断——坦率地说，这是由一个低级错误引发的。事实上，造成此次事故的工程师在过去 18 个月内曾经让 Netflix 宕机两次。然而他是我们绝不会开除的人。

第四部分向我们展示了，通过实施反馈回路，可以让每个人都为实现共同的目标而协作，当发生问题时及时发现问题，并通过快速检测和恢复的机制，保障所有功能不仅能按照设计在生产环境中运行，而且还实现了组织目标和组织学习。我们还研究了如何让开发和运维共享目标，从而提高整个价值流的健康程度。我们即将进入第五部分“第三步：持续学习与实验的技术实践”，以便更早、更快、更廉价地创造学习机会，这样才能打造创新和实验文化，使每个人都通过从事有意义的工作，帮助组织取得成功。

这样，就可以保证服务始终处于“就绪”的状态，即使是在项目的初始阶段，同时还可以从每次发布和生产问题中总结和学习，并将经验用于未来的工作中，从而提高安全性和每个人的生产力。此外，我们还将创造更多的数据使用场景，帮助我们做出更好的决策，实现组织的目标。本章讨论了反馈机制，它使得我们可以在日常工作的每个阶段改进服务，不管是将变更部署到生产环境，在出现问题时请求工程师修复代码，让开发人员跟踪下游工作，建立非功能性需求来帮助开发团队编写更优的生产就绪代码，还是将有问题的服务交回给开发团队自己管理。

然而，Puppet Labs 的《2015 年 DevOps 现状报告》表明，基于主干的开发方式能带来更高的生产力、更好的稳定性，甚至更高的工作满意度和更低的职业倦怠率。然而，如果开发人员长时间工作在自己的分支（也称为“特性分支”）上，只是偶尔将代码合并到主干，那么他们的每一次合并都会为主干引入大批量的变更，这会造成严重的问题。则与之相反，它优化了模块间的依赖关系，提高了生产力和安全性，让小型且高产的“双比萨”团队可以执行小的变更，并能安全和独立地进行部署。仅这些就能使部署团队的工作境遇得到巨大的改善。

然而，单纯地将所有手动测试自动化，可能产生不良后果——谁都不希望自动化测试不可靠或出现误报（即因为代码正确，所以测试本应该通过，可是由于性能不佳、超时、不受控的启动状态，或者因为使用了数据库打桩或共享的测试环境而导致的非预期状态，使得测试失败）。此外，通过把所有生产工件纳入版本控制系统，我们有了“唯一的事实来源”，这使我们能够用快速、可重复和文档化的方式重新搭建整个生产环境，并在运维工作中采用和开发工作一致的实践。部署流水线确保所有检入版本控制系统的代码都是自动化构建的，并在类生产环境中测试过。

通过将运维工程师融入开发团队，他们的工作优先级几乎完全受所在产品团队的目标驱动，而不再专注于解决自己的问题。最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标（例如，将“从提交代码到部署至生产环境”这一过程的前置时间减少 50%）。共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。但在以职能为导向的集中式运维团队里，实现该目标是有挑战的，因为运维团队不得不满足许多开发团队的各种迥然不同的需求。

DevOps 的三步工作法 ：流动、反馈以及持续学习与实验。流动原则 ：它加速了从开发、运维到交付给客户的流程。反馈原则 ：它使我们能建设出更安全可靠的工作体系。持续学习与实验原则 ：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。

devops

devops

nexus

maven

devops

devops