在这个定义下，我们就必须将运行环境的软件解构，并以包的形式导入到公司的整个项目资源库中，比如 Apache 将作为一个包被导入，而 Apache 依赖的其它包也将依次被导入，并建立起正确的依赖关系。而且，在导入的过程中还必须做些相应的调整，如，环境变量的读取和设置，必须来自于环境配置模块，而不要修改系统的环境变量，防止不同环境在系统环境配置上相互影响和依赖。
部署，一次部署可能会产生一个环境实例。一系列部署将产生对应于环境目标的多个环境实例，除去当前起作用的环境实例外（最新的），其它的是历史环境实例。通过在历史环境实例中切换，我们自然而然的就可以使整个环境回滚，因为项目所依赖的一切都已经成为的环境中的软件包，而且环境依赖的包的版本会随着部署具体确定下来。
建立逻辑软件包版本和版本库中软件包版本间的关系；为相互依赖的包编译并打上统一的标签；简化运行时包依赖关系的生产；简化运行时包依赖的指定（可参考 apt-get 和 RubyGem，环境只需指定直接依赖的包，间接依赖的包从运行时依赖树中自动导入）
由于我们已经将部署作为环境管理的一部分，而环境又是对外提供服务的最小实体，因此，对环境的部署就是要根据部署的类型，在环境上按一定的步骤执行一系列操作，从而使环境置于部署类型所要的状态，这个过程中可能会生成对应的环境实例。举例来说，我们可能会修改环境相关的一些配置，然后重启环境，显然，这种情况下不需要下载安装软件包（没有改变），因此也就不需要生成环境实例。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
从数据库历史，看分布式数据库的架构设计趋势
微服务架构下，使用 Higress 构建高性能云原生网关实践
FinOps 实战：趣丸科技云成本洞察实践和探索
评论