Drush 9 wants to be more integrated into your site, required by your composer.json
and living in your vendor directory. On your local machine you should consider shifting to Drush global launcher, which will live somewhere like /usr/bin/drush
and be the first hit for drush
in your PATH. Global launcher isn't Drush, it just knows how to find Drush, preferably in the ./vendor
directory of your project, and only fallback to a globally installed Drush as a last resort.
To perform remote commands on Acquia, you should have the same version of Drush running remotely. Acquia has globally available Drush 8 (by default) and Drush 9 (using drush9
) but I should reiterate that it's not best practice to use different versions of Drush locally and remotely. So if you want run many remote Drush commands correctly, you should pimp your aliases to know how to connect to Acquia and find the right Drush.
Drush 8 had a --local switch which would try to ensure that global settings and aliases didn't get picked up, but this doesn't always work due to the way Drush bootstraps. Drush 9 differs in that it will be --local by default. So if you have bought into the idea that running each of your projects may be running a slightly different version of Drush (and that that's ok) then you should be working on putting your Drush aliases in the same repo.
As yet, I've still not seen a Drush 9 version of acapi.drush.inc
which contains a lot of convenience commands for working with Acquia. If you have one, please comment below. Depending on your project, this could be a problem, I use typhonius/acquia_cli so that I can write PHP scripts that do the things I need.
(As a side note, be careful if you are also using Platform.sh. The Platform.sh CLI is opinionated and thinks that aliases should be global, and will place a global ~/.drush/drush.yml
that screws up the "--local by default" strategy. See this issue for more information.)
I recommend your aliases file will live inside your repo at ./drush/sites/self.site.yml
. I understand there is a feature coming for BLT that generates aliases, if BLT is your jam, and I assume it will put aliases to the same location. Here is a sample site alias file for you to base yours on. Note that we always explicitly define the location of Drush 9. This allows:
drush @vm status
- our local vagrantdrush @dev status
- Acquia devdrush @stg status
- Acquia test/stagingdrush @prod status
- Acquia prod
vm:
host: SOMESITE.vm
options:
alias-path: /var/www/drupalvm/docroot/drush
local: true
paths:
dump-dir: ~/backups/drush.dbdumps
drush-script: /var/www/drupalvm/vendor/bin/drush
files: sites/default/files
root: /var/www/drupalvm/docroot
uri: SOMESITE.vm
user: vagrant
ssh:
options: '-o "SendEnv PHP_IDE_CONFIG PHP_OPTIONS XDEBUG_CONFIG" -o PasswordAuthentication=no -i "~/.vagrant.d/insecure_private_key"'
dev:
host: SOMESITEdev.ssh.prod.acquia-sites.com
options:
ac-env: dev
ac-realm: prod
ac-site: SOMESITE
paths:
dump-dir: /home/SOMESITE.dev/drush.dbdumps
drush-script: /var/www/html/SOMESITE.dev/vendor/bin/drush
files: sites/default/files
root: /var/www/html/SOMESITE.dev/docroot
uri: dev.SOMESITE.com.au
user: SOMESITE.dev
stg:
host: SOMESITEstg.ssh.prod.acquia-sites.com
options:
ac-env: test
ac-realm: prod
ac-site: SOMESITE
alias-path: /var/www/drupalvm/docroot/drush
local: true
paths:
dump-dir: /home/SOMESITE.test/drush.dbdumps
drush-script: /var/www/html/SOMESITE.test/vendor/bin/drush
files: sites/default/files
root: /var/www/html/SOMESITE.test/docroot
uri: staging.SOMESITE.com.au
user: SOMESITE.test
prod:
host: SOMESITE.ssh.prod.acquia-sites.com
options:
ac-env: prod
ac-realm: prod
ac-site: SOMESITE
alias-path: /var/www/drupalvm/docroot/drush
local: true
paths:
dump-dir: /home/SOMESITE.prod/drush.dbdumps
drush-script: /var/www/html/SOMESITE.prod/vendor/bin/drush
files: sites/default/files
root: /var/www/html/SOMESITE.prod/docroot
uri: prod.SOMESITE.com.au
user: SOMESITE.prod
Add new comment