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

81–90 of 124 posts

Re: When deployments are easy, code becomes simpler

#81

Post by mrweasel »

onetimeuse92304 wrote: post #77
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…

Not saying it is a bad idea, but the way it works is it ensures certain things happen that you would normally want to happen, namely: * test of a rollback procedure, * developers thinking about backwards compatibility and rollback procedure. The main issue I see with this approach is that the test of the rollback is only partial. Just because the schema is usable by the previous version of the application does not me…

> Another issue I am seeing is that it is not a separate testing event but essentially happening live when the application is turned on on production. Not nice.

It's a testing event if you make it a testing even. The team I'm referring to regularly makes a dump from production, run it through a PII anonymizer and performs migration test on that.

Re: When deployments are easy, code becomes simpler

#82

Post by robertlagrant »

mrweasel wrote: post #80
steffres wrote: post #76

Earlier quoted context omitted.

I see. Thanks for the clarifications. And these DB migrations, did your team keep a history of them? If so, did you manage them yourselves, or did you use some tools like flyway? I'm asking because I'm starting a project where we will manage the persistence SQL layer without any ORM (always did it so far with Django's migrations), but might consider some third party tools for DB migrations.

The way I've seen it work is hand written SQL for the migrations, numbered and tracked in Git. There shouldn't be any reason that you can't do it with Flyway, but I would be concerned about fighting Flyway a bit. I use Django a fair bit and I honestly don't see a good way to make this approach work for Django, not suggesting that you can't, but you would be fighting Django a fair bit, it's not really how it's designe…

Django has migrations; why would this be harder with Django?

Re: When deployments are easy, code becomes simpler

#83

Post by steffres »

mrweasel wrote: post #80
steffres wrote: post #76

Earlier quoted context omitted.

I see. Thanks for the clarifications. And these DB migrations, did your team keep a history of them? If so, did you manage them yourselves, or did you use some tools like flyway? I'm asking because I'm starting a project where we will manage the persistence SQL layer without any ORM (always did it so far with Django's migrations), but might consider some third party tools for DB migrations.

The way I've seen it work is hand written SQL for the migrations, numbered and tracked in Git. There shouldn't be any reason that you can't do it with Flyway, but I would be concerned about fighting Flyway a bit. I use Django a fair bit and I honestly don't see a good way to make this approach work for Django, not suggesting that you can't, but you would be fighting Django a fair bit, it's not really how it's designe…

I didn't mean to use Django _and_ a separate migration tool. It's just that I did work with Django so far, but switching now to a new codebase without it. Hence my question for experiences in DB migration.

Re: When deployments are easy, code becomes simpler

#84

Post by politelemon »

hsn915 wrote: post #51
daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

Is "feature flag as a service" the new trend in backend development? Why would anyone replace a literal byte in memory with a full program? Why?

I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.

Re: When deployments are easy, code becomes simpler

#85

Post by gonzan »

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…

I agree with all this and it’s how I do it for web development but the time Apple/Google take to approve apps makes doing this for mobile apps quite risky since it’s hard to rollback.

I guess it goes to the point of the author that hard deployments on mobile makes mobile development harder

Re: When deployments are easy, code becomes simpler

#86

Post by azlev »

steffres wrote: post #83
mrweasel wrote: post #80

Earlier quoted context omitted.

The way I've seen it work is hand written SQL for the migrations, numbered and tracked in Git. There shouldn't be any reason that you can't do it with Flyway, but I would be concerned about fighting Flyway a bit. I use Django a fair bit and I honestly don't see a good way to make this approach work for Django, not suggesting that you can't, but you would be fighting Django a fair bit, it's not really how it's designe…

I didn't mean to use Django _and_ a separate migration tool. It's just that I did work with Django so far, but switching now to a new codebase without it. Hence my question for experiences in DB migration.

At work we use Django migrations. It helps. But the core of schema evolution is backward compatibility. To reach this goal, code review is necessary.

Here we never drop columns, only add new colunms, also never change column types.

When it comes to constraints (not null or something else) we double check about backwards compatibility.

Changing data is not a robust rollback.

Re: When deployments are easy, code becomes simpler

#87

Post by perrygeo »

mcny wrote: post #27
ljm wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: When deployments are easy, code becomes simpler

#88

Post by oftenwrong »

mvdtnz wrote: post #37
daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.

Multiple apps can access a single database, so where's the problem?

Re: When deployments are easy, code becomes simpler

#89

Post by mrweasel »

robertlagrant wrote: post #82
mrweasel wrote: post #80

Earlier quoted context omitted.

The way I've seen it work is hand written SQL for the migrations, numbered and tracked in Git. There shouldn't be any reason that you can't do it with Flyway, but I would be concerned about fighting Flyway a bit. I use Django a fair bit and I honestly don't see a good way to make this approach work for Django, not suggesting that you can't, but you would be fighting Django a fair bit, it's not really how it's designe…

Django has migrations; why would this be harder with Django?

The migrations is fairly tightly couple to the code. You can apply the migrations without deploying new code, if you extract the migrations, but now you have at least two branches in your version control, both of which are technically in production. You have the version that's actually running, and you have the version with the model changes and the migrations, from which you extracted the migrations and applied to the database.

I'd argue that because you're making the migrations from the model, it's also easier to do accidentally create migrations that are not independent of the code version.

Re: When deployments are easy, code becomes simpler

#90

Post by robertlagrant »

mrweasel wrote: post #89
robertlagrant wrote: post #82

Earlier quoted context omitted.

Django has migrations; why would this be harder with Django?

The migrations is fairly tightly couple to the code. You can apply the migrations without deploying new code, if you extract the migrations, but now you have at least two branches in your version control, both of which are technically in production. You have the version that's actually running, and you have the version with the model changes and the migrations, from which you extracted the migrations and applied to t…

Hm, but isn't that right? You make your change in code, which doesn't touch your models (except you're no longer using the column you'd like to deprecate), and deploy that; show it's working. Then you make another change to actually remove the column from the models and generate a migration. Then you deploy that version, which migrates the db and runs your new model code?

(You could in theory remove the column but not merge the migration if you wanted to show your code worked fully without that column in your ORM model before removing it from the DB as well?)

Post reply on HN