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

111–120 of 124 posts

Re: When deployments are easy, code becomes simpler

#111

Post by nicoburns »

steffres wrote: post #73
mrweasel wrote: post #49

Earlier quoted context omitted.

One of the very best development teams I worked with had an interesting take, they always did database migrations first. Any new state that was to be added to the system could only be done so by first adding the new database fields or tables. This ensure that version 1 of the code would work with version 1 and 2 of the database. They would then roll out version 2 of the code, but have the new features hidden behind a…

That sounds reasonable. But what about the case where the DB migration of version 2 would be incompatbile with code version 1, e.g. a column was dropped?

You do it in two stages. Add as new column, deploy code that uses it and no longer use the old column. Then later drop the column once nothing is using it anymore.

Re: When deployments are easy, code becomes simpler

#112

Post by nicoburns »

perrygeo wrote: post #87
mcny wrote: post #27

Earlier quoted context omitted.

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.

The system can only move forwards. Just like a `git revert`, it's a new commit to an immutable history. This is why I've never used or understood the value of the "downgrade" feature in some database migration tools. If you need to revert, make a _new_ migration that fixes the problem. Your tooling/code/logs should reflect the true history of the system without cooking the books.

I’ve found “downgrade” mostly useful for quick iteration during local development (where you may well not care about lost data). Realise your initial cut of the migration wasn’t quite right? Run “down” then fix it, then “up” again.

Re: When deployments are easy, code becomes simpler

#113

Post by nicoburns »

ajkjk wrote: post #28
digging wrote: post #9

Earlier quoted context omitted.

> 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.

Hmmm… well it certainly was for me. My code has gotten a lot simpler over time!

Re: When deployments are easy, code becomes simpler

#114

Post by wrsh07 »

WorldMaker wrote: post #108
wrsh07 wrote: post #98

> Much of the time I’m using flags so I can commit unfinished code There are two interpretations of this, and I find one of them horrifying 1. I'm working on a feature, I need to update multiple components, so I make small changes for each component and feature flag those (this is fine! Totally normal) 2. I commit code that doesn't work because I'm unwilling to use or understand git The second of these scares the cra…

"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a git branch hundreds of commits behind and full of merge issues. It's something of a "different strokes" preference and it's something of a question of how fast the main branch is moving and how hard to keep up with it. Most language compilers and JITs elimina…

I would strongly recommend learning git basics!

My branches are never more than a day behind main (rebase does wonders!)

Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!

Re: When deployments are easy, code becomes simpler

#115

Post by perrygeo »

OJFord wrote: post #94
perrygeo wrote: post #87

Earlier quoted context omitted.

The system can only move forwards. Just like a `git revert`, it's a new commit to an immutable history. This is why I've never used or understood the value of the "downgrade" feature in some database migration tools. If you need to revert, make a _new_ migration that fixes the problem. Your tooling/code/logs should reflect the true history of the system without cooking the books.

In what sense is 'downgrade' not just that prepared ahead of time? Or do you just not like the name? Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.

downgrade implies that such a thing is possible. In a stateful system though, you cannot take back that which you have committed. It's quite literally impossible by definition.

Re: When deployments are easy, code becomes simpler

#116

Post by pharmakom »

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…

In game dev there was a saying like “you’re writing the game in C# so just write the game logic in C#” rather than making a run-time configurable / scriptable monolith

Re: When deployments are easy, code becomes simpler

#117

Post by WorldMaker »

wrsh07 wrote: post #114
WorldMaker wrote: post #108

Earlier quoted context omitted.

"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a git branch hundreds of commits behind and full of merge issues. It's something of a "different strokes" preference and it's something of a question of how fast the main branch is moving and how hard to keep up with it. Most language compilers and JITs elimina…

I would strongly recommend learning git basics! My branches are never more than a day behind main (rebase does wonders!) Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!

There's still a difference between commented code because it is dead and bitrot and code-in-progress. I am among the first people to delete commented code and send anyone looking for it to git tutorials, but I've also kept git branches short by keeping code behind if flags (that are false in builds/production) while working on it so that I can still give that code the benefit of other refactors or compile errors and so that other developers are aware of that partially complete code.

It's not a dichotomy, it's an orthogonal spectrum. Of course it is hugely useful to be good at source control. Of course it is still sometimes useful to have code compiling in CI/CD that "isn't ready yet" but prone to cross-fire in other on going work and refactoring. (Plus source control is greatly useful for answering "Why is this flag false right now? Who was last working on it and for what project?" and keeping that code honest that it isn't just bit rot.)

Re: When deployments are easy, code becomes simpler

#118

Post by OJFord »

perrygeo wrote: post #115
OJFord wrote: post #94

Earlier quoted context omitted.

In what sense is 'downgrade' not just that prepared ahead of time? Or do you just not like the name? Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.

downgrade implies that such a thing is possible. In a stateful system though, you cannot take back that which you have committed. It's quite literally impossible by definition.

No it isn't?

Forward migration: add date column, set = date(day, month, year) for existing records, drop is valid date constraint, drop day/month/year columns

Down migration: add day/month/year columns, add is valid date constraint, set day/month/year = appropriate datepart of date, drop date column

for trivial example.

Re: When deployments are easy, code becomes simpler

#120

Post by zaphirplane »

jaimebuelta wrote: post #75
steffres wrote: post #73

Earlier quoted context omitted.

That sounds reasonable. But what about the case where the DB migration of version 2 would be incompatbile with code version 1, e.g. a column was dropped?

You NEVER do that in one go, you need to split it in several deployments. Dropping a column is relatively straightforward, in two steps. First deploy a version of the code that doesn’t use the column, then release the migration dropping the column. The typical example is the renaming of a column, which needs to be done in several steps: 1. Create the new column, copying the data from the old column (DB migration) bot…

What about new rows added during step 0 - 2
Post reply on HN