Either Dev -> Prod or Prod -> Dev (I prefer this one). One note, I would highly suggest adopting a standard workflow, where content goes one direction only. Use drush ne-import or the admin interface to import the nodes from the nodes file you exported. Use drush delete-all or admin interface to delete all nodes of the types you want to import Use drush or admin interface to load features Optionally (and hopefully) version control Use node_export and features to export nodes/features to files After importing the dev db into prod, automatically run SQL statements (usually via script) afterwards to change any settings that are different for prod than dev (e.g., maybe you have in variables table some connection settings for connecting to external systems that you need to change to point at prod external systems instead of at the dev version).Ģ) Use the Features module, as mentioned by budda, for admin settings, and use the Node Export module for content export/import in combination with the Delete All module. Optionally, run a regex find/replace beforehand on any hard-coded absolute links which reference the dev URL in the SQL dump. If you need to make content (non-code) changes, you do so on the dev/staging server.Īs to the database portion, I've adopted basically two schools of thought here (a 3rd school of thought, doing database diffs, I won't discuss because the complexity is quite high).ġ) Deploy by dropping the production database, and importing a mysqldump of the development database.
The CI system or tests can automatically pick up on any conflicts you might have introduced as soon as you check in your code. Ideally, you have unit tests built into your continuous integration system (highly recommend luntbuild or QuickBuild for this by the way, but Hudson also works).
Then, you commit changes on a regular basis, and they get pulled down to the dev/staging server, as do your teammates. Thus, on your local machine, you only work on one feature request/bug report at a time, being sure to clearly delineate this task from others that people might be working on and communicating to your teammates that you are working on it (redmine or other bug tracking is great for this).
#Drupal development company nebraska code
My root suggestion is that you have a development/staging server where code changes are checked out using a Continuous integration system on a frequent basis (e.g., every 5 minutes). I answered a similar question and am going to adjust it slightly to answer your question here. There's another question that deals with that. Or, are we stuck with working on the same copy of the site? (please so no)Įdit: In the comments we discussed what things can't be exported with Features and one of them was Taxonomies. How should we version the database (is putting a dump file in git a good way to do it)?Īre there any modules available that help with some of these problems? What steps can we take to easily merge our database changes? However, not even close to everything supports Features. The Features module helps a little, letting us export some of our database work into code which can then be versioned and merged. We can take a SQL dump and include that in our git repository, but we can't really merge the databases. But this doesn't really work with the database. The biggest problem we have now is how do we merge database changes, and how do we include the database in our source control system? The files are easy, just track them all (we use git) and merge our work, resolving conflicts where needed. We basically end up redoing everything on a shared copy. But now it's a big pain to merge our work into a single instance of the site. So we've moved to separate development instances. We've tried working on the same development instance of the site, but we often step on each others toes, or bring down the site with some bad code making it impossible for the other to continue working until it's resolved. We have struggled to find a good way to work on different parts of the site at the same time without getting in each others way. I work with another developer on a Drupal site.
0 kommentar(er)
