How does 'Environment Management' work in a DevOps world? I've had some very interesting conversations today about the role of Environment Management within teams that follow DevOps practices.  The traditional role of an Environment Manager was someone who:


  Took overall responsibility for coordinating multiple teams and components at all stages of the software development life cycle, SDLC, to ensure that a known sets of software versions are delivered and available in a timely manner.


It is my belief that in a cross-functional Agile team following DevOps practices these responsibilities belong to the team as a whole, ultimately being accountable to the Product Owner as the representative of the business.

In short, my question is who is... responsible for Environment Management in a team following DevOps practices, i.e., one that does not have an external Environment Manager function available to them.
I've never heard of an "Environment Manager."  Release Management, on the other hand, has historically been consolidated to a single person or team.  

In a DevOps model, Release Management is more of a process supported by elements from both Dev and Ops.  Organizations at high levels of "DevOps maturity" don't really have a distinct Release Management event- the act of releasing is baked into the Continuous Delivery pipeline (see "push on green" What is &quot;Push on Green&quot;?)  

It's possible the OP is also referring to Configuration Management, where environment-specific configurations are managed manually, or by tools like Puppet or Chef.  That work is traditionally an Ops-managed task, with higher-maturity orgs handling that through code.  Responsibility may be shared between Dev and Ops, or there may be a dedicated SRE team that deals with Config Management.