接着上篇（https://blog.csdn.net/jinzhengquanqq/article/details/115353649），一起来看看流动的技术实践。
目录
1 部署与发布
将软件发布到生产环境和部署到测试环境是有差异的，这些差异应该被封装在一组配置文件中。部署与发布之间的主要区别在于回滚的能力。测试环境及生产环境的部署与回滚，都应该是部署流水线具体实现中的组成部分。
创建发布策略：创建发布测试的最重要部分是在项目计划阶段就与应用程序的所有干系人会面，讨论关键在于，要对整个应用程序的生命周期中的部署与维护达成共识，然后把这个共识作为发布策略写下来。在整个生命周期中，干系人应该对该文档进行更新和维护。
在项目一开始创建发布策略的第一个版本时，应该考虑下列内容：每个环境的部署和发布都是由谁负责的；创建一个资产和配置管理策略；部署时所用技术的描述，运维团队和开发团队应该对其达成共识；实现部署流水线的计划；枚举所有的环境，包括用于验收测试、容量测试、集成测试、用户验收测试的环境，以及每个构建在这些环境中的移动过程；描述在测试和生产环境中部署时应该遵循的流程；对应用程序的监控需求，包括用于通知运维团队关于应用程序相关状态的API或服务；讨论部署时和运行时的配置方法如何管理，以及它们与自动化部署流水是如何关联在一起的；描述应用程序如何与所有外部系统集成；如何记录日志详情，以便运维人员能够确定应用程序的状态，识别出错原因；制定灾难恢复计划，以便在灾难发生之后，可以恢复应用程序的状态；对软件的服务级别达成一致；生产环境的数量大小及容量计划，应用程序会创建多少数据，需要多少个日志文件或数据库，需要多少带宽或磁盘空间，客户对响应延迟的容忍度是什么？；制订一个归档策略，以便不必为了审计或技术支持而保留生产数据；如何对生产环境进行首次部署；如何修复生产环境中出现的缺陷，并为其打补丁；如何升级生产环境中的应用程序以及迁移数据；如何做应用程序的生产服务和技术支持。
“创建发布策略”这个活动非常有用，它通常会对软件开发人员以及硬件环境的设计、配置和托管提出一些功能需要和非功能需求，当发现这些需求时，也需要将他们加到开发计划中。
发布计划：第一次发布风险最高，需要细致地做个计划，而这种计划活动的结果可能是产出一些文档、自动化脚本或其他形式的流程步骤，用来保证应用程序在生产环境上的部署过程具有可靠性和可重复性。
发布测试包含以下内容：第一次部署应用程序时所需的步骤；作为部署过程的一部分，如何对应用程序以及它所使用的服务进行冒烟测试；如果部署出现问题，需要哪些步骤来撤销部署；对应用程序的状态进行备份和恢复的步骤是什么；在不破坏应用程序状态的前提下，升级应用程序所需要的步骤是什么；如果发布失败，重新启动或重新部署应用程序的步骤是什么；日志文件放在哪里，以及它包括什么样的信息描述；如何应对程序进行监控；作为发布的一部分，对必要的数据进行迁移的步骤有哪些；前一次部署中存在问题的记录以及他们的解决方案是什么。
发布产品：对于商业产品发布还需要考虑以下事情：收费模式；使用许可策略；所用第三方技术的版权问题；打包；市场活动所需的材料；产品文档；安装包；销售和售后支持团队的准备；
1.1 应用程序的部署和晋级
首次向测试环境部署时就应该使用自动化部署，写个简单的脚本来做这件事，而不是手工将软件部署到环境中。
首次部署：项目首个迭代的主要目标之一就是在迭代结束时，让部署流水线的前几个阶段可以运行，且能够部署并展示一些成果。当这个启动迭代结束时，已经有了以下内容：部署流水线的提交阶段；一个用于部署的类生产环境；通过一个自动化过程获取在提交阶段中生成的二进制包，并将其部署到这个类生产环境中；一个简单的冒烟测试，用于验证本次部署是正确的，并且应用程序正在运行。
部署到试运行环境：在用户使用应用程序之前，应该在试运行环境上执行一些最终测试。如果能得到一个容量测试环境，有时也可以跳过试运行步骤，可以用容量测试环境同时做容量测试和试运行。如果应用程序需要与外部系统集成，试运行就是最后一个验证各系统生产版本之间所有集成工作的时机了。项目开始时需要计划的事：确保生产环境、容量测试环境和试运行环境已准备好；准备好一个自动化过程，对环境进行配置，包括网络配置，外部服务和集成设施；确保部署流程是经过充分冒烟测试的；度量应用程序的“预热”时长，如果应用程序使用了缓存，这一点就尤其重要了；与外部系统进行测试集成；如果可能的话，在发布之前就把应用程序放在生产环境上部署好；如果可能的话，在把应用程序发布给所有人之前，先试着把它发布给一小撮用户群；将每次已通过验收测试的变更版本部署在试运行环境中。
部署回滚和零停机发布：当出现问题时，你应该有某种方法恢复服务，以便自己能在正常的工作时间内调试所发现的错误。先要声明两个重要的约束，首先是数据，如果发布流程会修改数据，回滚操作就比较困难；另一个是重要与其他系统集成，如果发布中涉及两个以上的系统，回滚流程也会变得比较复杂。当制订发布回滚计划时，需要遵循两个通用原则，首先，在发布之前，确保生产系统的状态已备份；其次，在每次发布之前都练习以下回滚计划，包括从备份中恢复或把数据库备份迁移回来，确保这个回滚计划可以正常工作。
通过重新部署原有的正常版本进行回滚
零停机发布（也称为热部署），是一种将用户从一个版本几乎瞬间转移到另一个版本上的方法。
蓝绿部署：系统的用户被引导到当前正在作为生产环境的绿环境中。现在我们要发布一个新版本，所以先把这个新版本发布到蓝环境中，然后让应用程序先热身一下，这根本不会影响绿环境。我们可以在蓝环境上运行冒烟测试，来检查它是否可以正常工作，当一切准备就绪以后，向新版本迁移就非常简单了，只要修改以下路由配置，将用户从绿环境导向蓝环境即可，这样蓝环境就成了生产环境，这种切换通常在一秒钟之内就能搞定。如果出了问题，把路由器切回到绿环境上即可，然后在蓝环境中调试，找到问题的原因。
在做这种蓝绿部署时，要小心管理数据库，直接从绿数据库切换到蓝数据库是不可能的，因为如果数据库结构有变化的话，数据迁移要花一定的时间。解决这个问题的一种方法是在切换之前暂时将应用程序变成只读状态一小段时间，然后把数据库复制一份，并恢复到蓝数据库中，执行迁移操作，再把用户切换到蓝系统，如果一切正常，再把应用程序切换到读写方式，如果出了什么问题，只要把它再切回绿数据库就可以了，如果这发生在切成读写方式之前，那么什么额外工作也不需要做，如果应用程序中已经写入了一些你想保留的数据，那么，当再次切换回去之前，你就要找到一种方法可以拿到新记录并把他们迁回到绿数据库中，另外，你还可以找个办法让应用程序的新版本把数据库事务同时发向新旧两个数据库。
金丝雀发布（灰度发布）：在任意时刻，生产环境中只有应用程序的一个版本正在运行，这个假设都是正确的，这会让缺陷补丁以及基础设施的管理更容易一些，然而，这同时也是对软件测试的一种阻碍。即便有稳固且全面的测试策略，还是会在生产环境上发现缺陷。金丝雀发布就是把应用程序的某个新版本部署到生产环境中的部分服务器中，从而快速得到反馈。像蓝绿部署一样，要先部署新版本到一部分服务器上，而此时用户不会用到这些服务器，然后就在这个新版本上做冒烟测试，如果必要，还可以做一些容量测试，最后，你再选择一部分用户，把他们引导到这些新版本上，有些公司会首先选择一些“超级用户”来使用这个新版本，甚至可以在生产环境中部署多个版本，根据需要将不同组的用户引导到不同的版本上。可是金丝雀发布也并不适合所有的情况，对于那些需要用户安装到其自己环境中的软件来说，这么做就比较困难，对于这个问题，有另一个解决方案，那就是让客户软件或桌面应用程序自动从设置的服务器上拿到新版本并自动升级。金丝雀发布在对数据库升级以及其他共享资源方面引入了更进一步的约束，即任何共享资源要能在生产环境中的所有版本中相兼容，另一种方法是使用非共享架构，即每个节点与其他节点绝对独立，不共享数据库或外部服务，也可以将两种方法结合使用。最后，在生产环境中保留尽可能少的版本也是非常重要的，最好限制再两个版本之内，支持多个版本是非常痛苦的，所以要将金丝雀的数目减少到最低限度。
紧急修复：任何情况下，都不能破坏流程，紧急修复版本也要走同样的构建、部署、测试和发布流程。
真正执行部署操作的人应该参与部署过程的创建，记录部署活动，不要删除旧文件而是移动到别的位置，部署是整个团队的责任，不要直接对生产环境进行修改
2 提交阶段
当向版本控制库的一次提交时，提交阶段就开始了，当它结束时，你要么得到失败报告，要么得到后续测试和发布阶段可用的二进制产物和可部署程序集，以及关于当前应用程序状态报告，理想情况下，提交阶段的运行应该少于5分钟，一定不会超过十分钟。
2.1 提交阶段的原则和实践
提交阶段的目标是在那些有问题的构建引起麻烦之前，就把他们拒之门外，要么创建可部署的产物，要么快速失败并将失败原因通知给团队。
提交快速有用的反馈：提交测试无论是什么原因导致了失败，提交测试一结束，就要通知开发人员，并提供简明的失败原因报告，比如失败测试的列表，编译错误或其他错误清单，开发人员还应该可以很容易地拿到提交阶段运行时的控制台输出，即使提交阶段在多台机器上运行。引入错误后，越早发现它，就越容易修复它。提交阶段是第一个将质量视角从个体开发扩大到更多人的正式步骤，提交阶段的第一件事就是把提交者的修改与主线合并，然后对集成后的应用程序执行某种自动化的“验证”。只有在某个错误让提交阶段的其他任务无法执行时，我们才会让提交阶段停下来，比如编译错误，否则就直至提交阶段全部运行完后，才汇总所有的错误和失败报告，以便可以一次性地修复它们。
何时令提交阶段失败：出现编译错误、测试失败，或者环境问题，否则就应该让提交阶段成功通过并报告一切OK，代码覆盖率和其他度量项，这些信息可以使用一系列阀值聚合成一个“交通信号灯”（红、黄、绿），或者浮动的衡量标度，比如，当单元测试覆盖率低于60%就令提交阶段失败，高于60%就通过。
精心对待提交阶段，让开发人员也拥有所有权，在超大项目团队中指定一个构建负责人。
提交阶段的结果：与部署流水线的所有阶段一样，提交阶段即有输入，也有输出，输入是源代码，输出是二进制包和报告，产生的报告包括测试结果（假如测试失败，这些结果是找出哪里出了错的重要信息）和代码库的分析报告。分析报告可能包括测试覆盖率、圈复杂度、复制/粘贴分析、输入和输出耦合度以及其他有助于建立健康代码库的度量项，提交阶段生成的二进制包应该在该部署流水线的实例中一直被重用，而且最后还会发布给用户。
理想情况下在部署流水线中成功走向生产环境的每一步：交付团队的某个提交了一次修改；持续集成服务器运行提交阶段；成功结束后，二进制包和所有报告和元数据都被保存到制品库中；持续集成服务器从制品库中获取提交阶段生成的二进制包，并将其部署到一个类生产测试环境中；持续集成服务器使用提交阶段生成的二进制包执行验收测试；成功完成后，该候选发布版本被标记为“已成功通过验收测试”；测试人员拿到已通过验收测试的所有构建的列表，并通过单击一个按钮将其部署到手工测试环境中；测试人员执行手工测试；一旦手工测试也通过了，测试人员会更新这个候选发布版本的状态，指示它已经通过手工测试了；持续集成服务器从制品库中拿到通过验收测试的最新候选发布版本，将其部署到生产测试环境；对这个候选发布版本进行容量测试；如果成功了，将这个候选版本的状态更新为“已通过容量测试”；如果部署流水线中还有后续阶段的话，一直重复这种模式；一旦这个候选发布版本通过了所有相关阶段，把它标记为“可以发布”，并且任何被授权的人都能将其发布，通常是由质量保证人员和运维人员共同批准；一旦发布以后，将其标记为“已发布”。
提交测试套件的原则与实践：提交测试中，绝大部分应由单元测试组成，单元测试最重要的特点就是运行速度非常快。设计能快速运行的提交测试策略：将指定测试的范围最小化，并让它尽可能聚焦于系统的某个方面，尤其要注意的一点是，运行的单元测试不应该与文件系统、数据库、库文件、框架或外部系统等打交道。所有对这些方面的调用都应该用测试替身代替。提交测试阶段避免使用用户界面，使用依赖注入，避免使用数据库，在单元测试中避免异步，单元测试中可以使用测试替身，最少化测试中的状态，也可以将时间进行伪装。
3 持续集成
每当提交到版本控制系统的代码变更导致部署流水线失败时，我们就会群策群力地解决问题，力求尽快将部署流水线恢复到绿色状态，然而，如果开发人员长时间工作在自己的分支上，只是偶尔将代码合并到主干，那么他们的每一次合并都会为主干引入大批量的变更，这会造成严重的问题。解决大批量合并问题的对策是，应用持续集成和基于主干的开发实践，让每个开发人员每天都至少向主干提交一次代码。这样做能够将代码提交质量降低为开发团队每日的工作量，开发人员提交得越频繁，每次的提交量就越小。
持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合，至关重要的是，假如构建或测试过程失败，开发团队就要停下手中的工作，立即修复它，持续集成的目标是让正在开发的软件一直处于可工作状态。
3.1 实现持续集成
准备工作：
版本控制：包括产品代码、测试代码、数据库脚本、构建与部署脚本，以及所有用于创建、安装、运行和测试该应用程序的东西。
自动化构建：人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程。
团队共识：持续集成不是一种工具，而是一种实践，需要开发团队能够给予一定的投入并遵守一些准则，需要每个人都能以小步增量的方式频繁地将修改后的代码提交到主干上，并一致认同“修复破坏应用程序的任意修改是最高优先级的任务”。
一个基本的持续集成系统：当你选择并安装好持续集成工具之后，只要在花几分钟的时间配置一下就可以工作了，这些配置包括让它知道到哪里寻找源代码控制库，必要时运行哪个脚本进行编译，并执行自动化提交测试，以及一旦最新的提交破坏了应用程序，通过哪种方式通知你。准备好要提交最新修改代码时，清遵循如下步骤：查看一下是否有构建正在运行。如果有的话，你要等它运行完，如果它失败了，你要与团队中的其他人一起将其修复，然后再提交自己的代码；一旦构建完成且测试全部通过，就从版本控制库中将该版本的代码更新到自己的开发环境上；在自己的开发机上执行构建脚本，运行测试，以确保在你机器上的所有代码都工作正常；如果本地构建成功，就将你的代码提交到版本控制库中；然后等待包含你的这次提交的构建结果；如果这次构建失败了，就停下来，在自己的开发机上立即修复这个问题；如果这次构建成功，你可以小小地庆祝一下，并开始下一项任务。
3.2 持续集成前提条件
频繁提交：对于持续集成来说，最重要的工作就是频繁提交代码到版本控制库。
创建全面的自动化测试套件：持续集成构建中使用三类测试，它们分别是单元测试、组件测试和验收测试。单元测试用于单独测试应用程序中某些单元的行为（比如一个方法、一个函数、或一小组方法或函数之间的交互）；组件测试用于测试应用程序中几个组件的行为；验收测试的目的是验证应用程序是否满足业务需求所定义的验收条件，包括应用程序提供的功能，以及其他特定需求，比如容量、有效性、安全性等，验收测试最好采用整个应用程序运行于类生产环境的运作方式。
保持较短的构建和测试过程：有时候需要将测试分成几个阶段，首先将其分成两个阶段，第一个阶段用于编译软件，运行所有类级别的单元测试，并创建用于部署的二进制文件，这个阶段叫提交阶段，第二个阶段应该利用第一个阶段所生产的二进制文件进行验收测试、集成测试，假如你有性能测试的话，也要一并运行。一旦提交测试套件通过了，就要马上运行验收测试的第二个阶段，另外，有时候把一个简单的冒烟测试套件加入到提交阶段，也是非常有用的，这个冒烟测试套件应该执行一些简单的验收和集成测试，用于确保最常见的功能没有被破坏。
管理开发工作区：在本地开发环境上运行应用程序时，应确保所使用的自动化过程与持续集成环境中的一致，与测试环境中也是一样的，且生产环境中也是一样的。达到这一目标的第一个先决条件就是细心的配置管理，不仅仅是管理代码，还包括测试数据、数据库脚本、构建脚本和部署脚本，这些全部都要放在版本控制库中，且当编码开始时，应该以它们“最新的正确版本”作为起点。“最新的正确版本”是指那个在持续集成服务器上最近一次通过所有自动化测试的那个版本。确保是对第三方依赖的配置管理，即那些开发中所用的库文件和组件，应确保库文件或组件的版本都是正确的，即阿门的版本与你正在开发的源代码的版本是相互匹配的。
3.3 必不可少的实践
持续集成是一种实践，不是一个工具，它的有效性依赖团队纪律，要让持续集成系统能够发挥作用，尤其是面对一个大型复杂的持续集成系统时，整个开发团队就必须有高度的纪律性，持续集成系统的目标是，确保软件在任何时候都可以工作。
构建失败之后不要调新代码；提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事；等提交测试通过后再继续工作；回家之前，构建必须处于成功状态；时刻准备着回滚到前一个版本；在回滚之前要规定一个修复时间；不要将失败的测试注释掉；为自己导致的问题负责；测试驱动开发
3.4 推荐的实践
极限编程开发实践；若违背架构原则，就让构建失败；若测试运行变慢，就让构建失败；若有编译警告或代码风格问题，就让测试失败
参考书《DevOps实践指南》，《持续交付发布可靠软件系统方法》
7164
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
