6 ms·

> The process of deploying code to production is very simple, and takes about ten minutes total. This results in a life cycle in which we deploy code to product

> The process of deploying code to production is very simple, and takes about ten minutes total. This results in a life cycle in which we deploy code to production approximately 100 times per day. What? They spend 1000 minutes out of every 1440 deploying to production? The deployment process is occurring over 16 hours out of every 24? Am I the only one who is nonplussed by this? EDIT: Ok I get it, I get it. I guess I always worked in much smaller companies where CD meant deploying about 10 times a day tops. TIL big companies are big.

deleted 8y ago
[deleted]
maaark 8y ago
C'mon dude, it obviously doesn't require everyone in the company to spend 10 minutes for each deployment, it takes one person 10 minutes to deploy one thing.
- nathancahill 8y ago
  Probably not even. One person starts a deploy, after 10 minutes they can deploy again.
m0meni 8y ago
https://en.wikipedia.org/wiki/Continuous_delivery https://en.wikipedia.org/wiki/Continuous_delivery
xyzzy_plugh 8y ago
I think you're assuming that each deploy is somehow disruptive or blocking, as if systems enter some "deploy mode". This may be true of a fleet overall, but is not when you take an instance into account. Instead imagine each deploy as an edge, and imagine them to be near instantaneous. With respect to an instance, and a user, and the observable effects of a deploy, this paints a more accurate picture. 100 times a day means one deploy every 14.4 minutes. How many times a day do you think Amazon deploys changes? Or Facebook? Or Google?
- electrum 8y ago
  Deployment at Facebook: https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/ https://code.facebook.com/posts/270314900139291/rapid-releas...
wgerard 8y ago
Not a slack employee but worked at a company with similar CD views: (Likely) various groups of people are deploying to production throughout the day. Out of those 100 deploys, an individual is probably only involved in 1 or 2 a day. As soon as you're ready to deploy your code, you queue up and see it all the way through to production along with probably a few other people doing the same thing. The actual "change the servers over to the new production code" process is usually instantaneous or extremely quick, the 10 minutes is mostly spent testing/building/etc. People (including myself) enjoy this because you can push very small incremental changes to production, which significantly reduces the chance of confounding errors or major issues. Note that this is would be a Sisyphean task if your company doesn't have great logging/metrics reporting/testing/etc.
- toomuchtodo 8y ago
  It’s usually a Sisyphean task. Everyone wants to look and act cutting edge (“but Netflix!”) but nobody wants to make the necessary investments in the tooling, org structure, and management ability/support that is required to support that sort of deployment cadence (if your org focuses on who broke something instead of the process, and management doesn’t want to change that culture, all hope is already lost [based on experience in a large enterprise, YMMV]). There are some legitimate needs for continuous deployment, the rest of it is cargo culting.
  - wgerard 8y ago
    > There are some legitimate needs for continuous deployment, the rest of it is cargo culting. Maybe, but I wouldn't go that far. Small companies already often do CD, because there's rarely a rigid deploy schedule. It's a practice people understand and feel the benefits of immediately. If you ask someone who moved from a small startup to a huge company what their biggest complaints are, I bet "longer/stricter deploy process" comes up 8/10 times. When I think of cargo cult programming I think more of TDD or Agile: Practices that people aren't familiar with and often implement without understanding the benefits or reasoning.
    - 8y ago
hoorayimhelping 8y ago
When you have a team of 200 people, deploying 100 times a day isn't that big of a number. A culture of continuous deployment is often hard to fathom for people who've never worked at a company with one. Everything, down to what you write and how you write it, is influenced by being able to deploy it and see its effects almost instantly. These aren't huge, sweeping changes being deployed. They're small pieces of larger feature sets. It's more like: Deploy a conditional statement with logging and confirm from the logs that it works; next, deploy the view that you're testing with a feature flag toggled in a way that you and the pm can see it that is properly called from the conditional from before; when things look good, deploy some controller code that handles form requests from the view, etc. You deploy small changes piecemeal and so spread out the risk over a larger period of time. It makes identifying issues with a new piece of code almost trivial. Needing to debug 30 lines of code is so much less harrowing than needing to look over 900.
- Gravityloss 8y ago
  Also depends what you are working on...
stephengillie 8y ago
When I started at a real estate webhost in 2013, there was a "push Dev to Prod" script, and a scheduled task to run the script every 60 seconds. So we technically had 1440 pushes per day, though most developers were only working during daylight hours. So having more pushes per day isn't necessarily the metric to maximize. Quality of code changes for each push is important, and this is where automated testing can be very valuable. The goal is for automated testing to be a "gatekeeper of bad code". But even this system isn't perfect, and it's possible to deploy things that pass tests but still have show-stopping bugs. Or for the code to cause your tests to misbehave - I'm seeing this now with Tape.js on Travis, where Tape sees my S3 init calls as extra tests. Then my build fails because - of the 2 tests specified, 3 failed, and another 4 passed.
jsjohnst 8y ago
You’re assuming a monolithic app, maybe there’s twenty services that get deployed five times a day.

deleted 8y ago

[deleted]

maaark 8y ago

C'mon dude, it obviously doesn't require everyone in the company to spend 10 minutes for each deployment, it takes one person 10 minutes to deploy one thing.

nathancahill 8y ago
Probably not even. One person starts a deploy, after 10 minutes they can deploy again.

m0meni 8y ago

https://en.wikipedia.org/wiki/Continuous_delivery https://en.wikipedia.org/wiki/Continuous_delivery

xyzzy_plugh 8y ago

I think you're assuming that each deploy is somehow disruptive or blocking, as if systems enter some "deploy mode". This may be true of a fleet overall, but is not when you take an instance into account. Instead imagine each deploy as an edge, and imagine them to be near instantaneous. With respect to an instance, and a user, and the observable effects of a deploy, this paints a more accurate picture. 100 times a day means one deploy every 14.4 minutes. How many times a day do you think Amazon deploys changes? Or Facebook? Or Google?

electrum 8y ago
Deployment at Facebook: https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/ https://code.facebook.com/posts/270314900139291/rapid-releas...

wgerard 8y ago

Not a slack employee but worked at a company with similar CD views: (Likely) various groups of people are deploying to production throughout the day. Out of those 100 deploys, an individual is probably only involved in 1 or 2 a day. As soon as you're ready to deploy your code, you queue up and see it all the way through to production along with probably a few other people doing the same thing. The actual "change the servers over to the new production code" process is usually instantaneous or extremely quick, the 10 minutes is mostly spent testing/building/etc. People (including myself) enjoy this because you can push very small incremental changes to production, which significantly reduces the chance of confounding errors or major issues. Note that this is would be a Sisyphean task if your company doesn't have great logging/metrics reporting/testing/etc.

toomuchtodo 8y ago
It’s usually a Sisyphean task. Everyone wants to look and act cutting edge (“but Netflix!”) but nobody wants to make the necessary investments in the tooling, org structure, and management ability/support that is required to support that sort of deployment cadence (if your org focuses on who broke something instead of the process, and management doesn’t want to change that culture, all hope is already lost [based on experience in a large enterprise, YMMV]). There are some legitimate needs for continuous deployment, the rest of it is cargo culting.
- wgerard 8y ago
  > There are some legitimate needs for continuous deployment, the rest of it is cargo culting. Maybe, but I wouldn't go that far. Small companies already often do CD, because there's rarely a rigid deploy schedule. It's a practice people understand and feel the benefits of immediately. If you ask someone who moved from a small startup to a huge company what their biggest complaints are, I bet "longer/stricter deploy process" comes up 8/10 times. When I think of cargo cult programming I think more of TDD or Agile: Practices that people aren't familiar with and often implement without understanding the benefits or reasoning.
  - 8y ago

hoorayimhelping 8y ago

When you have a team of 200 people, deploying 100 times a day isn't that big of a number. A culture of continuous deployment is often hard to fathom for people who've never worked at a company with one. Everything, down to what you write and how you write it, is influenced by being able to deploy it and see its effects almost instantly. These aren't huge, sweeping changes being deployed. They're small pieces of larger feature sets. It's more like: Deploy a conditional statement with logging and confirm from the logs that it works; next, deploy the view that you're testing with a feature flag toggled in a way that you and the pm can see it that is properly called from the conditional from before; when things look good, deploy some controller code that handles form requests from the view, etc. You deploy small changes piecemeal and so spread out the risk over a larger period of time. It makes identifying issues with a new piece of code almost trivial. Needing to debug 30 lines of code is so much less harrowing than needing to look over 900.

Gravityloss 8y ago
Also depends what you are working on...

stephengillie 8y ago

When I started at a real estate webhost in 2013, there was a "push Dev to Prod" script, and a scheduled task to run the script every 60 seconds. So we technically had 1440 pushes per day, though most developers were only working during daylight hours. So having more pushes per day isn't necessarily the metric to maximize. Quality of code changes for each push is important, and this is where automated testing can be very valuable. The goal is for automated testing to be a "gatekeeper of bad code". But even this system isn't perfect, and it's possible to deploy things that pass tests but still have show-stopping bugs. Or for the code to cause your tests to misbehave - I'm seeing this now with Tape.js on Travis, where Tape sees my S3 init calls as extra tests. Then my build fails because - of the 2 tests specified, 3 failed, and another 4 passed.

jsjohnst 8y ago

You’re assuming a monolithic app, maybe there’s twenty services that get deployed five times a day.