总览
持续集成是一种软件开发实践，旨在通过自动化的构建和测试流程来频繁地合并代码变更到主分支。这种方法的核心在于“持续”，即任何时候都可以将代码集成到主分支而不会破坏项目。
优势：
- 提高软件质量：通过持续的构建和测试，CI帮助团队更早地发现和修复缺陷。
- 加快开发速度：自动化流程减少了手动测试和部署的时间，使新功能可以快速推向市场。
- 降低风险：持续集成降低了因代码集成问题导致的项目风险。例如，如果集成失败，可以快速回滚到上一个版本，避免影响用户的使用
- 促进团队协作：团队成员可以实时看到彼此的工作，促进了更紧密的协作。
持续集成是现代软件开发的关键组成部分，它通过自动化流程提高了开发效率和软件质量，是实现敏捷开发和DevOps的重要基石。
并且持续集成通常需要整个项目组成员协同以及一些工具来实现，如Git、Jenkins、Flow、Travis CI、GitLab CI、CircleCI等来进行自动化构建、测试和部署功能。
开始
通常来说。中大型软件项目公司都会有自己的持续集成服务器，并且会设计一套规则来满足持续集成的需求。美萌当然也不例外。
在我们评估了我们的交付属性后发现。我们的持续集成面临着几大挑战
服务器成本高: 并行运行测试需要大量服务器资源。包括服务器带宽/磁盘/CPU/内存等。
客户环境复杂：不同的云服务商、本地机房。环境资源不同等
集成难度高: 复杂的配置、脚本、工具等。在无运维人员部署配置时非常容易出错
开发环境多： 小程序 / Web / Android / iOS / SeverSide 等配置各不相同
该如何解决？
这里直接说结论
持续集成代码规范：明确开发规范并强力执行
持续集成环境：拆分不同环境，根据项目实际推进制定集成策略，最大限度满足复杂多变的发布环境。
完善发布文档: 所有项目都需要有发布文档，方便相关人员操作部署。
制定检查机制：通过相关检查机制，保证CI核心流程的稳定和落实到位。
特定项目特定处理: 针对特定需求项目。由架构师、运维人员、测试人员等共同完成。如(K8S容器化部署、Docker镜像构建)
接下来我们将对每个流程进行详细介绍
持续集成代码规范
基于公司开发规范的基础上。在CI中我们要进一步说明的是如何使用GIT的规范。这会影响到如何发布测试环境 和 使用FLOW流水线进行生产发布。
这里我们综合评估后。决定采用 阿里云FLOW分支流水线方案
持续集成环境
对于一个项目的环境。通常会将项目分为以下几个环境：
开发环境(dev)：开发环境。用于开发人员开发、测试、调试等。
测试环境(test/uat)： 测试环境。用于开发人员测试、QA测试、用户验收测试等。
预发布环境(stg): 预生产环境。用于线上环境灰度回归测试等。很少项目使用。不会过多扩展
生产环境(prod)： 线上正式使用环境
开发环境(dev)
对于我们来说。很少会有项目单独部署一套开发环境。通常我们会将开发环境定义为本地。
即前端启动本地localhost。后端启动服务并开放IP:端口进行对接访问。
所以这块没有特定的规范。基于分支规范对接开发即可
测试环境(test/uat)
当代码开发完毕。需要提交发布至测试环境。让测试人员进行测试。针对不同环境有不同的发布流程。
微信小程序：本地构建发布至 微信小程序平台
Android/iOS: 本地构建发布至 蒲公英
生产环境(prod)
当我们的代码经过了充分的测试和客户验证后。即可进入上线环节。不同于测试环境，生产环境的要求是非常高的。需要确保线上的 稳定性/可靠性/可回滚性，并且可能需要在一些节点加入人工的审核和通知。所以需要一套完整的发布流程和工具来确保。
对于生产环境。我们采用云效Flow发布。
完善发布文档
我们始终强调的是：发布文档是非常重要的。对于项目开发人员还是运维人员。都需要了解如何发布项目。
所以对于开发人员。我们要求所有项目都必须编写发布文档。
对于发布文档，你可以写的地方有：
(推荐)在项目wiki中编写并在git仓库中显式的写明wiki地址
在git仓库中的README.md编写
警告
涉及客户部署资料。包括不限于 服务器/数据库账号密码的。绝不允许提交到git仓库中。
制定检查机制
为了保证CI核心流程的稳定和落实到位。我们制定CI检查机制。
代码检查：项目代码检查人员将上述规范纳入日常检查规范中。在发现未执行规范的，即使进行指正。并要求相关人员及时落实
质检检查：对接项目质检人员
特定项目特定处理
对于特定需求项目。例如 超大型项目/架构不符或是特殊要求项目。可以不执行上述发布流程。但是依旧需要编写发布文档。
jenkins
废弃
此方案已废弃。仅作留档