探索中的持续部署

  • 崔康

2012 年 7 月 19 日

话题:持续集成DevOps语言 & 开发架构文化 & 方法

在这个定义下,我们就必须将运行环境的软件解构,并以包的形式导入到公司的整个项目资源库中,比如 Apache 将作为一个包被导入,而 Apache 依赖的其它包也将依次被导入,并建立起正确的依赖关系。而且,在导入的过程中还必须做些相应的调整,如,环境变量的读取和设置,必须来自于环境配置模块,而不要修改系统的环境变量,防止不同环境在系统环境配置上相互影响和依赖。

部署,一次部署可能会产生一个环境实例。一系列部署将产生对应于环境目标的多个环境实例,除去当前起作用的环境实例外(最新的),其它的是历史环境实例。通过在历史环境实例中切换,我们自然而然的就可以使整个环境回滚,因为项目所依赖的一切都已经成为的环境中的软件包,而且环境依赖的包的版本会随着部署具体确定下来。

建立逻辑软件包版本和版本库中软件包版本间的关系;为相互依赖的包编译并打上统一的标签;简化运行时包依赖关系的生产;简化运行时包依赖的指定(可参考 apt-get 和 RubyGem,环境只需指定直接依赖的包,间接依赖的包从运行时依赖树中自动导入)

由于我们已经将部署作为环境管理的一部分,而环境又是对外提供服务的最小实体,因此,对环境的部署就是要根据部署的类型,在环境上按一定的步骤执行一系列操作,从而使环境置于部署类型所要的状态,这个过程中可能会生成对应的环境实例。举例来说,我们可能会修改环境相关的一些配置,然后重启环境,显然,这种情况下不需要下载安装软件包(没有改变),因此也就不需要生成环境实例。

持续集成DevOps语言 & 开发架构文化 & 方法