By theabacus on

My workflow involves a development server, staging server, and production server (fairly common). Content is constantly being maintained on the production server.

If I am running a small code update, it is usually fairly simple since the database is minimally effected. However, on larger long-term updates, there may be significant database changes requiring upgrade database scripts. If the development involves a custom database table, it is easy to build an upgrade script. However, if an update involves changes to content type display, module configuration (from UI), system configuration, fields, or views it can get rather complex tracking down all the changes.

Are there any modules and/or practices that help with this? Thanks.

⋅ Categories: Drupal 7.x

Comments

jaypan’s picture

jaypan
Location Victoria, BC
commented

If you use a versioning system (GIT, SVN, CVS) with a central repository, this becomes much easier. I do the following:

1) The main branch of the central repository holds the code for the live server.
2) A secondary branch holds the staging server code
2) Development is done on my local machine in separate branches
3) When a feature is completed in the development environment, the branch is pushed to the repository and merged with the staging server code, which is then checked out to the staging server.
4) When the code has been cleared on the staging server, it's merged with the main branch (the live server code) and checked out to the live server. As the branch has now been merged, with the live code, it can now be deleted.

The theory is essentially the same regardless of the versioning system you are using, however the process will be different depending on which system you use. I recommend GIT.

Contact me to contract me for D7 -> D10/11 migrations.