Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
