We used to do releases whenever we wanted. After this took the site out one too many times, we moved to at most daily releases with an hour of QA.
This actually made things worse. Aggressive releases were often the result of a decision further up the chain that something was "critical" and needed to go out right then and there. We'd got into the pattern of expecting to be able to do this at the drop of a hat.
So now, everyone was rushing to get the "urgent fix" into the daily release. This is an effective way to ship buggy software. Extra emergency releases were frowned upon, and so it introduced a level of panic that "Oh shit, this better not screw everything up". Ironically, with anyone releasing whenever they wanted, there was less panic because you could always make a quick fix and put it out without too many people noticing or caring.
We felt as a team that we'd prefer a more relaxed schedule that also allowed testing and accountability.
Frequent releases were a result of bad management, and unrealistic stakeholder expectations, we as developers didn't necessarily care that our code wasn't being put out immediately. Obviously, it needs to go out at some point, and we've been equally demoralised by mammoth projects that have gone on for months without a release, but that's a different end of the spectrum. The important thing is regular releases, not frequent ones.
We've now decided to move to releases every 2 weeks with a 1 week QA period. We made this decision as a team of developers, it wasn't handed down from above, it just became a necessary check for the scale of our company.
I personally feel a lot more productive as a result, less panicked by the quick fix you need to drop everything to fit into the daily release, and less worried that a release will take out the site.
But sure, it comes at a cost. There's now a lot more going out with each release and more variables that could combine to cause issues, but these issues highlight deficiencies in our QA process that can be fixed. Also, getting our team to work according to this 2 week schedule has meant some significant costs to adopt better development processes, namely SCRUM, but I feel our team has benefited enormously from it. It all depends how well your team can adapt really.
So yes, there are costs associated, but it doesn't necessarily lead to demotivated developers. You need to be sure that the checks are introduced properly with their own test suite. This itself has a cost but can be extremely worthwhile. A half arsed and arbitrary change to your release schedule with no process changes can destroy you, but with a little training, the right team and the right managers, you can make things better for everyone.
This actually made things worse. Aggressive releases were often the result of a decision further up the chain that something was "critical" and needed to go out right then and there. We'd got into the pattern of expecting to be able to do this at the drop of a hat.
So now, everyone was rushing to get the "urgent fix" into the daily release. This is an effective way to ship buggy software. Extra emergency releases were frowned upon, and so it introduced a level of panic that "Oh shit, this better not screw everything up". Ironically, with anyone releasing whenever they wanted, there was less panic because you could always make a quick fix and put it out without too many people noticing or caring.
We felt as a team that we'd prefer a more relaxed schedule that also allowed testing and accountability.
Frequent releases were a result of bad management, and unrealistic stakeholder expectations, we as developers didn't necessarily care that our code wasn't being put out immediately. Obviously, it needs to go out at some point, and we've been equally demoralised by mammoth projects that have gone on for months without a release, but that's a different end of the spectrum. The important thing is regular releases, not frequent ones.
We've now decided to move to releases every 2 weeks with a 1 week QA period. We made this decision as a team of developers, it wasn't handed down from above, it just became a necessary check for the scale of our company.
I personally feel a lot more productive as a result, less panicked by the quick fix you need to drop everything to fit into the daily release, and less worried that a release will take out the site.
But sure, it comes at a cost. There's now a lot more going out with each release and more variables that could combine to cause issues, but these issues highlight deficiencies in our QA process that can be fixed. Also, getting our team to work according to this 2 week schedule has meant some significant costs to adopt better development processes, namely SCRUM, but I feel our team has benefited enormously from it. It all depends how well your team can adapt really.
So yes, there are costs associated, but it doesn't necessarily lead to demotivated developers. You need to be sure that the checks are introduced properly with their own test suite. This itself has a cost but can be extremely worthwhile. A half arsed and arbitrary change to your release schedule with no process changes can destroy you, but with a little training, the right team and the right managers, you can make things better for everyone.