When about to run a mirgate task in Aegir, there is a notice in the header of the pop-up window that reads as follows...
You may want to read our best recipes for disaster (http://community.aegirproject.org/node/1381) before going further. You can move your site to a new platform using this form, but avoid changing its domain name here at the same time. If you wish to securely change the platform this site is hosted on, always Clone it in its current platform, then test Migrate of the cloned copy first and check if the cloned/migrated copy works fine, before you will try that with your live site.
On that link (from the aegir project page), it states:
How to get all kinds of failed migrate or clone tasks?
Very easy. Simply use sites/domain-name/modules space for your code. This will guarantee many half-broken migrations with duplicates of the same site existing in two platforms, with fatal errors because some required include file in some module no longer exists, or not yet exists, as all paths to sites/domain-name/modules change on the fly when either domain-name or platform used changes, so some entries in your site's system table will cause either failed and reverted tasks in Aegir or some nice WSOD, until you will repair registry with http://drupal.org/project/registry_rebuild.
No, really, don't use sites/domain-name/modules for anything and save yourself headaches and frustration.
To help you understand this better, let's quote mig5 - Aegir core developer: "Aegir doesn't track site-specific modules/themes in /sites /$yoursite /(modules|themes) because it's not possible to ever upgrade those modules (they are tarballed up and moved with the site on a Migration). For this reason it's unwise to store site specific modules in this directory as you'll never be able to upgrade them if you do your upgrades properly (via Migrations, to new target platforms). To have site-specific modules not in that directory, you should learn install profiles, and store the modules/themes in /profiles /$yourprofile /(modules|themes) for a site using that install profile. (...) I don't see us ever handling the upgrades of modules in /sites/$site, since that entire dir gets tarballed up and moved across. In fact we made a deliberate design decision to literally ignore those modules in the Aegir package system." We highly recommend to read all comments there. There is also an excellent handbook entry you should read to understand this better.
I've not been using makefiles or git (though I used to use CVS)... I've just been developing using a cloned version of the production site updating modules etc with drush and then cloning and migrating. It seemed quicker and easier for me (perhaps it was not).
It looks like its probably time I learnt how to create an install profile and use drush make.
I also note the timely release of this:
http://drupal.org/project/profiler_builder
https://drupal.psu.edu/blog/422
Can someone please advise? Is this the way forward? Thanks.
Comments
I must be the last one to the
I must be the last one to the party on this (I'm only a part time developer and haven't followed BOA religiously). I found these excellent videos...
http://omega8.cc/managing-your-code-in-the-aegir-style-110
I just can't understand why Drush Make isn't packaged on my BOA 2.0.3 install...
Correction - I can see that
Correction - I can see that drush make isn't available as root but only for the user.
However, running make-generate as user doesn't seem to have the permissions to create the .make file. Is there a workaround?
Yes it does, I use drush
Yes it does, I use drush make-generate filename.make and it creates the file in the root of the platform.
I believe you have to use
I believe you have to use your main octopus instance user.
So by default o1.
su -s /bin/bash o1then do
drush make-generate sitename.makeThanks snlnz, I did try su -s
Thanks snlnz, I did try su -s /bin/bash o1 (well my username instead of o1) but it didn't work. I'm experiecing some dramas with drush. It must be related. See: http://drupal.org/node/1834384