3 ms·

I understand that, but would counter with that it sounds like deploy == release, and that if that weren't the case, you could deploy more often. However, I wil

I understand that, but would counter with that it sounds like deploy == release, and that if that weren't the case, you could deploy more often. However, I will admit it is a trade-off; some engineering time does have to be spent to get there, and perhaps that engineering time is better used elsewhere right now.

_vertigo 4y ago
What is the difference between deploying and releasing? Everywhere I’ve worked, those are the same thing. We deploy probably 10 to 30 times a workday. As for Friday deployments, I tend to avoid deploying big changes on Friday but medium and small are probably fine Friday unless it’s the very end of the day.
- pondidum 4y ago
  From the link further up the replies: > Deploy is the act of moving software into an environment and running it. > Release is the process of making a feature visible to a user or subset of users. In our case, we deploy often (10s of times per day), and make use of feature flags for releasing. Keeping an eye on data in Honeycomb before and after a deployment and before and after a flag is changed is part of the engineers job. If something doesn't look like it's working as intended, ideally it is disabled with a flag, rather than needing to figure out how a rollback can be done (often it can't), or rushing a fix and roll forward.
  - FridgeSeal 4y ago
    This is a pretty small distinction in my experience, and I think you'd find that most people would go with "if it goes into prod, it counts as a release". Regardless of how confident you are on your feature-flagging functionality, everyone's going to be unimpressed if suddenly your "minor" deploy has caused a bunch of things to go haywire at 4:30pm on a Friday and now people have to stay back and fix things.
snowwrestler 4y ago
If you put new code into production, that is a deployment and an engineering release. If some of that new code is a flag that controls what customers see, then from a product perspective it’s not a “product release”. Is that what you mean? The point is, even feature-flagged code can break things unexpectedly.

_vertigo 4y ago

What is the difference between deploying and releasing? Everywhere I’ve worked, those are the same thing. We deploy probably 10 to 30 times a workday. As for Friday deployments, I tend to avoid deploying big changes on Friday but medium and small are probably fine Friday unless it’s the very end of the day.

pondidum 4y ago
From the link further up the replies: > Deploy is the act of moving software into an environment and running it. > Release is the process of making a feature visible to a user or subset of users. In our case, we deploy often (10s of times per day), and make use of feature flags for releasing. Keeping an eye on data in Honeycomb before and after a deployment and before and after a flag is changed is part of the engineers job. If something doesn't look like it's working as intended, ideally it is disabled with a flag, rather than needing to figure out how a rollback can be done (often it can't), or rushing a fix and roll forward.
- FridgeSeal 4y ago
  This is a pretty small distinction in my experience, and I think you'd find that most people would go with "if it goes into prod, it counts as a release". Regardless of how confident you are on your feature-flagging functionality, everyone's going to be unimpressed if suddenly your "minor" deploy has caused a bunch of things to go haywire at 4:30pm on a Friday and now people have to stay back and fix things.

snowwrestler 4y ago

If you put new code into production, that is a deployment and an engineering release. If some of that new code is a flag that controls what customers see, then from a product perspective it’s not a “product release”. Is that what you mean? The point is, even feature-flagged code can break things unexpectedly.