Continuous Deployments at BuzzFeed(tech.buzzfeed.com)
tech.buzzfeed.com
Continuous Deployments at BuzzFeed
https://tech.buzzfeed.com/continuous-deployments-at-buzzfeed-d171f76c1ac4
3 comments
I am part of the team that worked on this project. AMA
Do you have any metrics about how efficient the process has become at Buzzfeed? Like Microsoft's 1ES system? - https://twitter.com/IkeTheDev/status/1230854784686723072
Sure. Our numbers are smaller, as our org is much smaller but I think they hold up.
We have under 100 engineers at BuzzFeed, so for us we reduce time spent supporting applications by a single percentage is almost equivalent to having an extra engineer!
On a typical day we'll do 180+ deploys. That'll be roughly 60% stage, 40% production. To deploy outside of continuous deployments (e.g. to push a branch build to a stage environment), is as simple as browsing to our deploy UI, selecting the service you want to deploy, the version, and the cluster to deploy too. It takes an engineer about 40 seconds to do that (time measured from typing URL, to hitting the deploy button)
Continuous deployments means for production deploys for master, that step is automated. So that's a saving (in engineer time) of around 40 seconds per deploy. Over the last month over 1400 deploys were made via continuous deployment.
This means from a developer productivity perspective roughly 2 engineer days per month (1400 deploys * 40 secs per deploy / 3600 to get into hours / 8 hours per day) ) are being saved as a result of this change.
However this is really a side benefit. Our real motivation for making this change was to ensure that all master builds are deployed, and that each of our ~500 micro services is always on latest master.
This is to reduce developer anxiety of deploying over a branch build and thus minimize stress around making change.
The productivity side benefit is pretty nice though!
We have under 100 engineers at BuzzFeed, so for us we reduce time spent supporting applications by a single percentage is almost equivalent to having an extra engineer!
On a typical day we'll do 180+ deploys. That'll be roughly 60% stage, 40% production. To deploy outside of continuous deployments (e.g. to push a branch build to a stage environment), is as simple as browsing to our deploy UI, selecting the service you want to deploy, the version, and the cluster to deploy too. It takes an engineer about 40 seconds to do that (time measured from typing URL, to hitting the deploy button)
Continuous deployments means for production deploys for master, that step is automated. So that's a saving (in engineer time) of around 40 seconds per deploy. Over the last month over 1400 deploys were made via continuous deployment.
This means from a developer productivity perspective roughly 2 engineer days per month (1400 deploys * 40 secs per deploy / 3600 to get into hours / 8 hours per day) ) are being saved as a result of this change.
However this is really a side benefit. Our real motivation for making this change was to ensure that all master builds are deployed, and that each of our ~500 micro services is always on latest master.
This is to reduce developer anxiety of deploying over a branch build and thus minimize stress around making change.
The productivity side benefit is pretty nice though!