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

Verify the schema.rb integrity when running our CI #5009

Merged
merged 1 commit into from
Oct 10, 2022
Merged

Conversation

javierm
Copy link
Member

@javierm javierm commented Oct 8, 2022

References

Objectives

  • Avoid adding a wrong version of the schema.rb file to version control
  • Avoid broken databases on production after adding multitenancy

Release Notes

TODO: when we release a version including multitenancy, emphasize the convinience of running this task on your CI.

In the past, we've run into situations where we commited a version of
the schema.rb to version control which wasn't in sync with what you get
when you create the database and run the migrations. This is something
that might happen if you're working on different branches at the same
time, run the migrations in all those branches, and then commit the
current status of your database to your current branch. That will result
in a schema file which contains the database changes done in all these
branches instead of just the current one.

Although this hasn't happened to us for years, we see it happening
sometimes in other COSUL installations, and there's always a chance that
we make a mistake and do it again.

Until now, it wasn't a big deal because the installer sets up the
database by running `db:create db:migrate`, which runs the migrations
instead of using the `schema.rb` file.

However, we're going to add multitenancy using the Aparment gem, and
this gem uses the `schema.rb` file when creating a new schema for a new
tenant [1]. If the `schema.rb` file contains changes that shouldn't be
there, this will lead to different database schemas having different
tables and/or columns and future migrations might crash on production
when applied to some of these schemas. In other words, this mistake
could now result in a disastrous situation.

To help preventing that, we're adding a CI workflow that checks the
current `schema.rb` file is in sync with the database migrations.

[1] https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f#7e97
@javierm javierm self-assigned this Oct 8, 2022
@javierm javierm added this to Reviewing in Consul Democracy Oct 8, 2022
@taitus taitus self-assigned this Oct 10, 2022
Consul Democracy automation moved this from Reviewing to Testing Oct 10, 2022
@javierm javierm merged commit 9ba7204 into master Oct 10, 2022
Consul Democracy automation moved this from Testing to Release 1.6.0 Oct 10, 2022
@javierm javierm deleted the check_schema branch October 10, 2022 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants