Today's new release of Drupal Remote Dashboard (DRD) introduces a big new feature which allows anyone to manage Drupal site updates in a protected and automated framework without having to get any third party involved in the process. Just in time for Independence Day, July 4th 2017. For Drupal site owners this brings independence from external service providers without compromising quality of service or reaction time.
As a team that had spend time and money for years in developing best practices for staging, deployment and operations of many Drupal sites on version 5 to 7, the all new Drupal 8 came with some surprises and challenges in 2015, when first alpha and then beta releases started to see the light. Where all of Drupal core up to Drupal 7 had been exposed in the main project folder, all the contributed code from the Drupal community and third parties was located deep down in the code tree with custom code for the specific project sometimes was hard to separate from other contributions.
Drupal 8 projects are in most cases controlled by Composer and following best practices, the directory structure of a Drupal project looks similar to this (more details have already been covered here):
Developers are known for their most famous topics to be testing and doumentation - not. And I'm no different. However, the bigger my projects tend to get and the longer they last, the more this becomes a real issue so that even the developer in me starts to promote the idea of proper testing and documentation.
Drupal Remote Dashboard (DRD) fully supports Drush and it does this in two ways: DRD provides all its actions as Drush commands and DRD can trigger the execution of Drush commands on remote domains. This blog post is part of a series (see part 1 of 4) that describes all the possibilities around these two powerful tools. This is part 2 which describes on how to trigger any of DRD's actions from the command line by utilizing Drush.