3

Currently each time we make changes to our dev instance of our Craft install (add fields, plugins, change settings in CP), we dump the database and upload it to the production database server. This gets messy now that our production database is accepting guest entries. We obviously do not want to overwrite those changes.

Is there a recommend workflow for this situation.

2

If your production server is getting user-generated content, then your best bet is to just keep track of changes you make, and redo them manually on production. Probably not what you wanted to hear, and we would love to have a better solution for you down the road, but it’s a pretty far way away. Maybe someone will write a plugin that helps in the meantime.

| improve this answer | |
3

Joining in at this point. We have some sites powered by Craft which need to get some updates. Its absolutely acceptable if the dev version is outdated regarding the content. Making content changes should not be our job, and we mostly work with placeholder and testing content anyway.

The whole next procedure is optional, so enabling this behavior with a config param (or auto-enable when using dev-mode) might be the best idea.

Best would be to write structural changes along with non-content-related settings like asset transforms, plugin settings etc into a file called "_migrations.sql".

Before pushing an update from "dev" to "production", you simply need to press a "increment database structure version" button which then renames the file to "migrations-($v+1).sql". Also the version number in the database gets incremented so the saved version number is directly up-to-date with latest migration file version number.

If an update then goes live, the production database will be behind latest migration file version and executes them like the craft migrations do, incrementing the structure version in database too. Database will be fully up-to-date at this point without overwriting or changing any entry or asset.

In combination with git we could put these migration files under version control so they get part of the commit without committing all the other trash that changed in the database while working on it.

As long as this is not possible from Craft itself, a dump must be made before and after changes are made and manually processed to create migration by hand, which also must be manually executed on production environment. Depending on the amount of changes this can be very frustrating and time consuming.

Making the web developers spend less time and struggling on daily problems would cause more time for more projects to be made with craft. A win-win situation on both sides.

| improve this answer | |
  • I agree with the proposal, it's pretty much how Rails does database migrations. But this isn't the right forum to propose an idea like this. This is supposed to be for answering questions. Please suggest this to the Craft team specifically. – Nilloc Sep 20 '16 at 1:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.