2. ¿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.
3. 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
4. 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
Estructura:
├── current ->
/var/www/my_app_name/releases/20150
120114500/
├── releases
│ ├── 20150080072500
│ ├── 20150090083000
│ ├── 20150100093500
│ ├── 20150110104000
│ └── 20150120114500
├── repo
│ └── <VCS related data>
├── revisions.log
└── shared
└── <linked_files and linked_dirs>
5. 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.
6. Configuración de Capistrano
Gené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}
7. Deploy
Ya 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)
9. 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
10. 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
11. 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
12. 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.
13. PROCESO
drush 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