Docker容器环境下的持续集成最佳实践：构建基于Drone + GitFlow + K8s的云原生语义化CI工作流

最新推荐文章于 2022-12-12 18:37:40 发布

小吴先森

最新推荐文章于 2022-12-12 18:37:40 发布

阅读量265

点赞数

分类专栏：协议

协议专栏收录该内容

5 篇文章 0 订阅

订阅专栏

<span style="color:#314659"><span style="color:#bababa !important"><code>rom_secret: <span style="color:#6a8759 !important">KUBERNETES_TOKEN</span>  
    namespace: <span style="color:#6a8759 !important">default</span>  
    deployment: <span style="color:#6a8759 !important">ci-demo-deployment</span>  
    repo: <span style="color:#6a8759 !important">allovince/drone-ci-demo</span>  
    container: <span style="color:#6a8759 !important">ci-demo</span>  
    tag:  
<span style="color:#6896ba !important">      -</span> <span style="color:#6a8759 !important">${DRONE_TAG}</span>  
  when:  
    event: <span style="color:#6a8759 !important">tag</span>
</code></span></span>

在示例中，可以看到在语义化发布之后CI会将新版本的Docker镜像自动发布到K8s，这里为了演示仅打印了指令并未实际运行。相当于运行了如下的指令：

<span style="color:#314659"><span style="color:#bababa !important"><code>kubectl -n default <span style="color:#e0c46c !important">set</span> image deployment/ci-demo-deployment ci-demo=allovince/drone-ci-demo:v1.0.2
</code></span></span>

由于自动发布的环节势必要接触到生产服务器，需要格外注意安全问题，首推的方式当然是将CI和K8s集群放于同一内网中，同时可以使用K8s的RBAC权限控制，为自动发布单独创建一个用户，并删除不必要的权限。

＃后话

总结一下，本文展示了从世界您好到单人单分支手动发布到团队多分支GitFlow流工作到团队多分支语义释放化语义发布到通知K8S全自动发布，如何从零开始一步一步搭建CI将团队开发，测试，发布的流程全部自动化的过程，最终能让开发人员只需要认真提交代码就可以完成日常的所有DevOps工作。

最终Step的完成品可以适应之前的所有Step，可果在此基础上稍作修改，直接使用。

然而写好每一个提供这个看似简单的要求，其实对于大多数团队来说并不容易做到，在实施过程中，经常会遇到团队成员不理解为什么要重视提出规范，每个提议都要深思熟虑是否过于吹毛求疵等等疑问。

以作为CI的核心，个人认为主要会带来以下几方面的影响：

一个好的承诺，代表着开发人员对当前改动之于整个系统的影响，有非常清楚的认识，代码的修改到底算feat还是fix，什么时候用BREAKING CHANGE等都是要仔细斟酌的，每个提都都在改变日里里“留底”，从而约束团队不随意提交未经思考的代码，提高代码质量
一个好的提也代表开发人员有能力对所实现功能进行精细的划分，一个分支做的事情不宜过多，一个提交也应该专注于只解决一个问题，每次提交（至少是每次推）都应该保持系统可构建，可运行，可测试，如果能坚持做到这些，对于合并代码时的冲突解决，以及集成测试都有很大帮助。
由于每次发布能清楚的看到所有关联的承以及承诺的重要程度，那么线上事故的回滚也会非常轻松，回滚到哪个版本，回滚后哪些功能会受到影响，只要看CI自动生成的释放记录就一目了然。如果没有这些，回滚误伤到预期外的功能从而引发连锁反应的惨痛教训，可能很多运维都有过类似经历吧。

因此CI自动化其实是锦上添花而非雪中送炭，如果团队原本就无视规范，承全是空白或者没有任何意义的单词，分支管理混乱，发布困难，奢望引入一套自动化CI来能解决所有这些问题，无疑是不现实的。而只有原本就重视代码质量，有一定规范意识，再通过自动化CI来监督约束，团队在CI的帮助下代码质量提高，从而有机会进一步改进CI的效率，才能形成良性循环。

愿天下不再有难发布的版本。

参考文献：