img

近几年，接触了不少自动化部署落地的案例，也亲身经历了从手动部署到容器化平台的迁移过程。

略有一些感触，遥想当年一晚上手工上线四十多模块带来的辛酸，感叹今日的自动化技术带来的便利。

近些年来非常火的一个词，叫做持续交付(CD)，当然，还有一个词叫CI，今日不作讨论。

持续交付的核心就是以最快的速度将它交付给用户。

交付当天

通常来说，应用版本发布的当天是比较紧张的，因为对于大多数项目来说，发布的风险还是比较大的。

很多时候，应用或者软件服务版本发布都是需要手工操作的。在这个过程中，有太多步骤容易出错，假如其中一步没有完美地执行，那么这个应用程序就可能无法正常地运行。一旦发生这样的情况，很难说清楚哪里有问题，或者说哪一步错了。

虽然现在很多公司的环境逐步迁移到容器平台，但因为历史遗留问题，很多项目的服务还停留在非容器的环境。非容器的环境，部署过程较为复杂，当然有些重视运维的公司会自研自动化部署的环境来解决这个问题。

关于手工部署

但是，还是有不少公司，部署手段还停留在手工部署。手工部署或者没有完全自动化部署，有以下特征：

  • 有详尽的部署文档(当然，也有不少公司是没有的，这对工作交接带来了隐患)；
  • 日常工作常常浪费在调试部署错误的过程；
  • 手工测试来确认是否运行正常；
  • 在发布时，常常需要修正一些在发布过程中发现的问题；
  • 开发、测试、预发布、生产各环境不一致，配置、目录结构、中间件架构等不相同；
  • 发布耗时较长；
  • 常常需要回滚，或者无法回滚；

手工部署虽然问题不少，但也是要求部署人员有足够的专业知识来做这些重复的工作。

发布耗时越长，出现错误的概率也越大。非生产环境与生产环境的差异性越大，发布失败的概率也越大。

总的来讲，发布交付是一件非常沉闷、无聊、令人焦虑的事情。

总结

因此，为了避免这些错误和焦虑，需要使用一套高度自动化的系统来完成交付工作。

持续交付实质是一个流水线，一个可重复且可靠的过程。它使测试人员、运维人员或支持服务人员能够做到自服务，即他们可以自行决定将哪个版本的应用程序部署到哪个环境中。也就是，过程中的每一个步骤都自动化。

持续交付带来的好处是能够更早的发现软件的缺陷，修复的成本也越低。由于发布过程本身已不再是一个障碍，我们可以部署软件变更，从而更快地获得商业利益。

生命如此短暂，我们不能把自己的假期浪费在计算机旁，做那些枯燥无味的部署工作。