Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-09T01:56:22.570Z
Answers.Text: What about some sort of Craft Migration that tracks changes and mods production server. I don't have time right now but I am putting it out there for someone else.
Answers.UserDisplayName: David A McInnis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-31T14:11:47.243Z
Answers.Text: Migrations are coming in v3, due late 2017 I think - https://craftcms.com/news/craft-3-content-migrations
Answers.UserDisplayName: Adam Hopkinson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-08T18:06:57.697Z
Answers.LastActivityDate: 2014-10-08T18:06:57.697Z
Answers.UserDisplayName: Brandon Kelly
Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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".</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-20T01:29:31.400Z
Answers.Text: 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.
Answers.UserDisplayName: Nilloc
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-05T09:50:07.493Z
Answers.LastActivityDate: 2015-11-05T16:33:20.000Z
Answers.LastEditDate: 2015-11-05T16:33:20.000Z
Answers.UserDisplayName: Andre Mohren
Body: <p>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.</p>
  
  <p>Is there a recommend workflow for this situation. </p>
  
Tags: <database><migration><workflow>
Title: Migrations for Deployment
ThreadText: # Migrations for Deployment
  
  (Asked by: username_0 on 2014-10-06)
  
  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.
  
  **Tags:** database, migration, workflow
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2014-10-08. Score: 2 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_0**: What about some sort of Craft Migration that tracks changes and mods production server. I don't have time right now but I am putting it out there for someone else.  
  > **username_2**: Migrations are coming in v3, due late 2017 I think - https://craftcms.com/news/craft-3-content-migrations  
  
  ---
  
  ### Answer by username_3 on 2015-11-05. Score: 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.
  
  > **Comments:**
  > **username_4**: 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.  
  
  ---
  
  