.gitignore y la estrategia de deploys en Magento2

san saru

A diferencia de Magento 1, Magento 2 funciona (no de forma exclusiva, pero casi) con Composer.

Como ya sabemos, una de las grandes ventajas del uso de composer es la gestionar los paquetes que nuestro proyecto/código necesita e instalarlo o actualizarlo desde la fuente original con sólo unos comandos.

Ahora bien, por el otro lado, todos versionamos, mayoritariamente con git, nuestros proyectos… ¿todos versionamos, no?.

Magento 2 ofrece desde el vamos un archivo .gitignore con la siguiente definición:

/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/Gruntfile.js
/package.json
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/*
!/pub/static/.htaccess
/var/*
!/var/.htaccess
/vendor/*
!/vendor/.htaccess

(La versión del archivo .gitignore a la que hago referencia es la de Magento 2.1.3)

Ahora, teniendo en cuenta Composer y Git, ¿cuál es la estrategia para deploys a llevar adelante en producción?.

Magento nos invita a excluir por completo los módulos ubicados dentro de vendor. De ésta forma, una vez deployado el código vía git, una de las tantas acciones extras a ejecutar, sería la de composer update.

¿Es ésta la estrategia correcta para los deploys?.

Personalmente creo que como propuesta para producción es incrementar los riesgos, básicamente, por dos motivos:

Y luego, según vimos en la presentación de Olga Kopylova sobre deployments en el Mage Titans USA 2016, los siguientes directorios deberían ser de sólo lectura:

  • app
  • bin
  • dev
  • lib
  • phpserver
  • pub
  • pub/errors
  • pub/static
  • setup
  • update
  • var/di
  • var/generation
  • vendor

Visto esto, ¿nos conviene entonces excluir el contenido de vendor de nuestra tienda y ejecutar composer update en producción?.

En el último proyecto que me tocó inicializar esto fue un tema de discusión. La conclusión (o decisión al menos) fue:

  • Se quitó del .gitignore la exclusión de /vendor.
  • Sólo los entornos de desarrollo usarían composer.
  • Si se versiona, claramente, el archivo composer.json para que cualquier dev pueda hacer las actualizaciones correspondientes en un entorno controlado.

Sería interesante repasar y comparar situaciones con el fin de poder confrontar las estrategias y ver las experiencias de diferentes casos reales.

N de la R: La foto del post pertenece a John Snape y la tomé de WikiMedia.

Unite a la lista de suscriptores

Una vez por mes vas a recibir un mail con contenido que se relaciona con lo que vemos en el blog, que extiende o anticipa lo que hacemos en Twitch, y que también suele incluir anécdotas del MundoReal® y algún que otro link.

Es gratis, no tiene publicidad y con el double opt-in de Mailchimp.