Devcamp #2 Rennes

Ce 14 novembre 2012 s’est déroulé le deuxième Devcamp à la Cantine Numérique Rennaise. Le thème de cette soirée était le déploiement d’application sur des serveurs. 5 intervenants nous ont fait découvrir leurs solutions dans des lightning Talk de 10min.

Fabric ton déploiement

Florian STRZELECKI nous fait découvrir Fabric, un logiciel python qui nous permet de déployer nos applications sur plusieurs serveurs. Fabric nous permet de définir des rôles pour chaque serveur afin de personnaliser ses déploiements. Fabric se configure à l’aide d’une fichier de configuration en python. Il ne nous reste plus qu’à utiliser les commandes Fabric pour lancer nos déploiements! Et tout ceci côté client, inutile d’installer Fabric sur chaque serveur.

Capistrano

Capistrano est présenté par Thierry HENRIO. Cette outils fait sensiblement la même chose que Fabric mise à part que celui-ci est développé en Ruby. Il utilise un système de plugin(ou Recipes) permettant de pouvoir utiliser des scripts déjà existant. Tout comme Fabric, Capistrano ne nécessite pas son installation sur nos différents serveurs.

GitHub Pages et IWantMyName

Guillaume COLLIC via un retour d’expérience sur la création de codeouest.org nous fait découvrir 2 services : IWantMyName et GithubPages

IWantMyName est un site web nous permettant de créer uniquement notre nom de domaine. Il possède ensuite un market (ou store) dans lequel différents services sont présentés. On peut alors lié un service voulu à notre nom domaine. Si la démarche ne peut pas se faire automatiquement, une explication précise sur la démarche est donné.

Guillaume nous présente ensuite Github Pages, un service qui nous permet d’héberger des pages web statiques sur un dépôt git. On peut utiliser ce service avec IWantMyName pour le lié à notre nom de domaine.

Puppet

Puppet est un outil également développer en ruby nous permettant le déploiement d’application sur les serveurs. Il nécessite son installation sur chaque serveur.

From scratch to deploy

Nicolas Ledez nous présente, à travers une démo en direct, la façon dont un administrateur système, un développeur et un intégrateur web travaille avec les outils découvert plus haut.

Conclusion

Ce deuxième Devcamp a été riche en échange et en découverte. Le regroupement de développeur passionné multi-techno donne une ambiance chaleureuse. Vivement le 12 décembre pour assister à la troisième édition! 🙂

Les gestionnaires de versions

Lors de la conception d’une application ou d’un logiciel, il est indispensable de suivre  son évolution à travers des versions. Cela nous permet de revenir au besoin à une version antérieur ou bien de sauvegarder une version 1.0, de développer une version 2.0 ajoutant de nouvelles fonctionnalités tout en corrigeant les bugs qui pourrait survenir dans la version 1.0 en sortant des patch 1.1, 1.2, etc…

Il y a trois types de sauvegarde :

  • Complète : Ce type de sauvegarde est le plus fiable mais aussi le plus gourmand en mémoire. Il sauvegarde à chaque nouvelle version l’intégralité des fichiers modifiés ou non.
  • Incrémentielle (ou incrémental) : Chaque sauvegarde enregistre les modifications effectuées par rapport à la précédente sauvegarde(incrémental ou complète).  Cette méthode de sauvegarde est la plus rapide mais pas la plus fiable. En effet, afin de restaurer une version, il nous faudra la dernière sauvegarde complète ainsi que toutes les sauvegardes incrémentales jusqu’à la version voulu. En cas de perte d’une de ces versions, il est impossible de restaurer la version voulu.
  • Différentielle : Chaque sauvegarde enregistre les modifications effectuées par rapport à la dernière sauvegarde complète. Cette méthode est moins rapide que la sauvegarde incrémentielle mais plus fiable. En effet, afin de restaurer une version, il nous suffit d’avoir la version complète et uniquement la sauvegarde différentielle de la version voulu.
Sans appui logiciel, cette tâche s’avère très fastidieuse voir impossible. Une des méthodes consistait en effet à créer une copie des fichiers dans un autre répertoire. Il était donc courant d’oublier de faire une copie, de supprimer un de ses répertoires, d’oublier de faire les mise à jour 1.1 et 1.2 dans la version 2.0, etc…

Ainsi il existe différents logiciels qui s’occupent de gérer ces versions.Ils sont divisés en trois catégories :

  • LVCS : Local Version Control System
  • CVCS : Centralized Version Control System
  • DVCS : Distributed Version Control System

LVCS

LVCS (Local Version Control System ) est le système le plus simple pour gérer ses versions. En effet, les LVCSs possèdent une base de données local afin de sauvegarder les versions. Cette méthode est aussi la moins fiable. En effet, si l’on perd le disque dur, la version du logiciel sur laquelle nous travaillons ainsi que les autres sont perdues. De plus, un LVCS est inadapté pour un projet en équipe.

RCS est un des LVCS les plus connus.

Schéma d’un LVCS :

 

CVCS

CVCS (Centralized Version Control System) est un système ayant un dépôt référent situé sur un serveur. Il apporte une solution aux développeurs travaillant en équipe. C’est le serveur qui se charge de sauvegarder l’historique des versions et qui sert de référent. Il est possible pour l’administrateur du serveur de gérer les droits des développeurs. Ce système est le standard pour  les gestionnaires de version bien que les DVCS apparaissent de plus en plus. En effet, les CVCSs ont trois principaux inconvénients. Premièrement, le travail hors-connexion est impossible, le développeur ayant besoin d’être synchroniser avec le serveur. Deuxièmement, en cas de perte du serveur(et de non backup), toute les anciennes versions sont perdus. Enfin, le système CVCS empêche l’utilisateur de travailler en mode “brouillon”. En effet, chaque version est forcément placer sur le serveur principal, il est donc impossible de pouvoir travailler sur des versions d’essais en local pour ensuite faire un commit sur le serveur principal.

Subversion(SVN) et CVS sont les CVCSs plus connus.

Schéma d’un CVCS :

DVCS

 Les DVCS (Distributed Version Control System) est un système où le dépôt(le regroupement des différentes sauvegardes des versions) situé sur le serveur est dupliquée sur l’ensemble des développeurs. Ce système offre plusieurs avantage : Il permet aux développeurs de pouvoir continuer à travailler hors-connexion. De plus, le développeur peut ainsi utiliser son dépôt local pour réaliser des brouillons et ainsi éviter de gêner les autres développeurs avec des versions “inutiles”. En cas de perte sur le serveur principal, il suffit de le restaurer en prenant une copie situé sur l’ordinateur d’un des développeurs. L’inconvénient principal de ce système réside dans le fait que l’administrateur du serveur possède moins de contrôle sur les fichiers. Par exemple, il ne pourra pas empêcher la mise à jour de fichier sur le dépôt local d’un développeur. Le second est que ce système consomme plus de mémoire(étant donné qu’on copie le dépôt du serveur sur sa machine local).
Git est le plus connu des DVCSs.
Schéma d’un DVCS :

Vocabulaire

Quelque soit le système de gestion de version que l’on utilise, on rencontre plus au moins le même vocabulaire. Voici les mots que l’on rencontre le plus :
  • Working copy : C’est les fichiers locales sur lesquelles on travaille.
  • Repository : C’est le répertoire de votre projet contenant la version du projet du côté du gestionnaire de versions.
  • Commit : C’est la version que l’on envoie sur votre gestionnaire de versions.
  • Branche : C’est l’axe de développement de votre application, il peut y avoir un axe développement et un axe production par exemple.
  • Merge : c’est l’action de fusionner de deux branches.
  • Flag/Tags : c’est un tag que l’on place sur un commit précis. Par exemple : Version 1.0