Voting starts in March for the Drupal Association Board election.
Spun off from. Come up with two or three standard workflows for deployment and sync of configuration, and ensure that the system actually meets those needs, with a focus on how config is gotten out of the sites in question.
User has a single site installed via a one-click installer at a shared host.
- This user will not have any interaction with the configuration system. Even if they want to move to a new host, they will have a to take a database dump and this alone will serve their needs.
User with a live website and a local development environment, using ftp to transfer code (no version control)
- Developer iterates on their local environment.
- When a set of changes is ready for deployment, files are uploaded to prod server's config directory. This directory may have a different hash than the local environment, but it will still start with 'config_'.
- UI is used to import them.
Small team using version control as a deployment mechanism.
- When work is started, settings.php is configured so that all environments are using an identically named config directory.
- Developers work with a checkout of the current production config on their local machines.
- Developers can then iterate on their site and its config files with $VCS, and share changes between other devs in normal $VCS ways.
- When a set of changes is ready for deployment, prod server's config directory is $VCS updated.
- Drush import-all-the-things.
1) Explicitly import/export configuration files
This is the system as it stands now. There has been feedback that this is confusing (users will expect their config files to always be present without explicitly exporting them) and it breaks some assumptions we have in CMI, like that missing files indicate deletion of configuration. Feedback and discussion around the present UI can be read at.
2) Writethrough configuration to files as it is saved
Makes more sense to end users and is more intuitive, can cause race condition problems when configuration is deployed because config being changed on the live site will overwrite config changes that have been deployed. It has been suggested that this could be controlled with a setting that indicates whether writethrough should be on by default or not (with a default of on.) This would require a little knowledge of how the system works to configure sites with more complicated deployment needs.
3) Writethrough changes to a separate directory
The same as above, but writethrough is written to an 'export' directory. When deployed to another server, it is deployed to an 'import' directory where it is imported. This avoids the race condition issues described above, however it also makes vcs-based deployment somewhat more complicated. You would want to setup every site instance (dev, stage, prod, whatever_other_instance) declaring in its settings.php in which directory it writes, and from which directory it imports - only as defaults, with the UI and drush commands for explicit import / export letting you pick a different one amongst the folders present under files/config_xxx.
'prod' writes to /prod and imports from /stage
'stage' writes to /stage and imports from /dev_shared
'dev writes to /dev_local and imports from /dev_shared
/dev_shared, /stage and /prod are all pushed in VCS, changes made in local dev environments are made by diffing / merging changes from /dev_local to /dev_shared and committing.
There are some more details and a potential workflow diagram at http://drupal.org/node/1703168#comment-6344116
|#60||Screen Shot 2012-10-22 at 14.41.45.png||82.49 KB||swentel|
|#60||Screen Shot 2012-10-22 at 14.42.03.png||27.05 KB||swentel|
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: PHP Fatal error encountered during run_tests.sh. See review log for details.. View