<p>I see three way to handle this need.</p>

<ol>
<li><p>The software declare its dependencies and is released with each dependency at the correct version independently of others. This may create problems if two version of the same dependency are not compatible for database access for example and need a system above to ensure only compatibles version are deployed toward an environment, the way to achieve it may vary depending on the tooling and is quite hard to get it right.</p></li>
<li><p>The software declare its dependencies, and if current available version of one dependency on the target environment doesn't match, the deploy stop and keep actual version the software. The team has then to coordinate with the dependency team to know when they'll be able to deploy. Main drawback is the delay this can bring in the release train. Here again the way to achieve it may vary depending on the tooling.</p></li>
<li><p>Cross teams made from members of each team, to handle the coordination of versions toward release. This help getting things at the right time but doesn't enforce any control.</p></li>
</ol>

<p>Best setup in my opinion is 2+3 above, to handle any problem of missed dependency while enforcing a communication between separate teams and allowing releases compatible with multiple version of the dependencies. this need to keep trace of this kind of behavior change to remove the unneeded old API handling once it is not on line anymore.</p>

CC BY-SA 3.0
2017-03-23T13:29:21.453Z
2017-03-23T13:29:21.453Z
Tensibai
<p>I've never heard of an "Environment Manager."  Release Management, on the other hand, has historically been consolidated to a single person or team.  </p>

<p>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 <em>event</em>- the act of releasing is baked into the Continuous Delivery pipeline (see "push on green" <a href="https://devops.stackexchange.com/questions/573/what-is-push-on-green">What is &quot;Push on Green&quot;?</a>)  </p>

<p>It's possible the OP is also referring to <em>Configuration Management</em>, 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.</p>

CC BY-SA 3.0
2017-03-23T16:26:06.190Z
Thanks for your answer Dave - I like the way you answered my question with another of my questions ;-)
Richard Slater
CC BY-SA 3.0
2017-03-23T16:13:10.823Z
2017-03-23T16:13:10.823Z
2017-04-13T13:01:29.297Z
Dave Swersky
<p>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 <em>Environment Manager</em> was someone who:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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.</p>

<p><strong>In short, my question is</strong> 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.</p>

CC BY-SA 3.0
2017-03-23T13:16:19.460Z
Wow! There's a role for environment managing too?
Dawny33
CC BY-SA 3.0
2017-03-23T13:17:01.693Z
@Dawny33 usually assumed by ops team responsible of delivery of new software versions.
Tensibai
CC BY-SA 3.0
2017-03-23T13:18:46.090Z
The job description (= what you quoted) of this Environment Manager sounds pretty similar to a Release Manager, no? If not could you explain what, in your opinion, the difference between both roles is?
Pierre.Vriens
CC BY-SA 3.0
2017-03-23T13:19:58.410Z
@Pierre.Vriens Wouldn't a RM be responsible for only one release at a time?
Dan Cornilescu
CC BY-SA 3.0
2017-03-23T13:28:59.390Z
Generally, yes, Release Managers are responsible for managing the release process from a release-centric view of the world, i.e. have all of the dependencies been released into production in the correct order, release notes have been written, business communication has been issued, marketing collateral has been delivered.  Environment Management is more about the ongoing state of all of the environments.  Equally there tend's not to be Release Managers in Agile teams the responsibility becomes defused within the team as part of preparing a release at the end of sprints/super sprints.
Richard Slater
CC BY-SA 3.0
2017-03-23T13:37:43.400Z
@DanCornilescu : looks like you have another perception of a RM as compared to mine ... IMO a RM is the mgr of a Release Management TEAM, which consists of X users, and all they do, all year around, it to orchestrate of subsequent releases of various types (such as business apps versus infrastructure updates)
Pierre.Vriens
CC BY-SA 3.0
2017-03-23T13:42:06.203Z
I think th last comment from @RichardSlater should be integrated in the question (+ add 'agile team' in the title also?) ...
Pierre.Vriens
CC BY-SA 3.0
2017-03-23T13:43:03.930Z
@Pierre.Vriens Yep, another item highly dependent on the organisation.
Dan Cornilescu
CC BY-SA 3.0
2017-03-23T15:08:49.077Z
@RichardSlater in general it's recommended to accompany a quote with a link indicating its origin, if available. I tried to find it to get more context, but Google didn't help :) Thx.
Dan Cornilescu
<culture><agile><environments>
How does 'Environment Management' work in a DevOps world?
Richard Slater
# How does 'Environment Management' work in a DevOps world?

(Asked by: username_0 on 2017-03-23)

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.

**Tags:** culture, agile, environments

> **Comments:**
> **username_1**: Wow! There's a role for environment managing too?  
> **username_2**: @username_1 usually assumed by ops team responsible of delivery of new software versions.  
> **username_3**: The job description (= what you quoted) of this Environment Manager sounds pretty similar to a Release Manager, no? If not could you explain what, in your opinion, the difference between both roles is?  
> **username_4**: @username_3 Wouldn't a RM be responsible for only one release at a time?  
> **username_0**: Generally, yes, Release Managers are responsible for managing the release process from a release-centric view of the world, i.e. have all of the dependencies been released into production in the correct order, release notes have been written, business communication has been issued, marketing collateral has been delivered.  Environment Management is more about the ongoing state of all of the environments.  Equally there tend's not to be Release Managers in Agile teams the responsibility becomes defused within the team as part of preparing a release at the end of sprints/super sprints.  
> **username_3**: @DanCornilescu : looks like you have another perception of a RM as compared to mine ... IMO a RM is the mgr of a Release Management TEAM, which consists of X users, and all they do, all year around, it to orchestrate of subsequent releases of various types (such as business apps versus infrastructure updates)  
> **username_3**: I think th last comment from @RichardSlater should be integrated in the question (+ add 'agile team' in the title also?) ...  
> **username_4**: @username_3 Yep, another item highly dependent on the organisation.  
> **username_4**: @RichardSlater in general it's recommended to accompany a quote with a link indicating its origin, if available. I tried to find it to get more context, but Google didn't help :) Thx.  

---

## 2 answers

### Answer by username_5 on 2017-03-23. Score: 3 | Accepted answer

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 "Push on Green"?](https://devops.stackexchange.com/questions/573/what-is-push-on-green))

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.

> **Comments:**
> **username_0**: Thanks for your answer Dave - I like the way you answered my question with another of my questions ;-)  

---

### Answer by username_2 on 2017-03-23. Score: 1

I see three way to handle this need.

1. The software declare its dependencies and is released with each dependency at the correct version independently of others. This may create problems if two version of the same dependency are not compatible for database access for example and need a system above to ensure only compatibles version are deployed toward an environment, the way to achieve it may vary depending on the tooling and is quite hard to get it right.
2. The software declare its dependencies, and if current available version of one dependency on the target environment doesn't match, the deploy stop and keep actual version the software. The team has then to coordinate with the dependency team to know when they'll be able to deploy. Main drawback is the delay this can bring in the release train. Here again the way to achieve it may vary depending on the tooling.
3. Cross teams made from members of each team, to handle the coordination of versions toward release. This help getting things at the right time but doesn't enforce any control.

Best setup in my opinion is 2+3 above, to handle any problem of missed dependency while enforcing a communication between separate teams and allowing releases compatible with multiple version of the dependencies. this need to keep trace of this kind of behavior change to remove the unneeded old API handling once it is not on line anymore.


---

