Small PR are easy to review and parse. Work gets broken down in to small, shippable changes. If you couple that with feature flags, you can get to a point where shipping a release is as easy as building whatever the latest commit is on Main and pushing it out the door.
Easy to say if your code doesn’t matter. If you work for regulated industries (FAA, FDA) you can’t ship it out the door.
I have been working on automating our tests for years. Manual testing still finds a lot of things despite passing all the automated tests. I’m now convinced anyone who says “automate that” doesn’t care about quality, humans are too good at finding things.
I completely agree. Not mentioned in my spiel is the constant human QA effort, each ticket merged gets checked, releases get a week of testing before release to the public.
Also, yeah. I’m iOS frontend. I make pixels dance. Either I leave security to Keychain or I hope (read: confirm) backend is sanitising inputs.
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.
Small PR are easy to review and parse. Work gets broken down in to small, shippable changes. If you couple that with feature flags, you can get to a point where shipping a release is as easy as building whatever the latest commit is on Main and pushing it out the door.
Automate that, do it every week or two.
Easy to say if your code doesn’t matter. If you work for regulated industries (FAA, FDA) you can’t ship it out the door.
I have been working on automating our tests for years. Manual testing still finds a lot of things despite passing all the automated tests. I’m now convinced anyone who says “automate that” doesn’t care about quality, humans are too good at finding things.
I completely agree. Not mentioned in my spiel is the constant human QA effort, each ticket merged gets checked, releases get a week of testing before release to the public.
Also, yeah. I’m iOS frontend. I make pixels dance. Either I leave security to Keychain or I hope (read: confirm) backend is sanitising inputs.
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.