I completely agree, but every week or two is too long. At one point we had ours running builds + automated regression testing => release twice or more a day. Along with automatic change logs and monitoring, It was so nice. Tiny updates are always better to test and know exactly what/where/how a failure or positive change occurs when the cadence is that fast. The devs loved it, the QA loved it, and as a DevOps, I loved it. We were even able to do AB testing and rolling updates.
It only got worse when management changed hands and some people decided on going agile in a “Scrum-but” method and it’s been a drag that sprints are 3 weeks long. Now releases take longer, have larger impact for better or worse, and regression testing is much more complex and I have to be more involved in releasing new code. The faster cadence meant it happened so often it was fully automated and I didn’t even know when most went out unless I was watching a dashboard.
I completely agree, but every week or two is too long. At one point we had ours running builds + automated regression testing => release twice or more a day. Along with automatic change logs and monitoring, It was so nice. Tiny updates are always better to test and know exactly what/where/how a failure or positive change occurs when the cadence is that fast. The devs loved it, the QA loved it, and as a DevOps, I loved it. We were even able to do AB testing and rolling updates.
It only got worse when management changed hands and some people decided on going agile in a “Scrum-but” method and it’s been a drag that sprints are 3 weeks long. Now releases take longer, have larger impact for better or worse, and regression testing is much more complex and I have to be more involved in releasing new code. The faster cadence meant it happened so often it was fully automated and I didn’t even know when most went out unless I was watching a dashboard.
Mobile app users get annoyed if you push too many updates. So you gotta pace yourself.