I was instructed by my project manager that frequent deployment in PROD or to test server should be avoided. But I don't understand why? We roll our testing copy to PROD on every sprint end but suddenly client would ask a simple change to the existing application which would require a re-deployment. When every thing was well tested and QA approved. why should we avoid frequent deployment?

How it was done universally?

  • 1
    I don't understand what you mean when you say the client wants a change after the sprint. That has no effect on the work you just completed - it should be part of the next sprint. If this isn't the case, you're...well, doing it wrong.
    – Thomas Owens
    Sep 4, 2010 at 10:43
  • I can partially understand not frequently deploying to production, but not deploying to test. Test should be for, well, testing, and therefor requires lots of deployments.
    – TheLQ
    Sep 4, 2010 at 13:27
  • @Thomas Owens Yeah your right, But client needs it immediately How do should that be handled?
    – Gopi
    Sep 6, 2010 at 4:51
  • You make it the highest (or a very high) priority for the next sprint to ensure that it's properly designed, implemented, tested, and then deployed. Since you used the term sprint, I'm assuming that you are using Scrum - a sprint should only be 2 to 4 weeks long. Adding a feature into a sprint at the last minute is only going to cause problems.
    – Thomas Owens
    Sep 6, 2010 at 10:53
  • 4
    This discussion right here is a perfect demonstration of the fundamental problem with programming methodologies. As much as @Thomas Owens believes in his procedure and methodology, @Sri Kumar's client doesn't care about sprints or procedures, they just have stuff they want now. That's where methodology breaks down completely, and you get questions like, "how bad is it REALLY to post new changes straight to prod?"
    – Dan Ray
    Sep 8, 2010 at 12:52

4 Answers 4


If you are talking about a hosted web application, the users don't get a say-so in when they get upgrades. That is, they are forced to upgrade each time you do a push to production.

If your changes dramatically change the system rules or UI, you should definitely consider bundling your releases and doing it less frequently. It is very frustrating to users to have to continually re-learn how to use the tools they rely on and violates the UI principle of making them feel they are in control of their computer/software.


if your re-deployement require downtime, then client may be unhappy about that. Also it depends on the frequency whether its daily weekly or monthly. My last project has a regular outage window at 2nd sat of every month with client's approval. You may check for any accepted outage window with your client.


There are always cases where issues are found in prod. Back to back deploys can make it MUCH more difficult in many cases to determine the actual source of the problems. Other than that I would deploy as often as everyone is comfortable with.

On the other hand, the client is the boss, if they want it deployed now with no testing that is there option and unless there is something irreversibly dangerous about it that you can explain to them about the change you have little recourse but to document the request, the approval, and make certain you have a way to go back if they don't like the outcome.

You are not always going to have total process buy-in from the client.


Why should frequent changes to prod be avoided? Because they can cause performance problems and user issues. Users need to be aware of the changes that might affect them espcially if the roll to prod might involve a lot of performance hits to the database and thus cause slowdowns. Because the users don't like it when they get locked out for an upgrade just when they need to run payroll. Users are often on the application all day long every day, they get cranky when lots of changes over a short period of time happen and they complain to their bosses who complain to your boss' boss who will yell at your boss.

Prod rolls are also risky. It is the rare place which actually tests against production level usage (heck way too many places don't even test code against produstion size databases), so things that appear to work fine in QA can cause the whole system to come to a crashing halt in a production enviroment. So the fewer times you go to prod with new code the fewer times your boss is at risk of being called on the carpet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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