Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When deployments are easy, code becomes simpler

bitbytebit.substack.com

Post reply on HN
Print view View original

21–30 of 124 posts

Re: When deployments are easy, code becomes simpler

#21

Post by hinkley »

rvrs wrote: post #18
mvdtnz wrote: post #17

Earlier quoted context omitted.

I'd rather have unfinished feature flagged code in master (and therefore production) than have the same unfinished code withering in a long running branch, diverging from master and causing integration problems later. > Either finish your work or delete the unneeded code. It's work in progress. We're working on getting it finished.

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or,…

Somewhere along the way, a new generation of developers thought that 'Continuous Integration' means "automated builds". I wonder what they think that 'integration' word is doing there?

Since you're here, I'll ask you. What do you think 'integration' means in this context?

Re: When deployments are easy, code becomes simpler

#22

Post by hinkley »

erik_seaberg wrote: post #6
bsima wrote: post #4

> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…

“Unfinished” can mean abandoned, but it can also mean half-baked code that has been pushed to master even though it’s still actively being developed and is nowhere near ready to run. Personally I prefer long-lived feature branches; this is a risk with no payoff. As for experimentation, I like percentage rollouts with segregated control/treatment group metrics. I agree that trivial on/off flags should be replaced by c…

Companies have an expectation that most of the code they paid for will eventually ship. Pretending like code might not ever be finished is an odd choice.

The exception is experimental work. Obviously experiments aren't being merged into master, so they don't need to be included in the arithmetic for any processes that eventually involve master.

Re: When deployments are easy, code becomes simpler

#23

Post by rvrs »

hinkley wrote: post #21
rvrs wrote: post #18

Earlier quoted context omitted.

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or,…

Somewhere along the way, a new generation of developers thought that 'Continuous Integration' means "automated builds". I wonder what they think that 'integration' word is doing there? Since you're here, I'll ask you. What do you think 'integration' means in this context?

"Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment claimed that there are readability and usability concerns with unfinished code. This is why we have code review. CI is a signal that the code is good to merge, but as a code reviewer, I have the final say. I don't merge unfinished code.

If CI passes on your branch but later fails due to lagging behind master, it is on you to get it working before re-requesting review.

PS: The HN guidelines clearly state "Be kind. Don't be snarky." (:

Re: When deployments are easy, code becomes simpler

#24

Post by ljm »

dmoy wrote: post #2

> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool. Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot o…

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

Re: When deployments are easy, code becomes simpler

#25

Post by gizmo686 »

bsima wrote: post #4

> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…

Some changes are too big to fit into a effort. A few years ago, I was working on a niche compiler. When the project was first started, the decision was made to inline everything, greatly simplifying the rest of the compiler [0]. This decision had served us well for the better part of its then 17 year lifetime, but was finally starting to cause issues with compile time and memory usage. One of our senior developers, who was intimately familiar with the project, tried on several occasions to allow for things to not get inlined. However, he kept having to give up as it was a low priority background task, and his branch would diverge from the main branch faster than he could keep his up to date.

The solution ended up being a rather simple feature flag. Within a few days, he coded a flag that would enable not-inlinging; and updated our test infastructure to look for regressions on unit tests with the flag enabled. Going forward, developers we responsible for making sure their changes didn't cause regression when the flag was enabled; and everyone was able to slowly chip away at everything the feature broke when they had spare cycles.

What would have been a major stop-the-world refactor with our most senior engineers, turned into a slow moving non-issue.

[0] Lack of turing completeness was and remains an explicit design goal, so recursion was explicitly forbidden.

Re: When deployments are easy, code becomes simpler

#26

Post by gizmo686 »

rvrs wrote: post #23
hinkley wrote: post #21

Earlier quoted context omitted.

Somewhere along the way, a new generation of developers thought that 'Continuous Integration' means "automated builds". I wonder what they think that 'integration' word is doing there? Since you're here, I'll ask you. What do you think 'integration' means in this context?

"Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment claimed that there are readability and usability concerns with unfinished code. This is why we have code review. CI is a signal that the code is good to merge, but as a code reviewer, I have the final say. I don't merge unfinished code. If CI passes on your bra…

Continous Integration is a development methodology, not an automated process. The idea is that developers continuously merge their changes into a shared integration branch. Having long running feature branches that get merged when they are done is a valid methodology, but it is not continuous integration; no matter what your automated build and test pipeline calls it.

In practice, I have typically seen CI done with either feature freezes, or release branches to allow creating versions where everything is complete.

Re: When deployments are easy, code becomes simpler

#27

Post by mcny »

ljm wrote: post #24
dmoy wrote: post #2

> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool. Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot o…

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

I always say this - there is no such thing as a rollback. Anyone who pretends you can simply "roll back" a stateful application is out of their mind.

If you can roll back and forward events, good for you but for most of us rollbacks are actually a new build, deployment, and a new set of tests. Every single time.

Re: When deployments are easy, code becomes simpler

#28

Post by ajkjk »

digging wrote: post #9
smokel wrote: post #8

I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time. Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the p…

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated. I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

Strongly disagree this is a junior dev thing. Most of the terribly complex abstractions are, in my experience creates by people who have enough seniority that others can't easily question them. There are good devs and bad devs, and there are junior and senior devs, but it's the first axis that determines code quality.

Re: When deployments are easy, code becomes simpler

#29

Post by javajosh »

Easy deployments are great, and all too rare. But feature flags are good too. It's actually a trade-off between determinism and control. No flags make the blob deterministic; flags give you control over the blob very late in its runtime. In the limit your feature flags might be set by an admin endpoint (which is very common, actually).

But the OP's real issue is git, and not wanting to work on a branch. I actually think that's a valid goal! I've noticed that many teams have simply moved "one level up" with their git usage. The repo is the new directory; the push is the new commit; etc. You can practice and get fast with it, but it's still too many moving parts and plenty of things to go wrong. I actually think that feature flags are too coarse anyway to block off incomplete code; you should probably use conditionals for incomplete code, even if you also have robust feature flag support. The reason is that you never, ever want to dynamically turn incomplete code on, so coupling the flag to a deployment makes perfect sense.

Re: When deployments are easy, code becomes simpler

#30

Post by eddd-ddde »

erik_seaberg wrote: post #6
bsima wrote: post #4

> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…

“Unfinished” can mean abandoned, but it can also mean half-baked code that has been pushed to master even though it’s still actively being developed and is nowhere near ready to run. Personally I prefer long-lived feature branches; this is a risk with no payoff. As for experimentation, I like percentage rollouts with segregated control/treatment group metrics. I agree that trivial on/off flags should be replaced by c…

Personally, long-lived branches feel like disaster waiting to materialize since by definition they do not integrate with upstream.

Yeah, you might be really responsible and rebase and test your feature frequently, but what about other people? They are more likely to break the integration with your code since they can't even see it.

Post reply on HN