Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 视频教程 | 打赏(Donations) | About
知乎专栏多维度架构 微信号 netkiller-ebook | QQ群:128659835 请注明“读者”

17.6. 持续集成不是DevOps

Jenkins 不是 DevOps

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。

持续集成只是 DevOps 中的一个小小的环节,并不是最主要的核心工作。

持续集成可以解决什么问题

  1. 能验证代码是否可以正常编译
  2. 验证组建或模块是否能够集成
  3. 验证自动化测试用例是否正常运行
  4. 测试环境的部署

持续集成不能解决什么问题

  1. 生产环境的发布
  2. 部署失败后回撤
  3. 不能构建环境,虽然支持 Docker

持续集成智能单向操作,例如

		
代码->构建->测试->部署 等等		
		
		

持续集成中我们遇到很多问题

例如就是通过 git hook 触发 Jenkins 实现持续集成,自动构建项目。问题来了,任何提交都会触发一次 pipeline 脚本,当项目频繁提交时,第一个构建过程还未运行完毕,第二个进程便启动。导致构建排队,阻塞,同时 pipeline 可能会争夺资源(多个进程读写同一个文件),产生冲突,轻则稍等片刻,重则测试环境崩溃。

另外通过CI 持续集成部署代码也不靠谱,会出现和上面相同问题,例如第一个进程用 scp 复制 jar 包到远程主机,还未传输完成,第二个进程便做同样的操作。

还有 第一个进程重启 tomcat ,tomcat 还未停止退出,第二个请求便发出。最终导致 tomcat 崩溃。

以上的特性,你敢在生产环境上使用吗?一旦发布失败,或者需要回撤,持续集成并没有很好的解决方案。

我认为,持续集成尚不完善,测试环境玩玩可以,生产环境还是不要了。