Drupal 8:Deploy con capistrano

¿Qué es Capistrano?

Capistrano (http://capistranorb.com/) es una herramienta escrita en ruby para la automatización de tareas en servidores remotos y realizar despliegues en estructuras complejas.Capistrano NO se instala en la(s) máquina(s) de destino, el único requisito en los entornos es ssh. Podemos centralizar los despliegues en una máquina con acceso ssh a todas las demás (maquina de deploy) y realizar las diferentes tareas (backups, tags de git, despliegues) con total seguridad y de una manera controlada.

Requisitos

En la(s) máquina(s) de destino tenemos que tener acceso vía ssh, nada más! para todo lo demás capistrano se apaña.

En la máquina de deploy tenemos que tener instalado… Capistrano, y por lo tanto ruby 2.0 o superior.

Hemos preparado una plantilla para los entornos de deploy que simplifica la configuración:

https://github.com/davidgallego/drupal8_capistrano

Qué hace Capistrano- Tareas básicas de deploy:

- Sube tu código al/los servidor(es) en releases.

- Tiene directorios y archivos compartidos entre releases.

- Puedes hacer rollback en cualquier momento.

- Custom Task.

- Creación de copias de seguridad DB

- Ejecución de comandos drush en remoto

- Restauración de db en rollback

Estructura:

├── current -> /var/www/my_app_name/releases/20150120114500/├── releases│ ├── 20150080072500│ ├── 20150090083000│ ├── 20150100093500│ ├── 20150110104000│ └── 20150120114500├── repo│ └── <VCS related data>├── revisions.log└── shared └── <linked_files and linked_dirs>

Desarrollo

Instalamos drupal desde https://github.com/drupal-composer/drupal-project/, el core, los themes contribuidos y los módulos contribuidos se instalan desde composer, por lo tanto no están en el repositorio.

Los módulos se instalan y actualizan con composer:

composer require drupal/redirect ~8.1

composer update drupal/core

La configuración va en /sites/default/settings.local.php fuera del repo.

Configuración de CapistranoGenérica (capistrano/config/deploy.rb)

- Configuramos el repo: set :repo_url, 'git@example.com:path/to/repo/reponame.git'

- Configuramos la ruta de drupal (normalmente /web): set :app_path, "path/to/drupal/dir"

Entornos (capistrano/config/deploy/{NOMBRE_ENTORNO}.rb)

- Configuramos la rama que se tiene que desplegar: set :branch, 'dev'

- Configuramos el directorio en el que se tiene que desplegar: set :deploy_to, 'path_in_the/server'

- Configuramos el/los servidores: server 'ip_or_domain.es', port: 22, user: 'deploy_user', roles: %w{app db web}

DeployYa estamos preparados para hacer deploy:

cap {entorno} deploy

Listo!

(bueno en realidad no….) la primera vez que hagamos el deploy será un FAIL, tenemos que crear el archivo shared/web/sites/default/settings.local.php con la configuración del servidor.

cap {entorno} deploy y Ahora si!.. Listo!

Para rollback (despues de hacer mas de dos deploys)

cap {entorno} deploy:rollback (nos preguntará si queremos restaurar alguna copia de db)

Drupal 8:Gestión de la configuración

Configuration Management Initiative

Por fin todo lo que sea configuración es exportable e importable a través de archivos yml, pero…

¿CÓMO GESTIONAMOS ESTO?

Si sólo hay un desarrollador no hay ningún problema, haces los cambios que haya que hacer, los exportas en desarrollo y los importas en el entorno que toque, mola!

Si el proyecto es multi-developer XD … puede que haya algún problema

Problemas

Mike exporta su configuración y la sube al repositorio.

Bob crea un nuevo tipo contenido...

Bob recoge la configuración del repo y se la importa, (o dios!!!!, todos los cambios de configuración que había realizado, no están….)

Bob, eres mu tonto

Problemas

Mike exporta su configuración y la sube al repositorio.

Bob actualiza su repo, exporta su configuración y la sube al repositorio.

Mike actualiza su repo e importa la configuración

O dios!!!!, todos los cambios de configuración que había realizado, no están….

Bob, eres mu tonto

Flow

Bueno entonces cómo!!!!

Una posible solución: http://nuvole.org/blog/2014/aug/20/git-workflow-managing-drupal-8-configuration

Mike, si ha realizado cambios de configuración, antes de hacer un pull siempre hace una exportación de su configuración, luego hace el pull, si tiene conflictos los corrige y luego realiza un import de la configuración para incorporar los cambios de sus compañeros.

En los entornos (dev|pre|pro) nunca se realizan cambios de configuración.

PROCESOdrush config-export

git add --all

git commit -m “Cambios en config”

git pull origin master

(Arreglamos posibles conflictos si fuera necesario)

drush config-import

git push origin master

¿¿¿CUAL ES TU SOLUCIÓN????