3 ms·
At my previous job we didn't have a QA team and we deployed continuously every day, including on Fridays, even though we were on-call. We just had a robust and
by thiht 4y ago
At my previous job we didn't have a QA team and we deployed continuously every day, including on Fridays, even though we were on-call. We just had a robust and reliable integration test suite, and we took code review very seriously. I've never been called on a week-end because of something broken specifically because of a Friday deployment.
If you're not confident about deploying on a Friday, you shouldn't be confident deploying at all.
To be clear, for big, risky changes, we obviously waited for the following Monday. The key is we didn't have a blanket ban on Friday deployments. Not being able to deploy for 20% of the working week is bad.
- kevincox 4y agoI am actually confident that each deploy runs a risk of implementing new bugs. I'm confident enough to do the deploy and our tests make it likely that most major functions are working correctly. But we have bugs, we continuously have bugs. And 9/10 times new found bugs are from new changes. I'd rather have those bugs be found when people are in office than needing to force the oncall back to work or have our product broken for the weekend. If you are so confident why even have an oncall? Because we know reality is. Bugs are rare and severe bugs are more rare. But they do happen. So let's try to make them happen less when people are out of office.