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.

9
  • Wow! There's a role for environment managing too?
    – Dawny33
    Mar 23 '17 at 13:16
  • @Dawny33 usually assumed by ops team responsible of delivery of new software versions.
    – Tensibai
    Mar 23 '17 at 13:17
  • 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
    Mar 23 '17 at 13:18
  • 1
    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. Mar 23 '17 at 13:28
  • 1
    I think th last comment from @RichardSlater should be integrated in the question (+ add 'agile team' in the title also?) ...
    – Pierre.Vriens
    Mar 23 '17 at 13:42
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.

1
  • Thanks for your answer Dave - I like the way you answered my question with another of my questions ;-) Mar 23 '17 at 16:26
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.