At my current employer (Root insurance), we currently deploy our server code at least twice a day and release mobile app once a week (Apple's review process doesn't really allow a faster cadence). In my time there I've seen us move from deploying once in whenever-something-needs-to-get-out, to once a week, to once a day, to now twice a day, and probably will accelerate even more as we grow.
It's an amazing feeling only being a few hours from shipping something and I have huge respect for the engineers who made our deployment process smooth as butter.
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
Everything needs to pass automated unit/integration/system tests and be approved by 2 engineers before it can merge into the main branch. Everything on the main branch will be shipped at the next deploy (all engineers have the capability to deploy outside of the regularly scheduled deploys; the schedule is the minimum cadence).
For things that need to be timed (like to coordinate with a third-party or announced launch-time), we'll often use a feature flag controlled by an environment variable (so we can enable it at any time independent of a deploy).
Everything is real-time monitored for health. Rolling a deploy back to a previous "good" state is even easier than deploying. Stakeholders should be included through the development process (as possible); but if they end up not liking something after seeing it live, a git revert and a few hours will take them back to their previous system (and everything going in front of the general public is A/B tested with control over how much of the population gets an experience)
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
At my current employer (Root insurance), we currently deploy our server code at least twice a day and release mobile app once a week (Apple's review process doesn't really allow a faster cadence). In my time there I've seen us move from deploying once in whenever-something-needs-to-get-out, to once a week, to once a day, to now twice a day, and probably will accelerate even more as we grow.
It's an amazing feeling only being a few hours from shipping something and I have huge respect for the engineers who made our deployment process smooth as butter.
That is amazing!!
When you do you ship new features? As soon as they are ready? When stakeholder approve? When they pass certain tests?
Everything needs to pass automated unit/integration/system tests and be approved by 2 engineers before it can merge into the main branch. Everything on the main branch will be shipped at the next deploy (all engineers have the capability to deploy outside of the regularly scheduled deploys; the schedule is the minimum cadence).
For things that need to be timed (like to coordinate with a third-party or announced launch-time), we'll often use a feature flag controlled by an environment variable (so we can enable it at any time independent of a deploy).
Everything is real-time monitored for health. Rolling a deploy back to a previous "good" state is even easier than deploying. Stakeholders should be included through the development process (as possible); but if they end up not liking something after seeing it live, a
git revertand a few hours will take them back to their previous system (and everything going in front of the general public is A/B tested with control over how much of the population gets an experience)That sounds like a dream setup!
Well, we're hiring at a 120% rate ;) and fully remote until the end of the year at least.
root.engineering/