4 ms·

For me the biggest take away from this thread is the distinction between release, deploy, and launch. So no matter how good or bad your CI/CD process is, you ca

by rudasn 5y ago

For me the biggest take away from this thread is the distinction between release, deploy, and launch. So no matter how good or bad your CI/CD process is, you can still control what gets launched, when, and to whom. I did not know about the term as such, but after reading about it I realised that it's something that our very small team (< 5) has been doing as a way to make sure that new stuff doesn't break production (eg switching major dependencies). I can see how being more formal about it can help small teams, especially when they want to have high velocity but do not the capacity to test the hell out of everything, or simply have to support alternate features at the same time.

bluefirebrand 5y ago
We manage this with branches in git. I think if you don't want certain features on production it's better to just not have them in the production branch. Putting them behind a feature flag always allows for a misconfiguration where suddenly a half built feature is visible and broken in production. It might be a small risk, but why take it?
- rudasn 5y ago
  > think if you don't want certain features on production it's better to just not have them in the production branch Totally agree. In our case however, we used a feature flag when launching a new feature for the first time (a new way to render pdfs) that depended heavily on Per-customer configuration (eg their letterhead/logo) and on the data being rendered, that also had very strict requirements (number of pages, etc). The only to "test" this was in production and it's something that must be reversible in an instant by us or the particular client (ie no redeployment or anything like that). I guess it depends on the context as well, since we do b2b and on-prem, so there's no such thing as "move fast and break things". Our clients actually require slow moving, incremental, updates that never break things, and it's a bit of a pain for us to do deployments / updates (it takes time, even if kind of automated/scripted).
  - bluefirebrand 5y ago
    See, and that's an entirely reasonable scenario to require feature flags for. In my mind it's always been a thing to add only when you actually need to toggle a feature without a deploy. Certainly not something to sprinkle in your code liberally. A lot of people in this thread seem to disagree and I find it fairly baffling.

by rudasn 5y ago

bluefirebrand 5y ago

We manage this with branches in git. I think if you don't want certain features on production it's better to just not have them in the production branch. Putting them behind a feature flag always allows for a misconfiguration where suddenly a half built feature is visible and broken in production. It might be a small risk, but why take it?

rudasn 5y ago
> think if you don't want certain features on production it's better to just not have them in the production branch Totally agree. In our case however, we used a feature flag when launching a new feature for the first time (a new way to render pdfs) that depended heavily on Per-customer configuration (eg their letterhead/logo) and on the data being rendered, that also had very strict requirements (number of pages, etc). The only to "test" this was in production and it's something that must be reversible in an instant by us or the particular client (ie no redeployment or anything like that). I guess it depends on the context as well, since we do b2b and on-prem, so there's no such thing as "move fast and break things". Our clients actually require slow moving, incremental, updates that never break things, and it's a bit of a pain for us to do deployments / updates (it takes time, even if kind of automated/scripted).
- bluefirebrand 5y ago
  See, and that's an entirely reasonable scenario to require feature flags for. In my mind it's always been a thing to add only when you actually need to toggle a feature without a deploy. Certainly not something to sprinkle in your code liberally. A lot of people in this thread seem to disagree and I find it fairly baffling.