dev:sqitch
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dev:sqitch [2015/12/29 11:08] – erickson | dev:sqitch [2022/02/10 13:34] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== Using Sqitch with Evergreen ==== | + | ===== Using Sqitch with Evergreen |
See also[[https:// | See also[[https:// | ||
- | === Getting Started === | + | ==== Getting Started |
- | == Install Sqitch == | + | === Install Sqitch |
< | < | ||
Line 13: | Line 13: | ||
</ | </ | ||
- | == Install Base Schema == | + | === Install Base Schema |
- | - Install the latest working branch from LP 1521693 | + | Install the latest working branch from LP 1521693 |
- | - Alternatively, | + | |
- | < | + | ==== Creating an Upgrade Script |
- | $ cd Open-ILS/ | + | |
- | $ sudo -u postgres psql --set db_name=evergreen -f tools/ | + | |
- | </ | + | |
- | + | ||
- | === Creating an Upgrade Script === | + | |
For this example, we're cross-porting an existing SQL upgrade script for LP #1319998. | For this example, we're cross-porting an existing SQL upgrade script for LP #1319998. | ||
Full code is tracked in [[http:// | Full code is tracked in [[http:// | ||
+ | |||
+ | **Override Sqitch DB connections parameters the sqitch flags --db-host, --db-name, --db-port, and --db-user. | ||
< | < | ||
Line 36: | Line 32: | ||
</ | </ | ||
- | * The --requires flag specifies which commit | + | * The --requires flag specifies which existing target |
* -n specifies a Sqitch " | * -n specifies a Sqitch " | ||
Line 48: | Line 44: | ||
</ | </ | ||
- | * The deploy/ file includes our new change | + | * The deploy/ file includes our new change. The structure of the file is practically identical to our existing upgrade/ |
* The revert/ file includes SQL that allows us to roll back the changes in the deploy script. | * The revert/ file includes SQL that allows us to roll back the changes in the deploy script. | ||
- | * For example, when deploying a modified function, as is the case with this example, the revert/ file will include the original | + | * For example, when deploying a modified function, as is the case with this example, the revert/ file will include the original |
* The verify/ file contains SQL to confirm the changes in the deploy/ file were properly deployed. | * The verify/ file contains SQL to confirm the changes in the deploy/ file were properly deployed. | ||
For example, see the contents of these 3 files at [[http:// | For example, see the contents of these 3 files at [[http:// | ||
- | === Deploying an Upgrade Script === | + | ==== Deploying an Upgrade Script |
* Sanity check the status first | * Sanity check the status first | ||
Line 90: | Line 86: | ||
- schema.materialized_billing_summary_delete_trigger .. ok | - schema.materialized_billing_summary_delete_trigger .. ok | ||
</ | </ | ||
+ | |||
+ | ==== Resolving Conflicts / Deploying Multiple Plan Files ==== | ||
+ | |||
+ | **AKA " | ||
+ | |||
+ | When deploying changes, Sqitch inspects both the name and position of each target in the sqitch.plan file. A Sqitch install target is a product of its name and which target precedes it. (This is similar to Git commits). I had originally assumed only the name of the change mattered, so this was unexpected. | ||
+ | |||
+ | In an environment where changes are always deployed linearly, like a production database, this has no bearing. | ||
+ | |||
+ | < | ||
+ | # On database evergreen | ||
+ | # Project: | ||
+ | # Change: | ||
+ | # Name: | ||
+ | # Deployed: 2016-03-30 10:16:33 -0400 | ||
+ | # By: Bill Erickson < | ||
+ | # | ||
+ | Cannot find this change in sqitch.plan | ||
+ | Make sure you are connected to the proper database for this project. | ||
+ | </ | ||
+ | |||
+ | |||
+ | The solution is to revert any Sqitch targets that are not shared by both branches. | ||
+ | |||
+ | < | ||
+ | sqitch revert --to < | ||
+ | </ | ||
+ | |||
+ | Or they can be virtually rolled back by telling Sqitch to pretend like they were reverted using | ||
+ | |||
+ | < | ||
+ | sqitch revert --log-only --to < | ||
+ | </ | ||
+ | |||
+ | The **--log-only** option tells Sqitch to update its tracking tables without executing any deploy/ | ||
+ | |||
+ | === Example === | ||
+ | |||
+ | - Deploy sqitch.plan with changes A, B, and C. | ||
+ | - Checkout another Git branch with a sqitch.plan file containing changes A, B, D. | ||
+ | - ' | ||
+ | - Revert all offending changes: | ||
+ | < | ||
+ | # roll back the change. | ||
+ | sqitch revert --to B | ||
+ | |||
+ | # OR just tell Sqitch to ignore the change. | ||
+ | sqitch revert --to B --log-only | ||
+ | </ | ||
+ | - Deploy change D | ||
+ | < | ||
+ | sqitch deploy | ||
+ | </ | ||
+ | |||
+ | The same steps will work when returning to the original branch w/ changes A, B, and C. | ||
+ | |||
+ | === The --merge option === | ||
+ | |||
+ | Version 1.1.0 of Sqitch [[https:// | ||
+ | |||
+ |
dev/sqitch.1451405280.txt.gz · Last modified: 2022/02/10 13:34 (external edit)