共计 10607 个字符，预计需要花费 27 分钟才能阅读完成。
作者：郝阔君
GrowingIO QA Leader，曾任职于中国惠普、奇虎 360。率领 QA 团队负责 GrowingIO 全产品线质量保证工作，目前专一于 DevOps 实际，帮忙团队晋升品质和效率。
目标
本文次要形容 GrowingIO 过来在 SaaS 产品线上 CI/CD 的一些实际。因为历史起因公司应用的局部工具链比拟小众，以后的 CI/CD 的流程还有很大的改良空间，然而一些实践经验还是有肯定借鉴意义的。
什么是 CI/CD
CI/CD 是一种通过在利用开发阶段引入自动化来频繁向客户交付利用的办法。CI/CD 的外围概念是继续集成（Continuous Integration）、继续交付（Continuous Integration）和继续部署（Continuous Integration），业界对 CI/CD 了解如下。
CI 继续集成（Continuous Integration）
继续集成是一种开发实际，在继续集成环境中，开发人员将会频繁地向骨干提交代码，这些新提交的代码在最终合并到骨干前，须要通过编译和自动化测试流进行验证。
继续集成是在源代码变更后自动检测、拉取、构建和（在大多数状况下）进行单元测试和动态品质剖析的过程。
继续集成的指标是疾速确保开发人员新提交的变更是好的，并且适宜在代码库中进一步应用。CI 的流程执行和实践实际让咱们能够确定新代码和原有代码是否正确地集成在一起。
CD 继续交付（Continuous Delivery）
实现 CI 中构建及单元测试和集成测试的自动化流程后，继续交付可主动将已验证的代码公布到存储库。为了实现高效的继续交付流程，务必要确保 CI 已内置于开发管道。继续交付的指标是领有一个可随时部署到生产环境的代码库。
在继续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都波及测试自动化和代码公布自动化。在流程完结时，运维团队能够疾速、轻松地将利用部署到生产环境中或公布给最终应用的用户。
CD 继续部署（Continuous Deployment）
对于一个成熟的 CI/CD 管道（Pipeline）来说，最初的阶段是继续部署，继续部署能够主动将利用公布到生产环境。
继续部署意味着所有的变更都会被主动部署到生产环境中，然而出于业务思考，能够抉择不部署。如果要施行继续部署，必须先施行继续交付。
继续交付并不是指软件每一个改变都要尽快部署到产品环境中，它指的是任何的代码批改都能够在任何时候施行部署。继续交付示意的是一种能力，而继续部署示意的则是一种形式。继续部署是继续交付的最高阶段。
如何实现 CI/CD
实现一套 CI/CD 流程次要有以下几种路径：
1. 购买现成的产品或服务
很多成熟的产品都提供欠缺的 DevOps 性能，如 Atlassian、微软的 Azure DevOps、阿里的云效、coding.net 等等。如果是全新的初创公司能够抉择购买适合的产品和服务，能够借助 DevOps 产品提供的工具和最佳实际，疾速搭建起一套欠缺的 DevOps 体系。很多 DevOps 服务都是跟云厂商集成的，如果曾经应用了对应的云服务产品，再应用对应的 DevOps 服务其老本并不高。
2. 将现有的一些工具集成起来
这是目前少数公司最常见的一种做法，将公司外部的项目管理，代码治理，制品治理等工具集成起来，或做一些简略的二次开发实现一套残缺的 CI/CD 流程。这种形式总体老本可控，利用现有的基础设施进行革新，不便灵便，能够依据公司本人的流程来定制。
少数公司都是采纳这一种形式，因为少数公司创建之初，必然是先生存后倒退，并不会把工程效率放在第一位，会选用一些独自的工具（如代码治理）解决某一畛域的问题。随着公司倒退才会更多的思考工程效率，此时将现有工具集成起来显然是最常见的抉择，GrowingIO 也不例外。
3. 应用一些开源的 DevOps 平台
目前也有一些开源产品，曾经基于各种开源产品做了二次开发集成，造成了残缺的 DevOps 平台，如猪齿鱼。如果不想购买云服务，又不想做二次开发，能够尝试此类工具。
不过值得注意的是，应用开源工具的资源投入并不一定会少，尤其是呈现问题须要解决，或者说工具不能满足本身须要时须要二次革新，都须要对工具进行深刻的钻研和理解，所以抉择这类产品也要思考是否与公司以后的技术栈匹配，是否有能力进行保护。
4. 本人设计开发实现
本人新造轮子，重头开始设计开发实现一套。显然这种形式是投入老本最高的，但也是最灵便，最能合乎企业本身须要的，个别都是一些特大型的企业才会破费资源来研发。比方下面第一种提到的一些云服务产品起初都是企业外部本人研发应用，成熟当前作为产品对外提供服务，从而获取更多经济回报。
应用的工具
工欲善其事必先利其器，要实现一个经济高效的 CI/CD 流程抉择适合的工具能够实现事倍功半的成果。一个典型的 CI/CD 流程建设至多须要具备以下性能的工具。
- 代码存储库，即须要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库
- 继续集成服务器，用于主动执行构建，测试，部署等工作
- 集中的制品治理仓库，用于寄存构建的成绩物，用于部署
- 主动部署工具，用于将构建到的程序主动的部署到指标服务器
代码治理 Phabricator
GrowingIO 成立之初就抉择了私有化部署 Phabricator 作为开发合作工具，Phabricator 是一款与 GitHub、GitLab 等相似的弱小的软件开发合作工具，其反对 Git、Mercurial、Svn 三种代码仓库托管、代码 Review、命令行工具、工作治理、看板、Wiki、主动规定，WebHook 和 API 等多种性能。
继续集成服务器 Jenkins
目前能够实现继续集成的自动化工具有很多，其中最风行开源工具莫过于 Jenkins。Jenkins 反对多种工作类型，1000+ 插件，社区和生态都比较完善。Jenkins 2.0 版本提供了 Pipeline as Code 的个性，能够将 CI/CD Pipeline 的定义纳入版本治理，反对 GitOps。此外，Jenkins 反对多种形式实现的主从架构，其中借助 Kubernetes 弱小的编排和调度能力而实现的主从模式，能够实现从节点的动态创建和销毁，极大的晋升了 CI 执行效率和资源利用率。
品质治理平台 SonarQube
SonarQube 是一款代码品质治理平台，通过 SonarQube 能够检测出我的项目中潜在的 Bug、安全漏洞、代码标准、反复代码、不足单元测试等代码品质问题，并提供了 UI 界面进行查看。能够通过管制相干代码质量指标的阈值，放弃和晋升代码品质。应用 SonarQube 收费的社区版，就曾经能够满足绝大多数的我的项目需要，而且它还很容易跟第三方的 CI/CD，Code Review 工具集成。
制品库治理 Nexus
Nexus 是 Sonatype 开发的一款制品仓库管理工具，反对 Maven，NPM，PyPI，Docker，Helm 等数十种制品的治理，此外他还反对 Webhook，REST API 能够很不便的与第三方工具集成。Nexus 的收费的开源版本（即 Nexus Repository OSS）所提供的性能曾经能够满足咱们的绝大多数需要。
部署工具 Capistrano
Capistrano 是一款 Ruby 语言实现的，收费开源的近程服务器自动化管理工具。Capistrano 是基于 SSH 的免代理模式运行的，只须要装置一个客户端即可轻松的实现多台服务的治理。Capistrano 提供了一套用于部署和回滚的 DSL 和工作流，能够很容易的实现服务的近程主动部署和回滚。同时还能够很容易通过自定义插件或脚本扩大性能，实现个性化需要。
此外除了以上工具还应用了 Kubernetes，Docker 等工具。这里提到工具所提供的性能都有很多其余的代替计划，须要依据公司具体的技术栈，以后应用工具，工程实际，部署形式等多种因素抉择。
源代码管理策略
源代码治理作为 CI/CD 的终点，会与 CI/CD Pipeline 深度的集成，不同的代码分支策略会影响 CI/CD Pipeline 的设计实现，所以在开始设计 CI/CD 之前必须依据公司以后的合作流程设计好分支管理策略。
Git 分支治理的计划有很多，他们各有优缺点，都有各自的试用场景，其中比拟闻名的有 git-flow、trunk-based、github-fow，各个企业也会自定制本人的分支策略，如阿里巴巴的 AoneFlow。
GrowingIO 偏向于应用 Trunk-based 的分支策略，其最现实状态的是「骨干开发，骨干公布」，要做到这一步对代码开发的品质要求相当高。
目前公司的开发实际还无奈达到这样的要求，所以退而求其次应用「分支开发，骨干公布」，当分支生命周期很短时，根本不会产生代码合并抵触，就根本等同于骨干开发。在骨干分支呈现 Bug 影响公布的时候也会长期采纳分支公布的策略。
分支阐明
Master 分支
Master 分支是最新的代码集成骨干分支，同时是公布（Release）分支，个别当代码通过充沛测试后能力进入到 Master 分支，Master 分支是随时可公布状态。
该分支禁止间接 git push，必须通过提交批改 Diff（等同于 Github 的 PR，Gitlab 的 MR，是 Phabricator 中进行代码 Review 的单元），通过 Code Review 和测试验收后，能力合并。
Release 分支
Release 分支是一个长期分支，次要是为了解决有些状况下 Master 分支不满足上线条件然而又须要紧急上线的时候应用。
例如上线过程中发现某一个批改引入了比较严重的 Bug，为了不影响其余批改的失常公布，通常会将有问题的 Commit 剔除掉，而后创立一个长期分支持续公布。
Feature 分支
性能开发分支或集成测试分支，是开发过程中最沉闷的分支，每次提交到该分支的代码都会被集成。在微服开发模式下，开发人员很难在本地搭建残缺的集成环境，因而须要云端的集成测试环境来帮忙开发实现联调测试。
如果在代码进入骨干分支之前通过集成测试，QA 验收，和产品验收，无疑会大大降低代码进入骨干分支的危险。当然要保障 Feature 分支的生命周期足够短，这样能够大大的防止代码合并抵触。
Trunk-based 拥护应用长生命周期的 Feature 分支，激励应用个性开关和形象分支技术来尽快的合并代码到骨干分支，同时又不影响骨干分支性能。
Local 分支
开发者本地分支，之所以是本地分支是因为 Phabricator 容许在不创立近程分支的状况下提交 Diff 进行代码 Review 和部署。
开发分支的代码通过本地调试和单元测试后会基于骨干（Master 分支）或 个性分支（Feature 分支）提交 Diff 进行 Code Review，Review 通过后进入对应的 Base 分支。
Feature 开发流程
通常要实现一个比拟大的 Feature 须要数据端多个组件，服务端多个微服务以及前端协同开发能力实现。EM（工程经理，Engineer Manger）在 Sprint 打算时将 Feature Ticket 拆分成多个子工作，交由不同的开发来实现。
- 各个模块的开发人员，从 Master 创立 Feature 分支，并推送到近程，如下图的 Feature 1 分支
- 对应模块的开发人员，从 Feature 分支创立一个本地开发分支，用于实现一个子工作，多个开发同时在一个代码仓库工作时能够各自创立本人的本地分支，如下图的 Dev1，Dev2 分支
- 开发人员在本地开发调试，并执行单元测试通过后，提交 Diff 进行 Code Review (CR)，如果 CR 不通过则批改代码更新 Diff 直到 CR 通过后合并到 Feature 1 分支，而后删除本地的开发分支，如下图的 Dev1 分支。当另一个开发实现本地开发须要提交 Diff 时，要先 Rebase Feature 分支，而后提交 Diff，通过 CR 后合并进入到 Feature 1 分支，并删除本地分支，如下图 Dev 2 分支。当须要在 Feature 1 分支持续实现新性能或批改 Bug 时，从新创立一个本地分支
- Feature 分支的代码会部署到对应的集成测试环境，供多端开发人员进行联调测试
- Feature 分支联调通过后，在基于 Master 分支再提交一个 Diff，而后提交 QA 测试，QA 测试通过后合并进入 Master 分支，删除对应的 Feature 分支
- 如果代码仓库的一个 Featrue 分支只有一位开发人员工作，能够间接 push，如 Featrue 2 分支，当代码通过集成测试后再提交 Diff 进行 Coded Review，CR 通过后进入骨干分支。不过即便只有一个开发人员也倡议应用提交 Diff 的形式向 Feature 分支提交代码，避免最初提交的的 Diff 过大，不利于 CR
TIPS： 每次提交 Diff 之前都应该与近程 base 分支进行 Rebase 或 Merge 操作，避免代码合并时抵触。
以上流程看似简单，不过借助 Phabricator 的命令行工具 Arcanist 能够很轻松的实现。
这里有个问题是 Feature 分支与骨干分支会有肯定差别，如上图 Feature 1 分支创立当前，Master 分支新的变更并不会进入到 Featrue 1，这个能够通过 Featrue 1 分支在 CI 流程中主动 Merge 骨干分支（在本地不会推送到近程），如果合并失败则 CI 流程失败，开发人员手工更新 Feature 1 分支，同步 Master 代码。
Hotfix 开发流程
Hotfix 开发流程与 Feature 相似，间接基于 Master 分支创立本地开发分支，开发通过后提交 Diff 进行，代码动态查看，单元测试，Code Review 和 QA 测试，通过后合并进入 Master 分支，公布上线。
有些状况下当 Master 分支曾经合并了新的 Feature，这时有紧急的 Hotfix 须要公布时，须要用到 Release 分支。能够基于上次上线的 Commit 创立一个 Release 分支，而后将 Hotfix 从 Master cherry-pick 到 Release 分支公布。
这时要保留 Release 分支，以防有新的 Hotfix 须要公布，直到下次 Master 分支公布后就能够删除 Release 分支。因为咱们的 SaaS 服务，公布频率很高，这种状况较少产生。
CI 流程
基于 Feature 分支的 CI 流程
在 GrowingIO 总是存在多个 Feature Team 在并行开发不同的性能，每个 Feature Team 都有本人独立的开发联调环境（对应到 Feature 分支）。
开发提交代码到 Feature 分支，Jenkins 主动监测到对应代码仓库的代码分支变更，而后启动对应的工作进行代码的动态查看，单元测试，编译，打包，并部署到开发联调环境。
对于前端和服务端利用是打包成 Docker 镜像进行部署在对应分支的 K8S 环境，对于数据端利用是打包成 zip 包部署到基于 VM 的环境。
同一个 Feature 的代码都提交后，开发在开发环境进行联调测试。其要害过程：Git Push → Code Check → Unit Test → Build → Deploy → Integrated Testing。联调测试通过后提交 Diff，触发上面流程。
基于 Diff 的 CI 流程
开发提交 Diff 当前通过 Phabricator 定义的主动规定，主动调用 Jenkins 的 Webhook 触发对应的 Jenkins 工作进行与骨干分支合并（并不提交到近程分支，只是查看有没有抵触）、代码动态查看、单元测试，Sonar 扫描、并通过 Jenkins 的 Phabricator 插件，将单测覆盖率等信息主动的增加到对应 Diff 的评论中。
如果下面的主动查看步骤失败或单测覆盖率不达标，则须要对应的开发批改，直到通过主动查看（当然有时候有一些紧急的 Bugfix 须要疾速公布，也会放宽这一限度）。
当主动查看通过当前即可告诉组内的其余开发人员进行人工代码审核，如果审核通过则通过 Phabricator 将 Diff 标记为 Accepted，此时 Phabricator 中定义的主动规定会主动的将 QA Team 增加到 Diff 的 Blocked Reviewer (如果 Blocked Reviewer 还没有 Accepted，Diff 是无奈合并到骨干分支的)，并通过邮件告诉 QA 人员进行测试。
QA 人员依据须要会将对应的 Diff 通过手动运行 Jenkins 工作部署到对应的 QA 环境进行测试，测试通过当前会再次在 Phabricator 将 Diff 标记的 Accepted，并告诉对应的开发 Land 代码（Land 是 Phabricator 的一个术语，行将代码合并到骨干分支，并将 diff 敞开，等同于 Github/Gitlab 的 PR/MR merge），当然 QA 也能够间接 Land 代码。其要害过程：Create Diff → Auto Check → Peer Review → QA Review → Land。
上面是上述过程的简略流程架构图：
公布策略
通过下面的 CI 流程当前，实践上曾经进入到骨干分支的代码是随时能够部署的状态。但在理论实际中出于对质量保证和公布老本的思考，会管制公布节奏。
咱们采纳的是基于固定公布周期的麻利公布火车模式（Agile Release Train，ART），失常每周一个正式版本（区别于 Hotfix 版本）公布，个别在周二早晨部署。
品质要求
下面也提到了，GrowingIO 是多个 Feature Team 并行开发，尽管每个 Feature 提交的代码都是通过测试才进入到骨干分支，然而在一个公布周期内多个团队可能对同一个代码仓库作出批改，多个 Diff 相互影响可能引入新的缺点。
还有就是在 Diff 测试的时候个别会关注在 Diff 本身的批改可能影响到的局部，尽管开发、测试会尽可能的剖析其影响范畴，但受制于每个人的常识以及零碎的复杂性，一个 Diff 批改可能引起齐全想不到的中央呈现缺点。
所以，在公布前必须对要公布的性能进行比拟全面的回归测试（在这方面咱们不止一次的犯错~□~||）。这一回归过程大略须要整个 QA Team 半天到一天的工作量，回归测试中发现的缺点要求立刻修复。
此外，回归测试期间会进入 Code Freeze 阶段，所有波及公布的代码仓库禁止开发 Land 代码到骨干分支，只有 QA 有权限 Land 代码到骨干分支。
这样做的次要目是防止曾经回归测试过的性能，因为新代码引入 Bug；同时又保障回归测试的 Bugfix 可能进入骨干分支。如果回归测试中发现的缺点无奈短时间内修复须要将有问题的 Diff 在公布分支剔除，定位到引入问题的 Diff 而后 Revert。
TIPS： 回归测试发现缺点当前为什么不延期公布？
- 因为「火车」上有其它货物（新 Feature 或 Bugfix）须要按时交付给客户。
- Code Freeze 工夫过长将影响失常的迭代，代码不能合并到骨干，前面有依赖开发碰壁。
- 如果勾销 Code Freeze 延期公布又要从新做回归测试，节约人力物力。
老本思考
下面提到了，每次正式版本公布须要做全面的回归测试，如果频繁公布必然会导致大量的人力消耗，再者 QA 都去做回归测试了，谁来做 Diff 测试？
这个问题解决的计划是晋升回归测试的效率。一是加大回归测试的自动化测试覆盖率，二是采纳一些精准测试策略，升高不必要的回归测试执行。但这些都须要一些资源投入来缓缓建设，短期内较难达到，所以抉择正当的公布节奏是最简略无效的形式。
个性开关
有些时候，曾经进入骨干分支的某个新性能并不心愿用户看到，可能是出于市场宣传的思考，也可能是性能还在迭代中还不够欠缺等起因。这种状况能够应用个性开关（Feature Toggle）管制。
目前 GrowingIO 的 Feature 开关能够实现，依照客户组织 ID，客户我的项目 ID，用户邮箱，用户邮箱后缀，以及自定义脚本规定进行各种精细化的 Feature 管制，这些配置能够通过批改配置文件实现热更新。
部署策略
部署前筹备
回归测试通过当前，QA 团队会进行公布前筹备工作，次要包含以下几方面：
- 生成 Jira Release Notes，查看 Jira 中 Release Version 关联的 Ticket 是否都是实现状态。
- 如果是未实现状态，查看是状态没有及时更新的，更新状态。
- 如果是未实现状态，如果是没有实现的挪动到后续版本。
- 如果是回归测试中发现有问题的 Diff 被剔除了，对应的 Ticket 也要移到后续版本。
2. 生成工程 Release Notes
- 蕴含上线执行步骤，上线哪个代码仓库的哪个分支，个别都是 Master。如果有非凡操作阐明，如须要批改配置或执行 SQL 脚本的都要具体阐明。
- 具体的批改清单，本次公布蕴含哪些新的 Diff 以及其对应的 Jira Ticket。次要是不便上线后呈现问题当前通过本次上线的批改清单，疾速的定位到可疑的 Diff，进行问题排查。
- 每次上线即便是简略的 Hotfix 也必须提供公布清单。
- 公布清单都有特定的版本号，版本号与 Jira 的 Release Version 对应。
- Release Notes 生成当前会公布到研发群中，请各个团队进行 Review。
TIPS： 工程 Release Notes 次要通过脚本主动的查看所有要公布的代码仓库，主动生成，而后有必要时进行简略的人工调整。
部署筹备
公布清单准备就绪后 QA 团队会通过钉钉群向 SRE 团队提交上线申请，SRE 团队收到上线申请后，会查看上线清单的步骤是否清晰明确，并相熟公布内容。如果确认无误会提前通过 Jenkins 编译本次要公布的代码，提前做好部署筹备。
部署过程
东风速递，使命必达 ????，达到预约的公布工夫点当前，SRE 会开始部署。为了保障部署过程中服务不中断，GrowingIO 目前采纳的服务端部署形式是蓝绿滚动部署形式。
咱们线上有两个类似的服务端集群，这两个集群中的微服注册在独立的 Goup 中，流量互相隔离。部署过程中会先将 Prod0 集群下线，此时客户流量全副进入到剩下的集群 Prod1，SRE 会依照部署清单更新 Prod0 中的服务，当部署实现后会告诉 QA 在 Prod0 集群做验证。
QA 验证通过当前会告诉 SRE 团队，持续公布。此时 SRE 团队会将 Prod0 集群上线，而后下线 Prod1 集群，并更新 Prod1 集群。
Prod1 集群更新结束当前会再次告诉 QA 在 Prod1 集群验证。QA 验证通过当前会再次告诉 SRE 团队，持续公布。SRE 会将 Prod1 集群上线，并告诉部署实现。
这里须要阐明的是数据端的利用公布采纳的是滚动公布策略，所以是会随着 Prod0 公布一起公布的。
当然，尽管通过了各种后期的筹备和测试，然而意外还是可能产生，不过几率很小。如果在上线过程中 QA 验证发现重大问题，或者 SRE 通过监控告警发现异常会终止上线，并回滚相干服务。
整个部署和回滚操作都是由 Jenkins 执行 Capistrano 脚本实现的，具体的部署细节并不需要人工干预，少数状况下，整个部署过程会在 30 分钟内实现。
部署收尾
部署胜利后 QA 团队会发送 Release 邮件，告诉公司全体成员本次公布的版本中蕴含的具体内容，即部署前筹备工作中的「Jira Release Notes」和「工程 Release Notes」。
前者面向业务人员浏览，后者面向工程人员，这样整个公司的人员都能够及时理解到本人关注的新性能或者 Bugfix 是否上线了。
问题与有余
上述 CI/CD 流程还有很多有余，最重要的问题有以下几点。
1. 基于源代码公布
目前 GrowingIO SaaS 服务的公布，不论是部署到 Dev, QA, Staging 还是 Prod 环境都是基于大代码分支从新编译而后部署。每次基于源代码公布的问题在于：
- 浪费时间，每次公布都要从新编译代码，有些服务编译工夫较长，甚至达到 10 分钟。
- 可能因为每次编译的根底环境不同，近程依赖版本的一些变动导致编译出的代码不同，导致测试没问题上线后呈现问题。
这个问题比拟容易解决，例如在 GrowingIO 私有化部署产品线实现的 CI 流程，曾经实现了基于二进制包的交付，从而实现了一次编译，多套环境部署，当然，这里有个基本前提是代码与配置拆散。SaaS 没有以后进行革新的次要起因是打算等生产环境采纳基于 Kubernetes 容器云部署形式的时候一并解决。
2. 自动化测试覆盖度不够
高效的 CI/CD 流程离不开自动化测试的反对，目前 GrowingIO 整个 SaaS 产品的单元测试，API 自动化测试，UI 自动化测试覆盖率还不够欠缺，导致整个流程对手工查看的依赖过高，效率偏低。这个依赖于公司在在质量保证方面的继续投入，来逐渐改善，没有捷径可走。
3. 整个 CI/CD 流程分成了多段，通过邮件，钉钉，jenkins 人工串联起来
目前整个 CI/CD 的流程分成了 Feature CI 流程，Diff CI 流程，部署流程，三个流程通过邮件告诉，钉钉音讯，不同的 Jenkins 工作串联起来。随着公司规模的扩充，这样的合作流程会变得越来越凌乱低效，而且很难做到数据的收集度量。
解决这个问题的无效办法是开发一个工具平台将流程和工具集成起来，提供对立的治理入口、流程标准，并实现数据的主动采集剖析。
4. 部署过程过于简单，不能实现更轻量滚动公布和金丝雀部署
下面提到为了保障公布过程用户服务不中断，采纳了滚动蓝绿部署的形式。这种形式部署时是将一半集群所有微服下线，此时线上提供的最大服务能力减半，在用户应用高峰期，这种操作显然危险极高，限度了公布工夫窗口的抉择。
此外，每次降级单个微服务的时候都要将整个一半集群下线，显然也是不够正当的。目前的打算是在生产环境应用基于 Kubernetes 的容器云部署形式来解决这一问题。
总结
本文次要介绍了 CI/CD 的概念，以及 GrowingIO SaaS 产品在外部采纳的各种工具，以及在 CI/CD 上的具体实际。正如下面所述，咱们目前间隔成熟的 CI/CD 还有肯定差距。甚至有些中央并没有恪守最佳实际，比方基于源代码的公布。
然而这些实际都是依据公司的理论状况一步步建设欠缺起来的，心愿对大家有一些启发。另外本文次要形容了整个 CI/CD 的宏观流程，后续的文章会持续介绍一些具体的工具配置应用办法，以及 GrowingIO 在私有化部署产品中 CI/CD 的一些改良。
对于 GrowingIO
GrowingIO 是国内当先的一站式数字化增长整体计划服务商。为产品、经营、市场、数据团队及管理者提供客户数据平台（CDP）、广告剖析、产品剖析、智能经营等产品和咨询服务，帮忙企业在数字化转型的路上，晋升数据驱动能力，实现更好的增长。
点击「此处」，获取 GrowingIO 15 天收费试用！