
Shipping is your company’s heartbeat (2013) - vinnyglennon
https://blog.intercom.com/shipping-is-your-companys-heartbeat/
======
igammarays
The other side of this coin is when you're trying to push out the first
version of an MVP. Devs can get so enamored by the process of designing and
perfecting your continuous delivery process that it distracts them from the
actual product, not to mention wasted time writing tests for features that
will only get thrown out after the first redesign. I call it continuously
delivering nothing.

~~~
toast0
The basic version of continuous delivery is devs have access to the server,
and push code there when it's done. You don't need a process while you're
building an MVP, or it's not very minimum.

------
elmerland
It sounds nice in theory, and maybe you could make it work. But in reality,
distracting a developer from whatever they were doing has a cost. Add up ten 1
minute fixes and your whole day goes by.

From the customer's perspective though having a fix out in a couple of minutes
is the golden standard. I guess that's were team organization and planning
comes into play. Having a couple of dedicated resources to address these ad
hoc issues, without distracting the people working on larger projects.

~~~
wpietri
I think the dichotomy you introduce here is false. My experience with
continuous deployment is that the faster you can ship, the smaller projects
get.

Instead of bundling a lot of hypotheses about possibly-valuable changes up
into a big release, you focus more on the next step in the direction you're
going. You release those steps one by one. (User-visibility of larger features
is controlled by feature flags, but you ship and user-test in small slices.)

In that context, the whole notion of distraction is different. You have to
hold a lot less state in your head. Instead that state lives in your unit
tests, your acceptance tests, your backlog, and the world at large. If a given
developer is releasing a couple of times a day, it's just not a big deal to
find a natural stopping point, release something small, and then pick up the
next slice of some longer-term effort.

------
luckyt
> In a company where you ship continuously, you see this and think “Simple –
> I’ll tweak a test and a regex pattern, get a quick code review from my buddy
> beside me, merge to mainline, and 1 minute later when it’s deployed to
> production, reply to the customer: ‘Sorry about this, it’s fixed now, thanks
> for letting us know.’”

This sounds like a really bad idea. If it's not a critical bug impacting all
your customers, do you have to fix it in 1 minute? Once your company gets
bigger, you would want to do proper code review and QA, so your 'one-line fix'
doesn't accidentally bring down the whole site.

~~~
BillinghamJ
You deploy gradually, initially to 1% or so of requests. If your metrics,
KPIs, etc. don’t suffer, it continues to roll-out until 100% of requests are
using that code-path - within a few hours or so.

Takes a bit of infra effort, but for a company like Intercom, that’s very
easily achievable.

~~~
AznHisoka
this is easy and doable if your change is a front end change.

good luck trying this when its a backend change involving distributed threads,
locks, resources, etc where production load is 100x more than staging/test.

~~~
greenleafjacob
If the cost of downtime is high enough you can mirror some or all traffic onto
a shadow copy of the infrastructure.

