持续整合&持续交付

在公司继续打杂

公司准备弄一套自动部署系统,这两天看了一堆的资料

持续部署:业界没有统一明确地定义,简单理解为将集成结果部署到不同的环境供用户使用,并且立即反馈部署结果的实践,其中不同的环境包括:开发环境、测试环境、预发布环境、生产环境

持续部署两个核心要素:持续、自动化,自动化是持续的基础

持续部署的需求场景:

  • 需要频繁的发布更新
  • 部署规模较大,人工操作费时费力易出错
  • 规范化上线部署流程和配置规范

我计划的流程如下

  • 开发者提交代码到版本仓库

  • 自动触发持续集成,Jenkins调用Rundeck获取部署文件并部署到测试环境

  • 在测试环境进行单元测试

  • 单元测试完成后,生成Docker并部署到开发环境

  • 测试人员进行产品验证

  • 测试人员在验证通过后,申请发布到生产环境,并手动触发Jenkins

  • 运维人员触发Rundeck,将Docker更新到生产环境

后来发现RundeckJenkins的集成并不是很稳定,决定尝试CircleCI 持续整合&持续交付工具。

  • CI和接入版本控制

  • 代码push集成单元测试

  • 提交代码到开放版本

  • 生产Docker,并部署到开发环境

  • 进行人工测试

  • 测试成功后,部署Docker到生产环境


The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证

本文首发于Why·Liam·Blog (https://blog.naaln.com),版权所有,侵权必究。

本文永久链接:https://blog.naaln.com/2016/05/continuous-integration-continuous-delivery/

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!