I vaguely remember being able to use 'drush update' to successfully update sites based on boa a good while back. But these days, I just have not found a way to be able to use drush to manage my boa sites, and the pain of GUI administration drastically reduces the usefulness of boa.
But I do realize I may be mixing up quite a few different policy issues here. So, I am just seeking clarification on the following:
- It seems the boa best practices is to not update modules (not core) on sites, but to create new platforms and then migrate sites to the new platforms.
- If the above is correct, I do wonder why I cannot use drush to update the shared platform module/theme space instead of needing to create a completely new platform. Can someone help me understand why this could create issues ..
- If it is not, what is the best practices for using drush?
- What OS users can use drush? o1, o1.ftp, root, site-owner OS account ?
- Is it even possible to use drush to update the shared platform code, and thus avoid storing modules/themes in sites/domain.name/modules, etc?
Yeah, too many questions, but this has been confusing for me for a while now .. I need to address this, because not being able to use drush in maintaining sites is easily trippling the amount of time it takes to maintain these sites.
If these have been directly addressed in some document or other post previously, please suggest links I can go and read more about it.
Thanks in advance for advice/comments/suggestions.
Comments
Or are there boa specific CLI commands?
Forgot to also ask if there are boa/octopus/barracuda specific CLI commands that would allow one to:
The recipe for updating a
The recipe for updating a platform is here: https://omega8.cc/your-drupal-site-upgrade-safe-workflow-298. You will not find mention of Drush there and for good reason. Trying to deviate from this recipe will only cause you heartache and sorrow.
That said, there are a couple ways to create a new platform:
Use a Drush Make file.
Use "drush up" on a local version of your site, then "git clone" it to the static directory of your Octopus instances.
In either case, make sure you then follow these directions to complete the process of creating the platform: https://omega8.cc/how-to-add-custom-platform-properly-140
Thanks for the suggestions
Million thanks, JimSmith, for the suggestions. I already saw some of those links, and can relate to the case being made.
The one scenario I was particularly miffed about is where the site is sending out emails suggesting updates are required, and a need to quickly clone the current platform the site is based upon, add the required updates, and then migrate the site.
I could not easily tell if a mere copying of the platform tree would constitute an effective clone, given the generous use of symbolic links
But you have given me fresh ideas on how to more effectively manage things via drush makefiles and git. This added with the omega8cc suggestion on using their git sources as foundation for custom platforms provide me something to start working with.
I guess I now have to quickly get up to speed on writing better drush makefiles ..
Thanks again ..