FAQs
As long as you replay the queries in the expected order, and do not update remote environments manually, thus creating new rows that lower environments do not know about, you shouldn't have any issues with executing migrations. If avoiding key collisions is a concern, there are advanced configurations you do to each of your MySQL databases to adjust the
auto_increment_increment and auto_increment_offset values.What if my production site has newer, user generated content then my dev or staging site?
Trek is currently designed to migrate data in a single direction: from a lower environment (dev/stage) to a higher environment (prod). If you are creating new channels, custom fields, and entries in your dev environment, and users are creating new entries in production, then Trek may not work out for you. If you are creating new channels or custom fields, but not creating entries in a lower environment, then you may be able to take advantage of Trek to push those changes to production. Basically the unique ID situation previously mentioned becomes an issue.
No, you don't have to install Trek on a site from the beginning. You can start creating migrations and releases at any time. When you install Trek on an existing site, probably your development or staging site, make sure that site database is a recent copy of your production site, then you can start making changes in your development site, and pushing them straight to production.
This is one of the goals of Trek, but at the time of this writing (before Trek has even been released) this specific scenario has not been tested. If you refer to Trek's config array, you'll notice that every model is set to true, meaning all site config (channels, channel fields, category groups etc) as well as content (entries, categories, and members) are set to be migrated.
Last modified 3yr ago