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:
- Cada línea de código que llega al servidor debería ser monitoreada/revisada/confirmada/aprobada antes de llegar al servidor (por más tedioso que pudiera parecer)
- Dos situaciones de NPM que que nos demostraron como romper todo: La debacle NPM y la más reciente en la cual con un paquete y 11 líneas de código se complicó todo.
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.
