There is no doubt that Drush is a magical tool in the Drupal community. Two very useful tools in the Drush "Swiss Army Knife" include drush sql-sync and drush core-rsync. These tools allow copying databases and files between Drupal instances.

If you need to have access to run Drush commands on a production server or via a Drush alias for a production server, policy.drush.inc can help prevent some devastating mistakes. Accidentally overwriting production databases and files can impact you and your clients negatively. The Github gist below shows how the built-in Drush policy functionality can prevent sql-sync and core-rsync from running against any Drupal instance that has a destination with prod in the name. This works for Drush aliases too.

Place the policy.drush.inc file in ~/.drush on the machine you use to run Drush. The code in the gist above prevents operations like drush sql-sync @dev @prod and drush core-rync @dev:%files @prod:%files

Drush's policy.drush.inc allows for a few other functions for validation and alters. It is worth reviewing the options and implementing changes to prevent accidents that can be prevented.

While the above works well, the best way to prevent accidental production issues due to developer mistakes is to have a policy implementing separation of duties. In this sort of policy, developers would not have access to production servers. Devops engineers would handle deploys manually or manage the automation that handles deployments.

Thank you to all of those who have worked so hard to make Drush a fantastic tool that I depend on daily.

Blog Category: 

• Drupal