Initial one-time setup
skeema init productionto import schemas from your master database instance. If you have multiple database pools, repeat this step for each one.
In the host directory created in step 1, use
skeema add-environment developmentto configure the connection information for your dev environment. This can either be a central shared dev database (-h some.host.name, along with -P 1234 if using non-3306 port), or perhaps a separate database running locally on each engineer's dev server reached via UNIX domain socket (-h localhost -S /path/to/mysql.sock).
If you have additional environments such as "staging", use
skeema add-environmentto configure connection information for them as well. Environment naming is completely arbitrary; no need to strictly use "production", "development", and "staging". Just be aware that "production" is the default for all Skeema commands if no environment name is supplied as the first positional arg on the command-line.
Add all of the generated directories and files to a git repo. This can either be a new repo that you create just for schema storage, or it can be placed inside of a corresponding application repo.
If you have large tables, configure Skeema to use an external online schema change tool. Configure the
alter-wrappersetting in a
.skeemafile in the top dir of your schema repo. See FAQ for more information.
Updating dev environment with changes from other engineers
If each engineer has their own local dev database, they can use Skeema to pull in changes made by other team members.
git pullon whichever repo contains schemas
skeema diff developmentto see what changes would be applied in the next step
skeema push developmentto apply those schema changes
Schema change process
Steps 1-3 are performed by a developer. Steps 4-6 can be performed by a developer or by a DBA / devops engineer, depending on your company's preferred policy.
Check out a new branch in your schema repo.
Test the schema change in dev, and update the corresponding files in the repo. There are a few equivalent ways of doing this:
a) If using a migration tool from an MVC framework (Rails, Django, etc): Run the migration tool on dev as usual. Then use
skeema pull development to update the table files in the repo.
b) If you prefer running DDL manually: Run the statement(s) in dev. Then use
skeema pull development to update the table files.
c) If you prefer to just change the CREATE TABLE files: Modify the files as desired. Use
skeema diff development to confirm the auto-generated DDL looks sane, and then use
skeema push development to update the dev database.
Commit the change to the repo, push to origin, and open a pull request. Follow whatever review process your team uses for code changes.
git checkout masterand
git pullto ensure your working copy of the schema repo is up-to-date.
skeema diff productionto review the list of DDL that will need to be applied to production.
skeema push productionto execute the schema change.