2020 年 10 月 26 日早上 11:00 整，突突突小分队 Leader 老李在周会上召开了新项目启动大会，由于是新项目，老李引进了 CODING DevOps 产品，目的是将 DevOps 理念和工作流贯彻到团队实际工作中，规范团队的开发、测试和运维流程，并进一步提升产品发布效率。散会前老李当场创建两个项目分别为 front-backend-cd 和 k8s-yaml，并表示给大家一天的时间了解 CODING DevOps 产品。
突突突小分队 成员之间配合已经有相当的默契，在了解了 CODING DevOps 产品后，第二天（10 月 27 日）各自开始了有条不紊的工作：
后端大熊在项目 front-backend-cd 中创建后端代码仓库 flask-backend
前端阿强在项目 front-backend-cd 中创建前端代码仓库 react-frontend
运维小胖在项目 k8s-yaml 中创建代码仓库 k8s-yaml
测试小莉整理测试用例，根据 Leader 老李提供的接口文档编写后端 API 自动化测试代码
将 k8s-yaml 作为独立项目维护的原因是除了 front-backend-cd 项目，k8s-yaml 也管理着其他项目的 Kubernetes yaml 文件，单独建库的目除了方便对 yaml 文件做版本控制，也便于开发和运维职责分明，开发不需要关注太多的运维基础设施（Kubernetes），主要精力放在编码、编译和构建镜像。
持续集成代码仓库初始化后，后端大熊和前端阿强开始了愉快的编码，同时在完成第一次代码提交前，Leader 老李已经为团队搭建好持续集成，并分别交由大熊和阿强维护。在下班前大熊和阿强完成了脚手架代码，提交了代码合并请求（MR，Merge Request）。
细心的前端阿强发现合并请求详情页正运行一个叫 合并状态检查 的任务，请教 Leader 老李后得知是合并请求触发的自动构建计划， 其作用是：自动构建源分支与目标分支合并后的结果，能够尽可能早地发现集成中的错误。如果合并状态检查失败，评审者不用过早介入代码 review 流程，开发者可以自行检查代码。
合并状态检查处点击 详情 可查看构建计划的执行详情：
果然，第一次合并状态检查失败，前端阿强根据构建日志，发现了一个低级的字符拼写错误，在内心深深的对自己鄙视一番后，立即修复，再次提交合并请求。
前后端代码经 Leader 老李 review 合并到 release 后，会触发相应的构建计划，其起点都是代码检出，终点是将镜像推送到制品库。
在后端大熊、前端阿强忙得热火朝天的同时，运维小胖也没有闲着，老李将小胖添加到团队的【运维】用户组，并授予【运维】用户组部署设置权限，小胖跟着 CODING 持续部署的文档开始一步步配置。
阅读更多：CODING CD 帮助文档
作为云原生的先行团队，突突突小分队很早就采用腾讯云 TKE 作为生产环境，于是运维小胖添加了 TKE 类型的云账号。
添加完云账号后，运维小胖根据使用引导跳转到 CODING 部署控制台，分别创建了应用 flaskBackend 和 reactFrontend。
接着配置部署流程，运维小胖将 k8s-yaml 项目中的 manifest 文件以及制品库中的 docker 镜像配置为部署流程制品，并在 Kubernetes 资源部署阶段（Deploy（Manifest）-Deployment）引用。
如图只有以 release- 为前缀的 docker 镜像才会成功匹配为发布制品
在人工确认阶段，运维小胖将自己设置为确认人，并将测试小莉加入通知人列表。
测试小莉也会接收到人工确认通知，虽然没有权限进行确认操作，但可以对发布过程 review，以降低发布故障率。
