Aujourd'hui un article un peu différent de ce que vous avez l'habitude de voir sur ce blog. Depuis le 1er décembre des auteurs français se relaient autour du hashtag #nowwwel à l'initiative de HTeuMeuLeu pour offrir chaque jour un nouvel article sur la conception web ; et je vous propose donc aujourd'hui mon article.
Je vais vous parler aujourd'hui de déploiement automatisé. Ou, pour être précis, je vais vous faire un retour d'expérience sur la manière dont je suis passé en plusieurs années de la copie par FTP au déploiement par TFS Release Management.
Les fichiers HTML et le FTP
J'étais au lycée quand j'ai fait ma première page perso. J'avais trouvé un logiciel sur le CD de Wanadoo qui permettait de faire son propre site web, et j'ai donc décidé de me lancer. Claris Home Page était un éditeur WYSIWYG, et j'ai découvert le HTML en regardant le code qu'il générait. Je n'ai su que beaucoup plus tard que ce n'était pas la meilleure manière d'apprendre, mais ça fonctionnait, et c'est tout ce qui m'importait.
Pour déployer, c'était très simple : on trouve un hébergeur gratuit, on crée un compte, et on envoie tous
les fichiers par FTP. C'était du contenu pûrement statique, donc pas de question à se poser, ça ne pouvait
pas ne pas marcher. Il fallait juste s'assurer que la page d'accueil s'appelle index.html.
Quelques temps plus tard, je me suis mis au php, pour développer un site web avec un ami. Ça fonctionnait toujours pareil : on se connecte au ftp et on copie les fichiers. Et vu qu'on était 2, le ftp servait aussi à partager le code entre nous...
Avantages : c'est facile à utiliser
Inconvénients : à l'époque j'en voyais aucun :)
Découverte du monde professionnel et des sites compilés
En 2006 j'ai rejoins la société Bewise en tant que stagiaire, où j'ai énormément appris. C'est là que j'ai débuté avec les technologies de Microsoft, j'ai découvert que TFS permettait de gérer les codes sources très efficacement (avec le recul, j'ai du mal à comprendre comment j'ai pu faire 5 ans de fac en gardant mes codes sources sur clé usb), et j'ai surtout découvert ASP.NET.
La grosse différence avec ce dont j'avais l'habitude, c'est que cette fois le code est compilé ; pas question donc de se contenter
d'envoyer les fichiers par ftp.
Je travaillais sur un projet pour Airbus (c'est le passage obligé pour un Toulousain), et pas question de déployer directement sur
le serveur, ils ont des équipes dédiées pour ça. Nous leur fournissions un programme d'installation (InstallShield, le même que
lorsque vous installez un jeu sur votre PC) qui installait le site et configurait IIS correctement.
Avantages : Le process à suivre limitait le risque d'erreur
Inconvénients : On perdait beaucoup de temps à chaque livraison
Un peu de simplicité avec WebDeploy
L'exemple précédent est particulier, en général pour déployer un site ASP.NET on préfèrera passer par l'outil de déploiement intégré à Visual Studio. Cet outil va compiler le site et nous fournir la version prête à déployer. Il propose aussi de déployer directement le site sur un serveur IIS distant en utilisant le protocole Web Deploy.
Ici le fonctionnement est très simple, on rentre l'adresse du serveur, le nom du site dans IIS, le login et mot de passe, et c'est parti. Le protocole est basé sur HTTPS, donc le transfert sera plus sécurisé que par FTP.
Avantages : Très simple et rapide, sécurisé
Inconvénients : Il ne faut pas oublier de récupérer le code des collègues avant de déployer
Déploiement automatique par un serveur de compilation
Début 2015 j'ai rejoins ma société actuelle, et je découvrais de nouvelles conditions de travail. Au lieu de développer et
livrer des projets à des clients, j'avais maintenant la charge de développer et maintenir des applications web sur le long terme.
J'avais entendu parler des vertus de la compilation automatique et de l'intégration continue –notamment grâce à mon ami
Patrice– mais je n'avais jamais réellement pratiqué.
Honteux de mon ignorance à ce sujet, je me suis empressé d'apprendre à configurer un serveur de build, avant que mes nouveaux
collègues ne s'aperçoivent de mon incompétence.
J'ai donc commencé par mettre en place des compilations automatiques, avant
d'enchainer par le déploiement. J'étais tellement fier de moi que j'en ai fait un article
sur ce blog.
Il existe de nombreux outils d'intégration continue (Jenkins, TeamCity pour les plus connus), j'ai choisi TFS pour une raison très simple (et certainement très mauvaise) : on utilisait déjà TFS, et c'était intégré. Mais ça fonctionnait, et ça a très bien évolué par la suite, je ne regrette aujourd'hui absolument pas ce choix.
Enfin, pour être franc, à l'époque j'ai regretté de l'avoir fait un poil trop tôt :)
Avantages : Le déploiement est entièrement automatisé, on ne risque pas de se louper. On peut bloquer le déploiement si les tests unitaires ne passent pas. On peut se moquer des collègues qui font planter la compilation.
Inconvénients : La gestion des définitions de build demande un travail supplémentaire. Les collègues se moquent de moi quand je fais planter la compilation.
Des scénarios plus poussés avec Release Management
Dans la continuité de la section précédente, j'ai commencé à utiliser un nouvel outil : Release Management.
Maintenant, au lieu d'avoir une compilation qui déploie, on a 2 outils séparés pour la compilation et le déploiement.
Cela permet notamment de gérer plus facilement les différent environnements : on ne compile qu'une fois, et on déploie sur
les différents serveurs sans problème.
J'en ai aussi profité pour ajouter la base de données de mes applis à mon process de déploiement. L'image de la base de données est dans mon contrôleur de source, au même titre que le code, et peut être déployée manuellement sur les postes des développeurs, ou automatiquement sur les serveurs de test et de production lors du déploiement de l'application.
Avantages : Comme le paragraphe d'avant, mais en mieux.
Inconvénients : C'est toujours du travail. Mais moins pénible parce que je commence à maitriser l'outil
Et après ?
L'idéal serait de stabiliser une technique de déploiement, et arrêter de changer tous les 3 mois. Mais j'ai encore des
améliorations à faire ; et plus j'utilise l'outil plus j'ai envie d'aller encore plus loin.
Premier possibilité : séparer les branches de dev et de déploiement pour pouvoir lancer la publication juste en archivant
sur la bonne branche, et ne plus passer par l'interface web. Mais il va falloir que l'équipe prenne l'habitude d'utiliser les branches
(en n'oubliant pas qu'on utilise TFS, qui malgré ses qualités a une gestion des branches moins pratique que Git).
Autre possibilité, soyons fous, un déploiement auto de la branche dev tous les soirs. Mais là attention, ça va demander beaucoup de
discipline de la part des développeurs, je ne suis pas sûr qu'on soit encore prêts.
Je n'ai pas de section commentaire sur mon blog, mais vous pouvez réagir sur twitter ; merci pour votre attention, et joyeux #nowwwel à tous !
