Dashboard to deploy, sync, rollback, snapshot and monitor ssh-connected environments. Also auto-updates on your projects (core / modules) are provided.

See documentation / guides etc at https://www.drupal.org/node/2493011 .

Characteristics

Built with Drupal 7

Easy setup compared to other tooling

Easily connect existing GNU/Linux servers running Drupal sites without need for installing modules or otherwise

Use GitHub, Stash, GitLab or Bitbucket

Deploy Drupal 6, 7 and 8

Compatible with multi-sites

Composer build prior to deploy

Compatible with https://github.com/drupal-composer/drupal-project

Please test, and participate in issue queue / coding etc!

Your input is most valued!

Note

Be aware that this project is not in a stable release yet, and you will always be responsible for your own environment, as this is not commercially-supported software.

Make sure you have periodic backups of your environments.

If misconfigured, or misused, this can brick your environments.

But in general, it might just be much more bulletproof than your beloved sysadmin :)

You are encouraged to test this project and report back to us!

It will save you lots of time.

Security considerations

Since DFC has root access to your systems, it's a weak spot / single point of failure in your infrastructure, just like all automation tooling.



Therefore you're advised not to put this dashboard on the public web, but only use it on your local network .

Therefore you're advised not to put this dashboard on the public web, but . Passwords (for FTP, GitHub access etc) need to be used / read by DFC, so they are saved in plain text in the DB, as salting / hashing would only make a false sense of security. Be aware of this when assigning roles to people.



Any ideas / advice on this is more than welcome.

Current features

Create client / project / environments

Connect GitHub, Stash, Gitlab or Bitbucket

Drupal 6, 7, 8

Deploy commits or tags to environment (SSH / FTP)

SSH environments (pub key connected)

FTP environments (password based) (Less features! You should drop FTP ASAP)

Backup DB / webroot (SSH / FTP, DB as well)

Restore snapshot (DB, files, settings.php or full webroot)

Drush commands like Clear cache Revert all features Rebuild search API indexes Reset all passwords and get 1-time login link (uli)

Report in hipchat (deploys)

Auto-updates projects to latest security version Core Modules (only modules on configurable whitelist)



Known limitations

At this moment, only drush 5 is supported (used / pushed by DFC for all actions to remote systems)

Fixed

Fixed Snapshot restore might fail if restoring database, because drush cannot bootstrap Drupal sometimes if DB is empty. Replacing drush with custom settings.php-parsing is on roadmap with high prio.



Despite this, restores are still successful in 99% of the cases, and manual intervention is always possible, since you can just download snapshots (backups) from the dashboard.

Fixed

Fixed Configure remote environments with root-user.

Also, the running webuser (www-data?) would probably work, but other users might fail as Drupal creates new files as it's own user, and -in general- those cannot be moved / touched by other users (used for deploying).



Using the webuser is not advised, as it would make the whole webroot writable by the webuser, hence leaving your websites open to another huge attack vector.



So use root.

Also, the running webuser (www-data?) would probably work, but other users might fail as Drupal creates new files as it's own user, and -in general- those cannot be moved / touched by other users (used for deploying). Using the webuser is not advised, as it would make the whole webroot writable by the webuser, hence leaving your websites open to another huge attack vector. So use root. Drush has a bug: it uses ~/.my.cnf over drupal credentials, rendering drush quite useless (results in deploy failure sometimes).

Workaround: specify 'password' and 'user' in ~/.my.cnf

Roadmap

Bold: already in progress.