“环境管理”在DevOps世界中是如何运作的？

Question

今天，我就环境管理在遵循DevOps实践的团队中所扮演的角色进行了一些非常有趣的讨论。环境管理人员的传统角色是：

全面负责协调软件开发生命周期所有阶段的多个小组和组件，以确保及时交付和提供一套已知的软件版本。

我相信，在遵循DevOps实践的跨功能敏捷团队中，这些责任属于整个团队，最终要向作为业务代表的产品负责人负责。

简而言之，我的问题是谁是.负责遵循DevOps实践的团队中的环境管理，即没有外部环境管理器功能的团队。

Answer 1

我从没听说过“环境经理”另一方面，发布管理在历史上一直被整合到一个人或一个团队中。

在DevOps模型中，版本管理更多地是由来自Dev和Ops的元素支持的过程。处于高级别"DevOps成熟度“的组织并没有真正的发布管理事件--发布的行为是在连续交付管道中进行的(参见"push on green”什么是“推动绿色”？)

可能OP也是指配置管理( Configuration )，在配置管理中，特定于环境的配置是手动管理的，或者是通过诸如Puppet或Chef之类的工具来管理的。这项工作传统上是一个操作系统管理的任务，高成熟度的操作人员通过代码来处理这个问题。Dev和Ops之间可以分担责任，也可能有一个专门的SRE团队来处理Config管理。

Answer 2

我想出三种方法来处理这个需求。

1. 该软件声明其依赖项，并与每个依赖关系发布在正确的版本独立于其他版本。例如，如果两个版本的相同依赖项与数据库访问不兼容，并且需要上面的系统来确保只将兼容版本部署到环境中，则可能会产生问题，实现该版本的方式可能因工具而异，而且很难正确实现。
2. 软件声明其依赖项，如果目标环境上的一个依赖项的当前可用版本不匹配，则部署停止并保留该软件的实际版本。然后，团队必须与依赖团队进行协调，以了解他们何时能够部署。主要的缺点是延迟，这会带来释放列车。在这里，实现它的方式可能会有所不同，取决于工具。
3. 跨团队，由每个团队的成员组成，处理版本向发布方向的协调。这有助于在正确的时间获得东西，但没有强制执行任何控制。

在我看来，最好的设置是上面的2+3，以便在执行不同团队之间的通信并允许与依赖的多个版本兼容的同时，处理丢失的依赖关系的任何问题。这需要跟踪这种行为更改，以便在不再在线时删除不必要的旧API处理。