Release/Change management - best aproach
Posted
by
Bob Rivers
on Programmers
See other posts from Programmers
or by Bob Rivers
Published on 2011-02-17T12:17:18Z
Indexed on
2011/02/17
15:33 UTC
Read the original article
Hit count: 330
I asked this question an year ago in StackOverflow and never got a good answer. Since Programmers seems to be a better place to ask it, I'll give it a try...
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?
Let's assume that we are talking about a mid to large "centralized" web system (no clients), in-house development. This system can be considered "vital" for a corporate operations.
I have a tendency to prefer to do this by releasing packets at regular intervals, not greater than 1 to 3 months. 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?
© Programmers or respective owner