自动化持续部署是业界最佳实践，以此为目标，优化IT模型。 在我接触过的很多公司中，在持续部署的实践中还存在很多不足之处。基本上部署靠人，更谈不上自动化。我一直强调，持续部署是IT交付的核心能力。直接关联多个研发/测试和运维团队，可以成为运维的核心平台。自动化部署能力的高低可以映射出很多方面的IT能力，比如流程/环境管理/服务耦合/平台能力等。 我做了三个持续部署系统，每个持续部署系统都有给整个IT团队带来了巨大的收益。当我带着这些经历回去看这本书《持续交付》时，我被书中的很多观点所触动，基本上每一点都有我自己的感受。 一起来看看《持续交付》中总结出的诸多错误模式。这些错误模式在现实中确实存在，必须避免。它们被称为反模式。详情如下： 1.反模式模式一：手动部署软件 对于当今的大多数应用程序，无论大小，部署过程都非常复杂，包含许多非常灵活的部分。许多组织手动发布软件，这意味着部署应用程序所需的步骤是由单个人或组单独执行的独立原子操作。每一步都有需要人为判断的东西，所以很容易出现人为错误。即使不是这样，这些步骤的顺序和时机也会导致结果的差异，而这种差异很可能给我们带来不好的后果。这个反模式的特点如下： ◆有一个非常详细的文档，描述了执行步骤和每个步骤中容易出错的地方。 ◆手动测试以确认应用程序正常工作。 ◆开发团队在发布当天经常接到客户的电话，要求解释部署出错的原因。 ◆发布时，经常会修复发布过程中发现的一些问题。 ◆如果部署在集群环境中，经常会发现集群中各个环境的配置不一样，比如应用服务器的连接池设置不一样或者文件系统目录结构不一样. ◆发布过程耗时较长（几分钟以上）。 ◆发布结果不可预测，经常要回滚或遇到不可预见的问题。 ◆发布后的凌晨两点，困倦地坐在显示器前，绞尽脑汁想着如何让刚刚部署的应用正常运行。 相反，随着时间的推移，部署应该走向完全自动化，即负责将应用程序部署到开发、测试或生产的人员应该只做两件事：（1）选择要部署的版本和环境;(2)单击“部署”按钮。对于打包的软件版本，还应该有一个创建安装程序的自动化过程。 当然，并不是每个人都热衷于这个想法。那么，让我们首先解释一下为什么自动化部署被认为是一个基本目标。 ◆如果部署过程不是完全自动化，每次部署都会出错。唯一的问题是“问题严重与否”。即使进行了良好的部署测试，一些错误也很难追踪。 ◆如果部署过程不是自动化的，那么它既不可重复也不可靠，并且会浪费大量时间来调试部署错误。 ◆必须记录手动部署过程。但文档维护是一项复杂且耗时的工作，涉及多人协作，所以文档通常不是不完整就是没有及时更新，而一套自动化部署脚本作为文档，永远不会是up-to-日期和完成，否则部署将无法进行。 ◆自动部署在本质上也鼓励协作，因为所有内容都在一个脚本中，一目了然。理解文档通常需要读者具备一定程度的知识。然而实际上，文档通常只是为执行部署的人编写的备忘录，其他人很难理解。 ◆以上几点的推论：人工部署过程依赖于部署专家。如果专家休假或离职，你就有麻烦了。 ◆虽然手动部署繁琐且重复性高，但仍然需要相当程度的专业知识。请专家来做这些枯燥、重复但对技术要求很高的任务，势必会引入我们可以预料到的各种人为错误，随之而来的是失眠和酗酒等问题。而自动化部署则可以将那些高成本的高级高科技人员从过度劳累中解放出来，让他们投入到更高价值的工作活动中。 ◆测试手动部署过程的唯一方法是恰好执行一次（或多次）。这通常既费时又费钱，而测试自动化既便宜又易于部署。 ◆此外，还有一个论点：自动化流程不如人工流程可审计。我们对这种观点感到困惑。对于一个手工流程，没有人能确定它的执行者会非常严格地按照文档来完成操作。只有自动化流程是完全可审计的。有什么比有效的部署脚本更容易审计的呢？ ◆每个人都应该使用自动化部署流程，这应该是部署软件的唯一方式。该指南确保在需要部署时，部署脚本会完成这项工作。我们会提到几个原则，其中之一是“使用相同的脚本将软件部署到各种环境”。如果您使用相同的脚本将软件部署到不同的环境，到发布日部署到生产环境时，该脚本已经被验证了数百次。如果您在发布时遇到任何问题，您可以100%确定这是环境的特定配置问题，而不是脚本。 当然，手动密集型发布有时会非常顺利。有没有可能是不好的情况恰好发生在我们身上？如果不是整个软件生产过程中容易出错的步骤，为什么总是这么严重呢？为什么需要这些流程和文件？为什么团队要在周末加班？为什么要求大家随时待命，以防万一？当软件首次部署到类似生产的环境（例如暂存环境）时，即大部分开发工作已完成，至少在开发团队认为“软件已完成”时。在这种模式下，经常会出现以下情况： ◆如果测试人员在此之前已经参与过流程，那么他们已经在开发机器上测试了软件。 ◆只有在部署到staging环境时，运维人员才会第一次体验到新的应用。在一些组织中，单独的运营团队通常负责将应用程序部署到暂存和生产环境。在这种工作方式下，操作员只有在产品发布到生产环境时才第一次看到软件。 ◆可能类生产环境非常昂贵，所以权限控制严格，运营商无权操作环境。也有可能环境没有按时准备好，甚至根本没人准备环境。 ◆开发团队将正确的安装程序、配置文件、数据库迁移脚本和部署文档移交给实际执行部署任务的人员，所有这些都无需在类似生产或暂存环境中进行测试。 ◆开发团队与实际执行部署任务的人员之间的协作很少。 每当需要将软件部署到暂存环境时，都会组建一个团队来完成任务，有时是一个功能齐全的团队，但是在大型组织中，此部署的责任通常落在一个单独的团队的肩上。#p# 将应用程序部署到暂存环境后，我们经常会发现新的错误。不幸的是，我们通常没有时间修复所有问题，因为截止日期临近，而且在项目的这个阶段，推迟发布日期是不可接受的。因此，大多数关键错误都被匆忙修复，项目经理保留一份已知错误列表只是为了安全起见，但是当下一个版本开始时，这些错误通常仍然是低优先级的。 有时甚至比这更糟糕，以下事情会加剧与发布相关的问题： 如果应用程序是全新的，第一次将其部署到暂存环境，可能会非常棘手。 ◆发布周期越长，开发团队在部署前做出错误假设的时间就越长，修复这些问题的时间也就越长。 ◆在那些将交付流程划分为开发、DBA、运维、测试等部门的大型组织中，各部门之间的协作成本可能非常高，有时甚至会把发布流程拖到“地狱列车”。此时为了完成一个部署任务（或者更糟的是，为了解决部署过程中出现的问题），开发人员、测试人员和运维人员总是举着问题单（不断地互相发邮件）。 ◆开发环境和生产环境的差异越大，开发时的假设和现实的差距就越大。很难量化，但我敢说，如果你在Windows系统上开发软件，最终部署在Solaris集群上，那么你会遇到很多意想不到的事情。 ◆如果应用是用户自己安装的（你可能没有太多的权限去操作用户的环境），或者其中的某些组件不在企业的控制范围内，此时可能需要大量额外的测试工作。 3.反模式三：生产环境的手工配置管理 很多机构通过专门的运维团队来管理生产环境的配置。如果需要修改，比如修改数据库的连接配置，或者增加应用服务器线程池的线程数，团队会登录生产服务器进行手动修改。如果记录了这样的修改，则相当于变更管理数据库中的一条记录。这种反模式的特点如下： ◆部署到staging环境很多次都非常成功，但是部署到生产环境的时候就失败了。 ◆集群中的每个节点都有不同的行为。例如，一个节点可能比其他节点承受更少的负载或花费更多的时间来处理请求。 ◆运维团队每次发布都需要很长时间准备环境。 ◆系统无法回滚到之前部署的配置，包括操作系统、应用服务器、关系数据库管理系统、Web服务器或其他基础设施设置。 ◆我不知道从什么时候开始，集群中的一些服务器使用了不同的操作系统、第三方基础设施、依赖库版本或补丁级别。 ◆直接在生产环境上修改配置，改变系统配置。 运维的关键实践之一是配置管理，其职责之一是使您能够迭代地创建您开发的应用程序所依赖的每一个基础设施。这意味着操作系统、补丁级别、操作系统配置、应用程序依赖的其他软件及其配置、基础设施的配置等都应该受到控制。您应该能够重建生产环境，最好以自动化方式重建。 我们还应该能够在部署出错时通过相同的自动化流程将系统回滚到以前的版本。 4.问题答案：自动部署 实现一个完整的自动化构建、部署、测试和发布系统。为了让这个系统运行良好，我们也帮助他们采用了一些必要的开发实践和技术（为大系统做小系统/维度服务/灰度能力等）。如何使用部署流水线，将高度自动化的测试部署与完善的配置管理相结合，实现一键式软件发布。也就是说，只需单击鼠标，即可将软件部署到任何目标环境，包括开发、测试或生产。 ————————以上几点摘自《持续交付》 常见的三种看法： 1。自动化脚本封装，使用expect+ssh； 2。使用配置管理工具来实现; 3.在Jenkins中写一个插件来实现。 但我还是觉得这不是我想要的可视化+自动化部署系统，一般都会选择自己实现。 1.YY包部署系统 缺点： A、对配置管理的支持不太好 B、环境管理能力弱 C、不按应用维度管理 2。UC的持续部署系统 是基于公司的另一个系统修改的。支持游戏业务的特殊发布场景，做了一些优化，但还存在一些不足。 缺点： A.应用程序与底层Agent的耦合度过高，Agent的异常会影响应用程序的工作。 B.系统架构设计非常复杂，涉及的组件太多，基于CF进行修改。 C.基于CF的PaaS平台每支持一种语言就需要重新开发。 D.封装的抽象能力不够，管理能力需要封装在Agent层。当然，这个能力可以在更高的层面上实现，兼容各种运营场景。 3.新的持续部署系统（doing） 基于包的新抽象，支持各种语言；向用户开放包管理能力，适应各种场景；支持包/配置/环境的可视化管理；支持灰度，支持快速回滚....等等。
