Depuis de longues années, Prestaconcept déploie les projets réalisés en utilisant Capistrano mais avec une particularité, le déploiement par archive.
Quel que soit le projet sur lequel nous sommes, nous voulons pouvoir déployer de façon fréquente et sans stress. Le recours à l'automatisation est dès lors obligatoire.
Capistrano
Depuis longtemps, nous utilisons Capistrano, avec en v2 l'adoption de Capifony dédiée à Symfony, puis Capistrano 3. Capistrano c'est un outil robuste, écrit en Ruby mais capable de déployer une application quel que soit son langage.
Il permet d'automatiser les tâches de déploiement en décrivant la configuration de son projet (les répertoires ou fichiers à partager entre chaque déploiement, les permissions à appliquer, le channel Slack à notifier, etc) d'un côté, et le ou les serveurs sur lesquels déployer le projet suivant la cible (recette, preprod, production, etc).
Habituellement, Capistrano déploie en utilisant Git directement sur le serveur cible en faisant un checkout de la branche demandée.
Chez Prestaconcept, nous avons, depuis quelques années, préféré le déploiement par archive.
Déployer une archive
Actuellement, notre plateforme d'intégration continue sous GitlabCI a pour charge de générer une archive du projet. Auparavant, nous faisions de même avec Jenkins, mais cela pourrait être par n'importe quel autre système en fait. L'essentiel est de générer une archive lorsque le code d'une branche est modifié.
L'archive qui est produite contient tous les fichiers nécessaires en production, et seulement ceux là. C'est à dire le code source de l'application, bien sûr, mais également les dépendances, les assets compilés, minimisés, etc. L'archive ne contient que ce qui est indispensable en production : sont supprimés les fichiers qui ne sont utiles que lors du développement. C'est ce package complet qui est alors envoyé vers le(s) serveur(s) cible(s).
Et c'est là le premier avantage de cette méthode: nous sommes assurés de la consistance des déploiements au fil de la chaîne de déploiement, entre recette, préproduction et production. L'archive déployée en production l'aura été auparavant en préproduction et en recette avec exactement les mêmes fichiers. C'est toujours les mêmes versions des dépendances ou des js qui vont par exemple être déployées pour une branche donnée. Un arrêt de Github ou de npm ne nous empêchera pas de déployer du moment que l'archive a déjà été faite.
Le deuxième avantage c'est de ne pas être obligé d'avoir sur les serveurs de production les outils propres à la compilation ou à l'installation du projet. Nous n'avons pas composer, less ou node par exemple sur les serveurs de production. Il n'y a que le strict nécessaire au fonctionnement de l'application elle même et pas à sa génération.
Enfin, troisième avantage, nous bénéficions d'un gain de temps au déploiement. La phase de construction de l'application a été faite en amont lors de la génération de l'archive par la plateforme d'intégration continue et elle ne sera faite qu'une fois. Le déploiement consiste seulement à envoyer l'archive et à la décompresser.
capistrano-archive en open-source
Depuis quelques années, nous utilisions un plugin pour Capistrano pour pouvoir déployer par archive. Des changements dans la gestion des "Custom SCM" des dernières versions de Capistrano nous ont poussé à re-écrire ce plugin et c'était l'occasion de le rendre open-source et de publier capistrano-archive sur GitHub.
Sa fonction première est bien entendu de prendre une archive en local et de l'envoyer sur le serveur cible du déploiement. La localisation de l'archive, tout comme son emplacement temporaire sur le serveur cible, sont paramétrables.
Il est également possible de n'envoyer l'archive que sur un seul serveur dans les cas d'architecture cible à plusieurs serveurs mais disposant d'un espace de stockage partagé. Dans ce cas là, l'archive n'est envoyée qu'une fois mais sera utilisé sur chacun des serveurs pour la création de la release.
Enfin, un workflow de validation pour forcer un environnement à utiliser l'archive précédemment déployée sur un autre peut facilement être mis en place. Ainsi il sera par exemple possible d'obliger à déployer sur la recette avant la production.
Avec ce plugin pour Capistrano, vous pouvez donc si vous le souhaitez déployer en utilisant des archives comme nous le faisons sur tous nos projets.