【方法论】持续部署&应用管理实践原创

大家好，我是陈军统，来自腾讯coding团队的解决方案架构师。今天我给大家分享的内容是持续部署与应用管理实践指南，以及基于coding产品的实现与操作演示。今天的课程会分为以下几个部分，在介绍持续部署的基础知识之后，我们会针对复杂度比较高的K部署讲解常用的部署策略，每种策略的具体做法，接着会讲解持续部署的最佳实践能收获的益处。最后一部分是使用coding持续部署与应用管理进行包含两种灰度发布策略的场景化实操演示。今天这个时代，软件开发最大的变化之一就是发布频率了。随着各项新技术与软件开发工具的不断涌现，软件开发的效率得到了巨大的提升，软件发布频率也由传统模式下的数月发布一次变成了每天发布一次，甚至是每天发布多次。

正是在这样的背景下，持续部署的理念应运而生了。在讲解什么是持续部署之前，我们先来看看传统模式下，我们是如何将应用部署到主机或者开发S集群的。在传统模式下，当我们需要将某个装va we应用部署到某台服务器时，往往需要执行以下几个步骤，首先，需要在这台服务器上执行一台install命令来安装comca服务器，安装完以后呢，需要执行另外两台命令，启动comca，并将其设置为一个可以自持控的服务。接下来，我们需要将构建生成的Java wow包拷贝到tomcat的指定目录下，并修改这个wow包的权限。当执行完以上步骤以后，就已经完成了一次主机部署任务了。当服务器数量不多时，部署流程比较简单的时候，这种通过手动执行命令来进行主机部署的方法是没有问题的，但是如果部署流程相对复杂，机器数量比较多的话，这种手动执行命令的方式显然是不可行的。另一方面是这种通过人工执行命令的式很容易出错。另一方面是由于。

每个人的精力都是有限的，无法并发执行这么多台服务器的部署任务，当服务器数量比较多时，总耗时就会很长，导致效率低下。为了解决规模化主机部署所带来的挑战，市面上涌现了很多批量部署的自动化工具，比如any和shift等。以S为例，这是一款自动化运维工具，结合了众多运维工具的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能，可以大大提高部署速度和效率。

我们再来看看在传统模式下，部署一个开S应用时，往往需要手动执行大量的命令。以上就是一些常见的开S命令，这种做法呢，要求操作人员必须熟练掌握KYS的相关命令，因此具有较高的技术门槛。由于每次的部署过程大致相同，因此很多时候都需要反复执行相同的命令，存在大量的重复劳动。为了解决这些问题，市面上涌现了大量的部署工具，而spin就是其中的佼佼者。spin在其官网上对自己给出的定义是多云持续交付平台，重点持有三个多云持续和交付。其中持续一词指的是产品的发布，并不是人工操作或随机的一次性的操作，而是以流水线为载体，可以反复执行的自动化流程。Netflix基于SP一天要部署上万个版本，可见一旦有了好的工具，我们就能稳定、自动和持续的进行发布了。想要真正理解什么是持续部署，我们还需要先理解什么是持续集成和持续交付。持续集成指的是频繁的一天多次将代码集成到主干分支。持续集成强调开发人员提交的新代码之后立刻进行构建单元测试，根据测试结果，我们可以确定新代码和原有代码能否正确的集成在一起。

持续交付是在持续集成的基础上，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。比如我们完成单元测试后，可以把代码部署到连接数据库的sta环境中，以便进行更多的测试，如果代码没有问题，可以继续手动部署到生产环境中。如果我们想要获得持续交付的好处，应该将我们提交的变更尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障，于是便有了持续部署。持续部署是在持续加速的基础上，把部署到生产环境的过程自动化。

在持续部署之后，有个理念也越来越火，那就是get out get out诞生于2017年，是由图中的这个人提出的。随后get out的理念开始慢慢被大众所接受。到了一八年末，各大云厂商纷纷采用get，而get out工作组也在2020年正式成立。到了二一年，Getout成熟度模型诞生了。关于什么是getout，一位工程师给了三曲很精辟的描述，第一句是did as the single source of true of system。意思就是说代码仓库是整个系统的单一可信数据源。第二句是d as the single place where we operate create change and destroy，意思就是说所有的变更活动都围绕着代码仓库来进行，包括创建、修改和销毁等动作。第三句描述是all changes are observable veryfiable，意思就是说所有的变更都是可察觉的、可检验的。除了这三句描述以外，我们还可以用一条公式来定义，这个就是基础设施及代码上合并请求加上持续集成或者是持续部署。

持续部署可以为我们带来很多的好处。第一，降低成本。持续部署流水线允许在非关键业务时间部署，从而限制了部署问题可能造成的潜在影响和损失。此外，在开发阶段，重复的自动化部署可以帮助开发人员在造成任何重大损失之前及早的捕捉错误。这样的流水线实现了提高代码质量，从而提高了企业的整体it投资回报率。

第二点，简化沟通。通过为所有从事同个项目的开发人员、ta和产品经理提供共同的框架，持续部署流水线可以改善团队成员之间的整体沟通和责任感。对于在持续部署环境下运行的每条流水线，所有相关人员都会得到通知，并在同一页面上获知正在进行的任何更改和出现的任何故障。这使得产品所有者和开发人员能够就测试结果进行有效沟通，并根据失败的严重性采取所需的行动。第三点，避免重大事故。在持续部署中，开发人员会逐步添加新代码，他分小块持续进行。在提交之前，开发人员会测试这些更改并记录结果。此外，还有一些系统会持续监视这些新变化，报告问题后，更改会立即恢复。在传统的部署过程中，重要功能作为重大代码更改发布，因此很难确定问题的根源，但是通过持续部署，问题可以很快得到解决，从而避免重大事故。第四点，提高客户满意度。通过持续部署，公司可以快速响应客户的反馈。一旦公司开发的新功能或提供了错误修复，持续部署流程可以帮助其快速触达客户，从而提高客户满意度。

第五，缩短产品的上市时间。持续部署的最显著优势之一是它可以帮助新功能和修复快速进入市场并供客户使用。在竞争日益激烈的环境中，交付时间是衡量成功的关键指标。在传统的手动部署中，在测试、代码审批以及最终为用户发布软件方面会有相当强的延迟。第六点，提高员工队伍的效率。持续部署使软件开发中的大多数普通任务自动化，开发人员不必担心代码是如何集成、部署或者测试的，工程师只需专注于提高工作质量，就可以快速完成一段代码并进行部署，无需等待重大更改。

接下来我们来看看常见的K8S部署策略。我们要介绍的第一种部署策略是停服发布，这种发布方式呢比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成。具体操作方式是先将老版本V1全部下料，再将新版本发布到服务器上去，这种方式会导致服务中断，再开发测试环境是可行的，但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。这种部署策略的优点在于成本较低，缺点在于部署过程需要停止服务，严重影响用户体验。而且如果新版本出现问题，需要进行版本回退的话，需要较长时间才能完成操作。

接下来我们再来看看另外一种名为滚动发布的发布策略。滚动发布一般是取出一个或者多个服务器，停止服务执行更新，更新完毕以后重新将其投入使用，周而复始，直到集群中所有的实例都更新成新版本。滚动发布的优点在于整个发布过程不需要停止服务，用户体验较好，缺点在于由于是逐个升级，因此整个发布流程耗时较长，如果新版本出现问题的话，回馈操作也需要较长时间才能完成。了解完什么是滚动发布以后，我们再来看看什么是蓝绿发布。蓝绿发布是一种通过运行两套环境来减少停机时间和降低风险的技术，可以认为是对停服发布的一种简单优化发布方式。简单的理解就是线上有两套集群环境，在架构图中，一套标记为绿色，称为绿色集群，一套标记为蓝色，称之为蓝色集群。初始状态下，所有流量都会被转到绿色集群。当我们想要发布新版本时，新建一个蓝色集群，当新版本的应用已经在蓝色集群上部署完毕以后，就将流量转到蓝色。

集群，从而完成系统的升级切换。哪类发布的优点在于，由于有两套集群，而且流量都是一次性进行切换的，因此升级和回退操作都能较快完成。缺点在于，由于是流量一次性切换，如果新集讯出现问题，影响面较大。除此之外呢？由于需要两套机器资源，因此成本较高。接下来我们再来介绍一种以鸟类命名的发布策略。没错，可能部分同学已经猜到了，我们将要介绍的这种发布策略就是金丝雀发布。

金丝雀发布是对蓝绿发布的一种简单优化。以前矿工在下矿洞干活之前呢，会先放一只金丝雀进去矿洞，看看金丝雀能否活下来，从而判断矿洞内是否存在有毒气体。我们将要介绍的这种部署策略与矿宫的这种探测手段有着异曲同工之处，因此得名金丝雀发布。金丝雀发布一般先将一小部分流量从绿色集群第一切换到蓝色集群第二，以便在生长环境上对新版本的应用进行测试。简单的金丝雀测试一般通过手工测试验证，复杂的呢，需要比较完善的监控基础设施配合，通过监控指标反馈观察金丝雀环境的健康状况，作为后续发布或者回退的依据。如果金丝穴测试通过，就会将流量从绿色集群第一全部切换到蓝色集群第二，如果金丝雀设置失败，则直接回退金丝雀宣告发布失败。相对于蓝绿发布而言，金丝雀发布的优势是有一个在生产环境的验证过程，可以降低VR可能有问题的风险和影响面。除此之外呢，由于有两套集群，因此无需停止服务就能实现平滑升级，整个发布流程对于用户而言是无感知的。缺点在于，在。

新版本发布的过程中，流量会无差别的被录由到新版本，一旦出现问题，可能会影响那些重要客户的体验，尤其是对于那些对稳定性有着极高要求的客户而言，这种情况必然会给他们造成巨大的损失。而我们将介绍的另外一种发布策略就能很好的避免这种情况，它叫做AB测试。A测试是在线上同时运行多个版本的程序，然后基于用户请求的原信息将流量路由到新版本，换句话说就是可以根据请求内容来动态路由。举个例子，我们可以设置uz a选的值为安卓的请求，来自手机，安卓系统的请求直接路由到新版本，来自其他系统，比如iOS或者终端，比如电脑端的请求呢，仍然路由到旧版本。这么做的好处是可以帮助我们对两个版本进行比较，看看哪个版本的受认可程度更高，用户反馈更好。

AB测试的优点在于我们可以根据请求信息来进行动态路由，实现对特定的用户群体提供新版本的服务，如果新版本出现故障的话呢，影响范围小。缺点在于，由于需要部署多个版本，并且需要一段的时间去观察不同版本的运行情况以及收集用户的反馈信息，因此发布周期会相对较长。接下来，我们再来看看影子部署。影子部署一般用于对那些涉及核心业务的引用系统进行升级改造，例如从do转Java，或者从SQL server数据库迁移到MYSQL数据库等等。具体的实现方式是在旧版本的基础上发布一个新的版本，并将旧版本接收到的所有流量全部进升到新版本，用来测试新版本的稳定性。笼统来说，影子部署可以适用于所有互联网应用。而在以下场景中，影私部署的作用格外明显，第一，调用新系统替换掉老旧系统，第二，系统经历了大规模改造，直接上线，面对客户风险较大，第三，系统更新需要提供向后兼容性，第四，实验性质的架构调整。在以上场景，运用隐私部署可以在不影响终端用户的情况下完成验证与测试。影子部署的优点在于，我们可以使用生产环境的真实流量来对新版本的系统。

进行压力测试，同时呢又保证生产环境的用户不受影响。缺点在于这种部署的技术门槛较高，相关环境的搭建复杂度也比较高。

讲解了这么多种部署策略，我们再来看看他们之间的对比。如这张表格所示，从平复与否、流量测试、目标用户、部署成本、回馈速度、影响面、复杂度等都做了详细的对比。每种部署方式都有其优点和缺点，我们可以根据自己的具体情况选择最适合自己的部署方式。接下来我会给大家介绍一些持续部署方面的最佳实践。第一点最佳实践是安全左移。安全左移是IC开发和Del人员使用的专业术语，用于描述将安全测试和安全技术向软件开发中些上游移动。当前，安全所于已经成为软件行业的共识，因为在软件开发生命周期早期修复漏洞远比在后期进行补救更加省时省力。借助coding平台所提供的代码扫描、视频扫描以及质量红线功能，我们可以尽早发现软件视频中可能存在的各种安全漏洞问题，并及时对其进行处理，从而保证进入到持续部署环节的所有软件制品都是没有安全问题的。

通过实施安全左移的相关策略，可以提高系统的安全性和稳定性，避免生产事故的发生。第二点是只构建一次。在软件开发的过程中，为了保证生产环境的稳定性，我们往往需要创建一些测试环境，用来进行上线前的测试工作。一般的流程是开发人员会提交代码到代码仓库，然后触发相应的持续集成流水线，生成二进制制品，然后执行相应的持续部署流水线，将视频部署到某个测试环境，比如s sit测试环境。那么如果我们在s sit环境测试通过，想要在U环境上执行测试时，我们是否应该重新再进行编译构建操作，然后再将新生成的恶性制制品部署到UV环境呢？这种做法显然是不合适的，因为这样无法保证测试人员在s sit环境测试通过的版本就是用户在u at环境测试的版本，而且还会浪费大家的时间。持续集成应该是一次构建形成的二进制部署包，以后在多数运行。

因此，部署版本不应该反复构建，而是直接用测试通过的部署版本进行u at环境的部署。但是实际应用的部程中，不同环境往往存在不同的配置信息，比如接口、访问地址、数据库、连接信息等，这些信息都和环境相关，因此我们需要将这些跟环境相关的配置从二进制部署包中剥离出来。这样一来，我们在进行环境迁移或者新环境部署时，只需要动态修改这些配置文件即可。这也正是我们这里例举的第三点最佳实践，配置与代码分离。接下来我们再来看看第四点最佳实践，那就是实现全流程自动化。

在传统模式下，当我们想要发布某项功能时，往往需要进行大量的人工操作，比如手动执行单元测试和手动执行部署脚本、将应用部署到服务器等。这些人工操作不仅需要耗费大量的时间，而且还容易因为人为因素导致错误。人与机器的最大区别之一就是在重复性动作上人容易犯错，而机器犯错的几率几乎为零。所以一个更理想的做法是将这些需要人工操作的环节改造成自动化操作，从而实现全流程的自动化。借助coding平台所提供的持续集成指定仓库和持续部署功能，再加上每个功能模块所提供的触发机制，我们可以将不同环节串联起来，从而达到全流程自动化，并最终实现一键部署。第五点是建立及时的消息反馈机制。及时的消息反馈可以确保团队成员及时获得完成工作所需要的所有信息。从开发角度来看，这意味着团队会立即收到所有流水线执行失败的警报，同时这也意味着开发人员能够尽快获得清晰全面的代码测试结果。从运维人员角度来看，这意味着他们可以了解到任何生产环境的故障。借助托运平台所提供的各种系统监控和消息推送功能，我们可以建立一套及时的消息反馈机制，帮助用户及时发现代码中可能存在的安全问题、制品中可能存在的安全漏洞问题以及生产环境中可能出现的故障等，从而推动他们做出快速响应，降低系统的平均修复时间。第六点，最佳时间是一切变更都要实现版本化管理。要实现这个最佳时间，我们需要先实现everything code。

也就是一切级代码，这里就包括pline code流水线及代码、引发structure X code基础设施及代码和policy s code策略及代码等等。通过实现everything s code，我们可以借助coding所提供的代码仓库来记录所有的版本变更信息，从而大大提高我们排查和追溯问题的能力。一旦部署过程中出现任何问题，我们可以通过代码仓库中记录的变更信息快速追溯相应的责任人，并通知相关人员及时处理问题，将损失降到最低。

在详细讲解coding持续部署与应用管理方面的能力之前，我们先来看看coding的能力全景图，如这张图所示，啊，Coding是一站式的dex研发管理平台，涵盖了软件开发生命周期中的各个阶段。在使用coding执行部署任务之前，我们需要先完成号的绑定，左边的截图就是持续部署模块的账号绑定页面。目前coding的持续部署模块支持腾讯云TK javas和腾讯云这三种账号类型，用户可以根据自己的实际情况选择适合自己的账号类型来进行绑定。

绑定完云账号以后，我们需要创建应用和部署流程，左边的截图呢就是创建应用的界面Co CD基于原生的能力来管理部署过程，可以方便的将应用部署于Co和主机组上。右边的截图呢就是我们创建部署流程的界面了，在这里可以看到Co内置的非常丰富的模板，借助这些模板我们可以快速创建一条可运行的部署流水线。这就是Co持续部署模块所提供的可视化流水线编辑器的截图。从截图中可以看到，这是一条用于将应用部署到K8S集群的流水线，用户在编辑这条流水线时不需要编写相关的KS命令，只需要通过可视化菜单选择相应的步骤即可。除了可视化流水线编辑器以外，Coding的持续部署流水线还支持多种触发机制，比如当代码被推送到指定代码仓库时，自动触发流水线，或者是有新的多可镜象被推送到coding多可仓库时，自动触发流水线。除此之外呢，Coing还提供了定时触发器。在传统模式下，当我们想要测试某项功能时，往往需要将代码提交到集成分支，然后通过持续集成流水线对用户提交的代码进行单元测试，测试通过以后呢打包生成相应的视频，最后通过持续部署流水线将视频部署到测试环境。

当项目规模比较大时，完成一次部署任务往往需要较长的等待时间。有一种节约时间的做法是，我们可以设置一个定时出发器，在每天下班后的某个时间点自动触发流水线，将持续提升流水线构建而成的新视品自动部署到我们的测试环境，那么第二天早上当我们来公司上班时，就可以在已经部署好的环境下直接开展测试工作，而不用浪费大家的宝贵时间去等待部署任务的完成。借助coding de boss平台在不同功能模块所提供的多种处罚机制，我们可以实时监听代码以及制品的变更事件，一旦监听到有新的代码提交或者有新的视频被推送时，就自动触发相应的流水线，从而实现一键部署。

此外，Coding还提供了丰富的open API，用户可以很方便的将coding与第三方应用进行集成。以上就是coding持续部署功能的简单介绍，前面我们所介绍的其实是咱们持续部署功能模块的1.0版本，近期呢，Coding会推出一款名为奥的全新产品，这款产品在设计的过程中融合了行业内的先进理念和最佳实现，目的就是为了降低原生时代下应用部署的复杂性，帮助用户实现高效和可靠的发布。前面我们已经讲解过什么是get off，接下来我们一起来看一看如何在coding offs平台上实现get off。首先呢，我们创建两个不同的代码仓库，其中一个用来存储应用程序的代码，另外一个用来存储应用程序的配置文件。之所以将应用程序的代码和配置文件存储在不同的代码仓库，主要是基于两点考虑，第一点是为了实现持续集成和持续交库，我们的CR流水线默认会启用触发器，这个触发器一旦进接到对应程序的源代码有变更，就会自动触发相应的CI流水线。如果我们只是变更了配置的话，则没有必要触发应用程序的CI，因此需要将配置相关的文件存储到一个单独的代码仓库，并关闭相应的触罚规则。第二点是我们修改业务代码的频率会远高于修改配置的频率，如果存储在同一个代码仓库，提交记录会很多很杂，很难进行问题的追溯。接下来我们。

再来看看整个街道工作，有下面讲解的是push的模式，还有另外一种获的模式，因为时间关系就不想拍了。首先开发人员会提交程序代码到Co定代码仓库，这个时候呢，我们会进行代码评审，只有评审通过以后，我们才会将他提交的代码随并到主干分支，一旦有新的程序代码提交到主干分支，就可以自动触发相应的Co顶持续集成流水线，并构建产物推送到Co顶的智敏仓库。这里面是多可镜像，当coding的持续部署模块监定到有新的多可镜像被推送到智敏仓库后，会自动触发相应的持续部署流水线，将新的高可镜像发布到K8S集群。对于运维人员来说，他们将无法像以前一样直接执行命令来操作KS集群，所有的操作都将围绕着代码仓库来进行，比如当运维人员需要修改某项配置时，他需要将更新后的配置文件提交到Co代码仓库。当评审。

通过以后，相应的配置文件将会合并到主干分支，当后建的持续部署模块进行到相应的配置文件有变更以后，才会触发相对应的持续部署流水线。这就是coding新版的应用管理二的截图。二比的一大特点在于它是以应用为中心的，在左上角是用了一个概览，右上方显示的是当前未发布的变更以及已发布的记录，下方则是不同的环境信息，所有重要信息一目了然。此外包支持一键回退功能，支持模板化和版本化。通过整合Co的代码仓库模块，可以实现云资源的代码化管理，所有的变更都可追溯可审计。这是orbi应用中心的截图，在这个页面，我们可以快速的了解到每个应用的最新版本、最近一次的部署时间以及待发布的变更数量等信息。这是office应用监控功能的一个截图，在这个页面我们可以快速的了解到这个应用。

所在服务器的CPU利用率以及内存利用率等信息，从而及时发现可能出现的异常情况。除此之外，呢包还支持自定义告警策略，用户可以自定义触发条件，一旦系统监听到满足相关触发条件的异常情况，就会通过用户配置的通知渠道给用户发送告警信息，从而确保所有异常情况都能得到及时的处理。

这是包比所提供的集群管理功能，通过这个页面，我们可以快速查看每个集群的健康状态。此外，包比支持多款，就是工具的集成，集成完相关的日志工具以后，我们就可以在coding平台上查看相关集群的日志信息，而不需要跳转到其他平台上去查看日志。由此可见，借助coding de boss平台所提供的各项功能，我们的所有工作都能在一个平台上完成，无需跳转到其他平台，大大提高了工作效率。最后，我们让解决方案架构师何文强基于coding持续部署与应用管理，给大家进行包含两种灰度发布策略的场景化实操演示。