Avoid massive releases.
The larger the release, the more bugs there will be. When you only release software a couple of times a year, you have bugs on top of bugs, under bugs, and hidden by other bugs.
A large release tends to have many different classes changing. It also includes many new dependencies and interconnections. As the development team adds more parts to the release, the complexity and the chance for things to go wrong increases geometrically, not linearly. Thus, several things will always be wrong in a large release.
Another issue with big releases that happen rarely is that the business requirements have probably changed during this time. So what you are delivering may no longer match what the business desires. This divergence reduces your ability to deliver working software and add business value. And if you’re not doing that, then what are you doing?
On the other hand, in a tiny release, sometimes very few lines of code change. And because the difference is small, the code is carefully tested and has a low chance of being wrong.
And with short, rapid releases, you can be much more agile and respond to change instantly. Your business people will love you for that.
Ideally, it would be best if you had a series of frequent, tiny releases. Some organizations can push to production several times a day. To get there, you must master unit testing, integration testing, continuous integration, and continuous deployment.
It would help if you had robots that automated all of the work that goes into a release.
Robots are the future.
Today's Card 