I'd swap updb and cim.
updb to ensure hook_update_N() runs first to provide entity updates or delete fields (which can't be done via cim) or to disable modules programmatically prior to getting the updated config imported. This prevents cim running into errors due to missing config (not knowing for example that a module will be disabled via core.extension....
The answer is that they are certainly not redundant.
It's true that one can accomplish the same end result using a bash script that includes drush commands (at least the building part). But, if what we are looking to do is to integrate our process into a CI framework like JenkinsCI, then using something like phing (ant or capistrano could be substituted ...
It sounds like you're running into a common deployment issue with Drupal: the fact that content and configuration reside in the same database. This generally puts a kink somewhere in most deployment strategies, as you start to run into issues whenever you have to merge existing user content (often a moving target) with upstream configuration changes.
The Drush make approach, as you've already mentioned, is the version my team is using.
Even though you are not currently using drush make for your sites, it should be relatively straightforward for you to move to this workflow if you want as drush also provides drush make-generate which will generate the make file from an existing site. Thus no need to feel ...
You should look into drush, drush deploy and especially features. Not all Drupal configuration options are supported by features, and you will need to do some work to create a deployment process that works for you. There is no single script that will do everything correctly for you.
One possible answer is the Environment module (the 7.x dev release works just fine). It allows you to define arbitrary environments (comes configured with "Development" and "Production", but you can have more if necessary). It then provides drush environment-switch to switch between environments. You can then implement hook_environment_switch() to do ...
There is a feature request issue in a Drush queue, just stumbled on it. In donquixote's Drux project are commands you need:
drux-enable-dependencies (dep-en) - Download and enable dependencies of existing modules.
drux-find-obsolete (obs) - Find modules that are not direct or indirect dependencies of the modules given as arguments
You have to do this yourself. @rpayanm answered where you can do it manually, you will need to look at the code there, and for example implement drush commands that allow you to export and import it again. Automating that is then relatively easy, export, sync it to the other server, and import again.
Looks like a project that helps with that exists: Drush ...
To set up to do a drush rsync or drush sql-sync to a remote machine, set up aliases for both sites on the local machine. The alias for the local site should be as you have shown in your question. For the remote machine:
$aliases['stage'] = array(
'uri' => 'staging.mysite.com',
'root' => '/home/user/www/mysite',
'remote-host' => '...
In order for remote commands to work, you must make sure that drush is in your PATH. This is often done by putting something like the following in a line that bash will source when it starts up:
A lot of folks put a line like this in their ~/.bashrc file, but note that on a lot of systems, this file begins with a ...
Add the --yes option to your Drush command. This assuredly will work if you place it before the rsync directive.
drush --yes rsync @dev @live
Drush rsync is different than most Drush commands in that it uses strict option handling. Commands that work with strict options pass all extra flags that appear after the Drush command name on to the ...
I don't think there is a way to get this task completely automated.
But you could use the Master Module to write your dependencies into code. Master provides a framework for module-dependency configuration in automated deployment settings.
I use readonlymode when migrating my sites, which I daily do to migrate localhost content to remote host.
I use drush's sqlq command to restore which better than BackupRestore module.
For proper migration, you must compare sites/all folder with that of live one. You also need to copy sites/default/files to the live one.
My typical restore goes like as in ...
I would recommend that you create the field programatically. In your update function. You could also create multiple update functions, just create the field in one, then migrate the data then remove the old field.
If you have a lot of data, then your update function should be done as a batch, so it doesn't run in any PHP timeouts or memory limits. In that ...
The quickstart project will handle almost all of these tasks. It is basically a preconfigured drupal development environment that you run in a virtual machine.
If you wanted to install the tools locally, you can do almost everything in your lists with drush & make.
Configuration management is a major initiative in the upcoming Drupal 8. Here's Dries talking about it.
In D7, you'll need cTools and Features and Strongarm. And here's a comparison of staging/deployment tools.
Migrating complete database can be risky, you will loose the changes on your live site.There are multiple ways to migrate, here is my view.
Use features modules to migrate the content types with dependencies from development to live site,
use migrate module to export your entities.
Views, panels and rules give you the export code ready to import, that ...
Here is how drush sql-sync works between two remotes:
Logs into remote @destination via SSH and creates destination database if needed via sql-create.
Backs up database on @sourceby performing sql-dump on source unless told otherwise and saves it into drush-backups folder.
Logs into @destination remote via SSH and executes rsync to transfer database from ...
This is how I do the restore on a site-by-site basis:
drush @site1 sql-drop -y && gunzip -c /path/to/backup/file1 | drush @site1 sql-cli
You could maintain a list of site aliases to database name and write a shell script to automate the process.
The database name for an individual site could be extracted as follows:
drush status @site1 --fields=...
There is Beanstalk
Advanced Deployment Tools Deploy your repositories to (S)FTP, SSH and
Amazon S3 in one click.
And there is GitHub's post-receive hooks.
GitHub will POST to a supplied URL when someone pushes to the repo. Just write a short PHP script to run on your linode VPS and pull from GitHub when it receives said POST.
You may be interested in Fabric
Fabric is a Python library and command-line tool for streamlining the
use of SSH for application deployment or systems administration tasks.
It provides a basic suite of operations for executing local or remote
shell commands (normally or via sudo) and uploading/downloading files,
as well as auxiliary ...
I seem to have stumbled my way through to a solution. Vocabularies don't need to be exported via UUID, as they already have their own machine name, but any terms within those vocabularies still need to be added to a deployment plan so they can be exported (inadvertently adding a vocabulary to the plan throws errors).
Using the latest development snapshots (...
Although the question is a year before I would suggest using these 3 tools.
Git + Capistrano + Drush.
It just works for such kind of tasks.
Here are some Capistrano gems/files related to Drupal to help you automate Drupal development:
Your question is a bit long, and too subjective. There are many ways to do things, and the answers to your questions are subjective. For better answers, post shorter questions that ask about a single factual item. It's hard to answer "what is the best workflow"-style questions on StackExchange; those are better handled on a discussion board.
Trying to pick ...
We abandoned managing the blocks through the normal Structure->Blocks page a long time ago. Now we use it simply to set block titles, and the individual block's settings.
For assignment onto pages we use Context module:
Context allows you to manage contextual conditions and reactions for different portions of your site. You can think of each context as ...
The Default Content module uses cores REST/HAL/Serialisation API's to export content to JSON. You put the content into you_module/content/[entity_type]/anything.json and the content is automatically imported when you enable your module.
Features can help bypassing the UUID problem. It's still buggy, which prevents us from fully automating the process, but we can at least shift and maintain configuration manually.
Features still creates modules, it exports the configuration into the config/install directory of the given features module. This will be picked up when you install the feature, ...