Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate automatically on service start #7103

Merged
merged 1 commit into from
Jan 30, 2024
Merged

Migrate automatically on service start #7103

merged 1 commit into from
Jan 30, 2024

Conversation

ConradIrwin
Copy link
Member

This avoids a forgettable manual step in deploying collab

Release Notes:

  • N/A

This avoids a forgettable manual step in deploying collab
@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Jan 30, 2024
@maxdeviant
Copy link
Member

Is there another way we can achieve the same thing (avoiding the need to remember to run migrations)?

I've seen issues with running migrations on server startup that led to production outages.

@maxdeviant
Copy link
Member

maxdeviant commented Jan 30, 2024

Is there another way we can achieve the same thing (avoiding the need to remember to run migrations)?

I've seen issues with running migrations on server startup that led to production outages.

How I've solved this in the past is having a separate step that runs during the deployment pipeline that runs the migrations, and then only attempts the deploy when they succeed. This does require that migrations are backwards-compatible (which I believe ours are), but it means that a bad migration (e.g., one that times out) will get caught before we deploy the new version and get stuck in a failure loop when trying to run migrations when the app comes up.

I haven't familiarized myself with our deployment pipeline yet, so not sure what is easily doable.

@ConradIrwin
Copy link
Member Author

I like the idea of doing this as part of a build, it would also be nice to get the logs (which this doesn't let you do).

I've also run in production with this setup quite successfully; and I think with the migration linter we added, it should be a reasonable risk trade-off: Typically the worst that happens is the new release gets stuck in a crash loop while the old one continues to serve traffic (though I haven't verified that this happens yet, I was going to do some monkeying around on staging).

I think the ideal next step is that Github Actions deploys collab automatically; so we could defactor this when we do that and do it in separate steps (but I don't like that it makes the happy path of slower).

@maxdeviant
Copy link
Member

Typically the worst that happens is the new release gets stuck in a crash loop while the old one continues to serve traffic (though I haven't verified that this happens yet, I was going to do some monkeying around on staging).

True, I guess it does depend on the rest of our architecture, and whether services stuck in a crash loop can receive traffic (which was the case on Heroku).

@ConradIrwin
Copy link
Member Author

Let's give it a go :D

@ConradIrwin ConradIrwin merged commit 911b4b5 into main Jan 30, 2024
6 checks passed
@ConradIrwin ConradIrwin deleted the auto-migrate branch January 30, 2024 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed The user has signed the Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants