4

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.

030
  • 13,383
  • 17
  • 76
  • 178
Richard Slater
  • 11,747
  • 7
  • 43
  • 82

2 Answers2

3

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"?)

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.

Community
  • 1
Dave Swersky
  • 4,068
  • 2
  • 21
  • 33
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.

Tensibai
  • 11,416
  • 2
  • 37
  • 63