diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-06 15:07:43 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-06 15:07:43 +0300 |
| commit | d5e68dfae835516bcc94d208cd7be461e75831ff (patch) | |
| tree | b4bd3d748b530d1129a753f98c90142f943bd2c8 /doc/development/migration_style_guide.md | |
| parent | 22856b87805d4e6fe92eee6e9ae3dcdebb75c3f3 (diff) | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/migration_style_guide.md')
| -rw-r--r-- | doc/development/migration_style_guide.md | 17 |
1 files changed, 14 insertions, 3 deletions
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md index 41b3b9ed428..62e797276c1 100644 --- a/doc/development/migration_style_guide.md +++ b/doc/development/migration_style_guide.md @@ -19,8 +19,8 @@ Migrations are **not** allowed to require GitLab installations to be taken offline ever. Migrations always must be written in such a way to avoid downtime. In the past we had a process for defining migrations that allowed for downtime by setting a `DOWNTIME` constant. You may see this when looking at -older migrations. This process was in place for 4 years without every being -used and as such we've learnt we can always figure out how to write a migration +older migrations. This process was in place for 4 years without ever being +used and as such we've learned we can always figure out how to write a migration differently to avoid downtime. When writing your migrations, also consider that databases might have stale data @@ -35,10 +35,21 @@ For GitLab.com, please take into consideration that regular migrations (under `d are run before [Canary is deployed](https://gitlab.com/gitlab-com/gl-infra/readiness/-/tree/master/library/canary/#configuration-and-deployment), and [post-deployment migrations](post_deployment_migrations.md) (`db/post_migrate`) are run after the deployment to production has finished. +## Create database migrations + +To create a migration you can use the following Rails generator: + +```shell +bundle exec rails g migration migration_name_here +``` + +This generates the migration file in `db/migrate`. + ## Schema Changes Changes to the schema should be committed to `db/structure.sql`. This -file is automatically generated by Rails, so you normally should not +file is automatically generated by Rails when you run +`bundle exec rails db:migrate`, so you normally should not edit this file by hand. If your migration is adding a column to a table, that column is added at the bottom. Please do not reorder columns manually for existing tables as this causes confusion to |