借这个周末闲适的下午和明媚的阳光，决定把近来项目上的CI/CD（持续集成/持续交付）策略以及Git分支模型和以前的项目做一下分析比较，希望对各位有所帮助，也能有所思考，尤其是那些期望搭建项目部署流水线或者想了解Git分支模型的开发、运维人员。 背景 废话不多说，由于近期做了N次release，所以对自己目前所处的新项目的部署方式有了一定的了解。为了方便，本文就叫该项目为A项目吧。发现A项目的部署方式和我之前接触的TW“传统”CI/CD策略差异比较大（在ThoughtWorks，几乎每个项目都有持续集成/持续交付流水线，如果你对它们的概念还不是很清楚，建议阅读持续交付这本书，将对你梳理整个交付流程帮助巨大）。 关于A项目的背景，受客户保密协议的**，我只能透露几点。A项目所属公司为国外某大型电信运营商，主要内容为用户账户自服务平台。该平台涉及诸多内外部服务，如认证、订单跟踪、短信认证等等，数量总数在三十多个左右，而每个服务都是一个独立的子系统，有独立的代码库、独立的机器实例（AWS EC2 实例）用于运行，以及一套独立的Jenkins Job用于自动化构建和部署（即我们接下来谈的内容）。当然，这也是为什么A项目想往微服务架构迁移的主要目的。 接下来，让我剥去诸多项目的其他内容，仅仅讨论一下它的CI/CD策略，也可以说是它的构建、部署方式。 A项目的CI/CD策略 千言万语还是不及一张图（作者小学美术数学老师教的，望见谅）： 上图，为一个独立子项目（如背景中所说的某个服务）在其Jenkins里面的任务（Job）结构图，主要有两种自动化任务，Build和Deploy：
这用在该项目组中几乎所有的以服务为单位的子系统之上，也就是说，我们有将近三十套左右类似这样的Jenkins任务。 需要说明的是，上图中的黑色圆圈、黑色圆圈加横线和黑色空心圆圈分别代表完全自动化、需要手动更改配置后点击触发和需要手动点击出发三种情况，即如下图所示： 这样的方式有如下几个特点：
B项目的策略及比较 而我曾经接触过的一些项目，同样为了便于说明，这里我们统称它为B项目，不管它的CI/CD工具用的是Jenkins还是go.cd，它们都会是一种流水线（Pipeline）的形式，如下图所示（没错，请叫我灵魂画师， |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
