I know there are going to always be differences depending on the particular size, staff etc, but i wanted to get feedback in general around:

In an environment where you have a production support team doing first line support and release management, is it better to simply have developers manage their own releases instead? In this case, its internal software at an insurance company but the question should be valid at any company, size, etc I think.

Currently, we have our production team do releases but there is an argument that its inefficient and that if you allowed developers the ability to do it, they will focus more on making it simple and efficient and avoid basically passing on scripts, etc to run to another team.

The counter argument is that if you don't have a check and balance, you could get a software team (or an individual) that doesn't a very hacky job about getting their software out there (making on the fly changes, not documenting the process, etc) and that by forcing the prod support team to do the actual release, it enforces consistency and proper checks and balances.

I know this is not a black or white issue but I wanted to see what folks thought on this so the discipline and consistency is there but without the feeling that an inefficient process is in place.

  • Sounds like the support team is also the test team? I guess you should let the test team test it first, or if you lack the test team, then better have support test it before the customers have to (unless your policy is customer=tester like a company i've previously worked for :-). – Louis Somers Nov 26 '11 at 1:01
  • Can you do a "press-one-button-to-build-release"? – user1249 Nov 26 '11 at 23:26
  • Why not? I think more and more evidence is coming from companies that the model of having developers manage and deploy their applications is the right way. Look at StackOverflow, Amazon, Netflix, Etsy, Facebook, and many, many more. – mkobit May 6 '16 at 1:57
  • A great article written by Netflix also touches on this subject - Full Cycle Developers at Netflix — Operate What You Build. – mkobit Aug 16 '18 at 21:07

There are a number of reasons why developers should not do production releases. This is even more important when you have a production support team who need to manage the code after release.

I have extensive experience in small organizations and teams without production support teams. Even in these organizations releases were done as if we had a production support team. My experiences supporting applications as well as developing them lead me to respect both roles and their different requirements.

Among the reasons for the handoff to production support:

  • Fixes may be done directly in production and lost when the next release comes out. (I just violated this rule for a one line configuration fix during a week-end production release. But you can bet I made sure it got fixed in the code base on Monday. A larger fix went from developers to integration testing and then to production.)
  • Environment configuration may get baked into the code. This results in development builds, integration testing builds, and production builds. Sometimes non-configuration or untested changes get included in the production build.
  • Production support get builds they don't know how to run. This seems great for the indispensable developer who needs to do all the restarts but is not good for the company.
  • Production and development code for a release can grow increasingly different. (I once made the mistake of comparing a development code base that was supposed to be identical to the production code. Some files were the same.)
  • Released code is packaged and configured in a manner more suitable for development than production. The production team is likely to encourage or required appropriate packaging and configuration capabilities.
  • Code releases may not get tagged in version control. Versions built for hand-off need to be tracked. This may not necessarily happen, but less likely to be skipped or overlooked if the code is being "released" to integration testing or production.
  • Micro-releases are possible. This makes support a nightmare. (It was broken at 2:00 but is might have been fixed in the 2:15 or 3:05 release.)

EDIT: The production support team are one of the stakeholders in the release. It helps if the development team works with the production support team to make it successful. Separate environment specific configuration so that they can be maintained appropriately. It is often appropriate for the the production support team to maintain the environment configuration.

  • 1
    The same reasons could be presented to support the opposite opinion, as well. I once worked in a company where the production support team was responsible for releases to the production environment. And they used to make some of the mistakes you point out, like editing a config file directly in production. Since they had no access to the project's version control (and didn't care, actually), the files went out of synch. But, when anything went wrong with the release, the blame fell on the development team. So, it would be much better if developers themselves took care of the release process. – Otavio Macedo Nov 26 '11 at 14:33

I firmly believe that the developers should do all the things necessary to release their code. The biggest problem with delegation of responsibility is that it creates a lot of mistrust between teams that takes a lot hits and teams that do the work. This mistrust and friction causes both the teams focusing their effort and energy on fire fighting and finger pointing activities.

If the idea is that your team should develop valuable code that works well on a production environment then the biggest value comes from what the developer will learn from doing all the activities by himself. If he does not face the issue, he will view all firefighting from other teams as a hindrance rather than learning. When he views as hindrance he will simply not learn but try to focus on how to do things undetected by the other teams.

If I were the company with money to afford specialist teams and demand zero failures. I would put in place a few loosely defined(non binding) expert teams and let the developer choose if he wants his work reviewed by them. If the release fails, the developer knows what he did wrong and how he can avoid it. As grows up in the technical ladder he might want to move into those expert teams.

Due to peer pressure people will get their work reviewed by the expert teams. And it will also create better relation between expert teams and developers, actually leading to better work.

  • Another reason for this is that the goals when having different teams are directly competing against each. The "production support" want stability, which is the opposite of change. The development team is inherently making changes. – mkobit Oct 24 '17 at 15:52

I'm currently working at a small company (it's just 4 of us) so we have to do all of the work (starting with the client interviews to fetch information about features, creating specification documents, and final product deployment).

It was chaos at first, but as we started getting used to doing multiple tasks, we realized that if you define workflows and kind of standarize them, everyone should be able to do some part of the process without knowing what the other did.

Another lesson we learned is: It's always good to know something about each part of the system. I don't mean how its implemented but rather what it does. It's really useful when creating releases (like the problem you mention) because the developer making the release, although he/she did not write that code, knows what is it for.

So, to sum up: Developers should develop to solve a problem. Releasers (I think I just made that up) should think about the best way to release a certain solution. If you think about releasing when developing, your code won't be as clean and may generate problems in the future.


You could try to install a continuous integration process (see here http://en.wikipedia.org/wiki/Continuous_integration). That way, you have always and every day a new release candidate at hand. That does not mean that every of those releases are really delivered to the users, the decision is still up to the production team which version or milestone they deliver. The important part is that you get the responsibilties right between the developer team and the production team.

On the other hand, your development team will be forced to learn how to develop in smaller iterations, where each iteration is a fully documented, internally tested increment. Perhaps that will help you to work more efficient on both sides.

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.