Release/Change management - best aproach

Question

What is the better way to work with release management? More specifically what would be the best way to release packages?

For example, assuming that you have a relatively stable system, a good quality assurance process (QA), etc. How do you prefer to release new versions?

I have a tendency to prefer to do this by releasing packets at regular intervals, not greater than 1 month. During this period, I will include into the package,fixes and improvements and make the implementation in production environment only once.

But I've seen some people who prefer to place small changes in production, but with a greater frequency.

The claim of these people is that by doing so, it is easier to identify bugs that have gone through the process of QA: in a package with 10 changes and another with only 1, it is much easier to know what caused the problem in the package with just one change...

What is the opinion came from you?

Update 1 (trying to define boundaries): I was thinking about an in-house, mid to large system, without clients (web based), that can be considered vital to the corporate operations.

Answer 1

A lot depends on what you're releasing -- something small that takes minimal effort on the part of the user to install is more practical to release more often. If each update is going to take the user an hour to install, you'd better make each one significant enough to justify that effort.

Answer 2

Once upon a time a worked for a small development tools vendor. We did relatively large releases a few times a year. It's too much work to package a product, especially if it is to be documented as well as regression tested. Distributing on the internet instead of physical media changes this very little.

Doing custom development / system integration work (multiple jobs), we install updates when they are needed, no more, no less.

What's required?