7 ms·
I have worked for a lot of startups, and the best ones have deployed as often as possible. One company (which grew massively and is now public) allowed develope
by dlevine 4y ago
I have worked for a lot of startups, and the best ones have deployed as often as possible. One company (which grew massively and is now public) allowed developers to push code whenever they wanted. Once your code was merged into master and the required tests had passed, you could push to staging and then production whenever you wanted. However, you were responsible for making sure that your push didn't break anything. Developers took a lot of responsibility, and when something broke, the last guy who pushed usually fixed it really fast (and if not someone else did). Releases went out several times a day.
At my current job (fast-growing mid-stage startup), any developer can push when they want, but it works a bit differently. Once the release is staged, everyone who has a commit on staging is responsible for verifying their feature. Then the developer goes through a "release checklist," which involves finding a buddy and jointly running through a list of manual tests to validate key features. After that, they can push. They probably push a few times a week.
I feel like code freeze/manual QA/weekly push is something of an anti-pattern. Developers are disconnected from the process of releasing their code, and take less ownership. While in practice manual QA should lead to finding more bugs, in practice it can lead to more defects.