持续部署CI/CD

时间:2023-03-09 14:55:50
持续部署CI/CD

一.简介

在敏捷开发时,通常将服务进行拆分成不同模块,每个开发小组负责一个模块的开发,会在一天内对这个模块进行频繁的提交到仓库主干并部署到线上。CI/CD就是在开发中使用工具保证快速并稳定上线的方法,提交开发效率。

现在 jenkins 已经是常用运维工具了,所以很难体会到 CI/CD 的效果,没有进行对比。实际在最开始的时候一个技术团队中开发、测试、运维是没有太多关联的,发布模式如下:

  1. 开发进行项目代码开发、本地 PC 运行成功后将代码提交到版本 git 仓库中
  2. 开发通知运维进行项目发布,运维运行脚本将代码下载并打包构建
  3. 运维用部署脚本将成品部署到测试环境,通知测试人员进行功能测试
  4. 测试人员进行自动化功能测试,完成后通知开发可以合并到生产环境
  5. 找一天晚上运维进行生产环境的发版,测试进行功能测试

流程是没有问题的,在最开始瀑布式开发中因为 1-2 个月才发版一次这个发布流程不会出太大问题。但目前都是敏捷开发,将一个产品需求分割成多个,一天里测试环境可能要进行 10 多次迭代过程,那上面的模式会很痛苦,同时手动环境太多,也会造成人为失误。

二.分解

CI

持续集成(CONTINUOUS INTEGRATION)

持续部署CI/CD

在持续集成环境中,开发人员将会将代码频繁的从本地合并到主分支。每次迭代都要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果,以保障所有的提交在合并主线之后的质量问题,对可能出现的一些问题进行预警。

需要具备哪些条件:

  1. 你的团队需要为每个新功能,代码改进,或者问题修复创建自动化测试用例。
  2. 你需要一个持续集成服务器,它可以监控代码提交情况,对每个新的提交进行自动化测试。
  3. 研发团队需要尽可能快的提交代码,至少每天一次提交。

能获得什么呢?

  1. 通过自动化测试可以提早拿到回归测试的结果,避免将一些问题提交到交付生产中
  2. 发布编译将会更加容易,因为合并之初已经将所有问题都规避了
  3. 减少工作问题切换,研发可以很快获得构建失败的消息,在开始下一个任务之前就可以很快解决。
  4. 测试成本大幅降低-你的 CI 服务器可以在几秒钟之内运行上百条测试。
  5. 你的 QA 团队花费在测试上面的时间会大幅缩短,将会更加侧重于质量文化的提升上面。

CD

持续交付(CONTINUOUS DELIVERY)

持续部署CI/CD

CI 很容易理解,就是持续集成。但是 CD 既可以指代码持续交付,也可理解为代码持续部署。CI 和 CD 之间有很多相似的部分,但是也有很大的区别。

CI 主要是对代码进行迭代,保证每次修改的代码新增的内容都可以通过测试操作,确保在后续基础上开发,之前的代码没问题。但这些迭代多是内部迭代,并不发到生产,不会让用户进行体验。

持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付,将大需求拆分多个小版本,这样随时就可以发布多个小版本让用户尽快体验,可能在发布后出现其实不适合这个产品的情况,也可以避免更多损失,及时停止开发。

需要具备什么条件?

  1. 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求
  2. 部署需要自动化。触发是手动的,但是部署一旦开始,就不能人为干预。
  3. 你的团队可能需要接受特性开关,没有完成的功能模块不会影响到线上产品。

能收获什么?

  1. 繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。
  2. 你可以更快的进行交付,这样就加快了与客户之间的反馈环。
  3. 轻松应对小变更,加速迭代

CI/CD

持续部署(CONTINUOUS DEPLOYMENT)

持续部署CI/CD

如果我们想更加深入一步的话,就是持续部署了。通过这个方式,任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预(没有一键部署按钮),只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式,可以加速与客户的反馈循环,但是会给团队带来压力,因为不再有“发布日”了。开发人员可以专注于构建软件,他们看到他们的修改在他们完成工作后几分钟就上线了。基本上,当开发人员在主分支中合并一个提交时,这个分支将被构建、测试,如果一切顺利,则部署到生产环境中。

需要具备的条件:

  1. 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
  2. 你的文档和部署频率要保持一致。
  3. 特征标志成为发布重大变化过程的固有部分,以确保您可以与其他部门(支持,市场营销,公关…)协调。

可以获得什么?

  1. 发布频率更快,因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
  2. 在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复。
  3. 客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年。

三.总结

如前所述,您可以采用持续集成,持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。

如果你刚刚开始一个项目,并且还没有客户,那么你就可以去创建这些工作流,最好是将这三个方面都实现,并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目,那么您可以一步一步地分阶段去实现他们。

持续部署CI/CD