Blog myBlog = BlogFactory.getWordPressBlog();
Article tagué SI
Mettre en place un workflow git
2/06/11
Si vous avez été à une ou deux présentations de git, vous avez sans doute déjà vu ce diagramme (ou un équivalent).
Après avoir un peu pratiqué git, ce genre de workflow devient naturel, et est particulièrement appréciable :
- les fonctionnalités ont chacune leur branche dédiée : la lecture de son historique n’est donc pas gêné par le reste des développements
- les livraisons peuvent être préparées sans empêcher les personnes qui travaillent sur les futures fonctionnalités de partager leur travail
- etc.
Voila pour la théorie : sur le papier, ça laisse absolument rêveur ! Mais dans la pratique, tout ne fonctionne pas aussi bien, surtout au début. Et c’est là que commence mon retour d’expérience sur la mise en place de ce workflow.
Application Play Framework sur Cloud Foundry
1/05/11
Il y a quelques semaines, j’ai obtenu un accès à la béta de Cloud Foundry. Pour ceux qui n’ont pas suivi l’actualité, il s’agit d’un PaaS (Platform as a Service) Open Source de VMWare, permettant d’exécuter en cloud des applications Java (WAR, Spring, ROO), Rails, ou Node.js (pour l’instant, mais d’autres pourraient bientôt venir enrichir cette liste).
Prise en main
La prise en main de l’outil de déploiement VMC via le tutoriel est extrêmement simple. On y apprend à créer et déployer une application sur le cloud en quelques commandes.
Deuxième chose à laquelle je m’intéresse, les systèmes de persistance. On a le choix entre trois systèmes, SQL (MySQL) ou NoSQL : MongoDB (base orientée documents) et Redis (base clé-valeur). Cette liberté de choix est très appréciable, et permet de répondre aux différents types de besoins que l’on peut avoir. Et là encore, on peut penser que d’autres systèmes viendront prochainement enrichir cette liste.
Côté Java, encore de bonnes surprises : contrairement au Google App Engine (par exemple), il n’y a aucune restriction sur l’utilisation de l’API : l’application est exécutée sur un serveur Tomcat. Il est donc possible de développer une application web Java complètement standard, et ensuite de la déployer sur Cloud Foundry au lieu d’un serveur d’application classique.
J’ai fait le test (avec une application simple) et ça fonctionne !
Avec Spring et l’outil de développement Spring Tool Suite, la gestion de la persistence MySQL est très simple, comme expliqué sur le blog officiel.
La suite >
Gérer AUTREMENT un projet Maven avec Git
13/04/11
Comme vous avez été nombreux à apprécier mon article sur Maven et git, en voici la suite ! Il s’agit d’une solution alternative permettant de répondre à la même problématique, basée sur les subtree.
Rappel : mon but était de séparer la gestion de configuration de plusieurs modules Maven d’un même projet, tout en conservant un dépôt pour maintenir le projet (pom racine du projet, etc.).
La problématique étant la même, nous allons nous baser sur le même exemple : un projet créé à partir de l’archetype appfuse-modular-jsf. Pour sa mise en place de ce projet, je vous renvoie donc aux étapes Créer le projet de démonstration et Mise en place des dépôts distants.
Revenons à notre espace de travail
Maintenant que nous avons nos dépôts distants, la première chose à faire pour mettre en place les subtrees est de supprimer les répertoires des deux modules dans l’espace de travail. En effet, avec cette méthode, les modules n’ont pas de dépôt git locaux dédiés.
Déclarons ensuite les dépôts distants de notre espace de travail :
1 2 3 | git remote add origin $BARE_REPOS/demo.git # S'il n'existe pas déjà git remote add core $BARE_REPOS/demo-core.git git remote add webapp $BARE_REPOS/demo-webapp.git |
A ce stade, les habitués de git qui ne sont pas trop endormis doivent crier « KEUOUA ??? ». Effectivement, les démos distants sont normalement des clones du dépôt local. Or nous venons de déclarer trois dépôts distants qui n’ont pas un seul commit en commun.
Ce n’est pas une erreur, et c’est le mode de fonctionnement des subtrees. Contrairement aux submodules pour lesquels on avait trois dépôts locaux, avec les subtree, on a un unique dépôt local : le lien entre cet unique dépôt et les dépôts distants passe donc par les « remotes » du dépôt local.
Des branches locales pour travailler sur les modules
Nous allons maintenant créer des branches locales associées aux branches distantes afin de pouvoir travailler sur nos modules.
1 2 3 4 | git fetch core git fetch webapp git branch localcore --track core/master git branch localwebapp --track webapp/master |
Il est maintenant possible de travailler sur les modules localcore et localwebapp dans leurs branches locales respectives. Le tracking étant défini, les push seront effectués vers les dépôts respectifs des deux modules.
Et l’arborescence globale de notre projet ?
Depuis notre unique dépôt local, nous avons vu comment travailler séparément sur nos différents modules. Mais à ce stade, nous n’avons pas reconstitué l’arborescence de notre projet Maven. C’est à ce stade qu’interviennent les subtrees.
On rebascule dans la branche master de notre projet, et on exécute :
git read-tree --prefix=core/ -u localcore git read-tree --prefix=webapp/ -u localwebapp
Après cette étape, on n’oublie pas de commiter l’ensemble et nous avons récupéré l’arborescence globale de notre projet.
Mettre à jour le projet lorsque les modules évoluent
Notre module core a maintenant évolué dans sa branche. Ces modifications ne sont pas automatiquement reportées dans la branche master de notre projet.
Pour récupérer ces mises à jour, il suffit d’utiliser la commande :
1 | git merge -s subtree localcore |
Cette opération aura pour effet de fusionner dans la branche master les modules (ainsi que leurs historiques respectifs).
On peut juger que ces historiques sont « parasites » à ce niveau : on les a déjà dans la branche du module. On préfèrera dans ce cas la commande :
1 | git merge -s subtree --squash --no-commit localcore |
Cela aura pour effet d’agréger tous les commits en un seul et de préparer le message de commit (qui concatène les messages de tous les commits agrégés). Il ne reste plus qu’à corriger ce message et à valider le commit.
Submodules ou Subtrees ?
Nous avons donc deux méthodes permettant de traiter la même problématique. Il ne reste plus qu’à en choisir une. Les deux approches ont leurs avantages et leurs inconvénients.
Les subtrees sont plus faciles à manipuler : ils nécessitent moins d’opérations, et il est plus difficile de faire une erreur qu’avec les submodules (oubli d’un push par exemple).
Les submodules sont plus complexes à utiliser, mais plus structurés (il s’agit là d’un avis subjectif de ma part) : chaque dépôt distant est associé à un dépôt local.
Personnellement, ce sont les submodules que je préfère.
Partager un projet Talend Open Studio avec git
26/03/11
Récemment, OCTO a publié deux bons billets sur les implémentations de services REST et sur leur testabilité. Je vais donc laisser ce sujet de côté pour le moment et différer le billet que je comptais écrire sur le sujet.
Depuis déjà pas mal de temps, je m’intéresse aux « forges logicielles », en particulier autour de des technologies Java. Dans ce cadre, j’ai testé plusieurs outils de suivi d’anomalies/évolutions : Mantis, JIRA, Redmine, etc.
D’après ce que j’ai pu voir, de nombreux clients utilisent Mantis pour le suivi des anomalies. Dans la forge mise en place en interne, nous utilisons plutôt Redmine (la suite des produits Altassian est également excellente, mais nécessite d’avoir le budget), en particulier pour son excellente intégration avec git :
- possibilité de lier des commits aux fiches Redmine
- pilotage automatique de la résolution et du « time-tracking » des fiches en extrayant automatiquement ces informations des commits git
- visualisation dans l’interface Redmine des diffs
- calcul et affichage de statistiques sur le dépôt du projet
Afin de pouvoir utiliser simultanément ces différents produits (Mantis du client et Redmine ou JIRA interne), j’ai pensé créer un projet Open Source permettant de synchroniser les données entre ces différents produits, en utilisant Talend Open Studio. Pour cela, il fallait donc réussir à partager ce projet en utilisant git (afin de le rendre accessible sur GitHub).
Au revoir SVN… Bonjour Git !
7/12/10
Commençons par un résumé des épisodes précédents :
- Tout a commencé avec la découverte de Git.
- Après un premier test concluant, c’est à l’atelier de rentrée de Git-Attitude que j’ai vraiment appris à utiliser Git et eu « l’effet Whaou » !
- Convaincu par l’intérêt des DCVS, j’ai commencé à travailler avec Git comme frontal de Subversion : voir ici et là.
- Après avoir joué avec Git, « Git + SVN » laisse un sérieux arrière-goût d’inachevé. Nous avons donc cherché et trouvé une solution pour coupler Git au SI, de la même manière que SVN avant lui.
La solution ayant été trouvée, il ne reste plus qu’à effectuer la migration définitive de SVN vers Git, en conservant l’historique du projet.
La suite >
Git et LDAP en entreprise
19/11/10
Le gain apporté par les gestionnaires de configuration distribués n’est plus à démontrer. Dans ce domaine, les projets libres montrent la voie, et en utilisent presque tous un, que ce soit Git, Mercurial, etc.
Cela fait maintenant quelques temps que je teste Git, y compris au travail en interface avec SVN, notre gestionnaire de configuration d’entreprise.
Pour aller plus loin dans cette utilisation, il fallait envisager de remplacer (ou de doubler) le serveur SVN central par un repository Git central (« bare repository« ). La contrainte imposée par mon administrateur système préféré étant d’avoir le même système de gestion des droits d’accès, centralisé sur notre serveur LDAP (où chaque projet est associé à un groupe d’utilisateurs).
Voici différentes pistes que nous avons envisagées pour ce faire :
La suite >
Allons un peu plus loin avec Git-SVN
12/10/10
Il y a très peu de temps, j’expliquais comment utiliser Git avec SVN dans Eclipse. C’est maintenant quelque chose que j’utilise au quotidien, que ce soit avec Eclipse ou IntelliJ IDEA, mon nouveau choucou. Dans un cas comme dans l’autre, on ne coupera pas à l’utilisation des « external tools » pour la configuration des commandes « git svn rebase/dcommit/etc. »
Après plusieurs semaines d’utilisation, j’ai voulu étendre cette utilisation à d’autres commandes, afin de voir si on pouvait pousser plus loin les interactions entre Git et SVN.
La suite >
De SVN à Git sous Eclipse
31/08/10
Il y a maintenant quelques semaines, j’ai été frappé par le virus Git. Dans la foulée, j’ai migré la gestion de configuration de mes composants pour Talend Open Studio sous GitHub. Et depuis, pour mieux maitriser cet environnement, j’ai pris ProGit comme livre de chevet.
Plus récemment encore, j’ai décidé de passer également sous Git mon environnement de travail professionnel pour le développement Java. Mais cette fois, ce n’est plus aussi simple, car on ne peut pas remplacer comme ça le serveur SVN central utilisé par les différentes équipes de développement.
Mais Git et Subversion peuvent être utilisés ensemble. On travaille sous Git en local, profitant ainsi de tous ses avantages (passage rapide d’une branche à l’autre, pour bien découpler les différents travaux, etc.), et on synchronise ce travail sous Git avec le serveur SVN.
Ce mode de travail et ses avantages ont très bien été expliqués dans le dernier article de Nicolas de Loof. En particulier, ce qui m’intéresse, c’est la rapidité de mise en oeuvre sans avoir à faire évoluer la plate-forme de développement d’un iota.
Cet article expliquant tout ce qu’il y a à savoir pour débuter avec Git et SVN, je ne recommencerai pas. Je vais donc aborder l’étape suivante : l’intégration de cette nouvelle méthode de travail dans mon environnement de développement.
Découverte de Git et de GitHub
24/08/10
Après avoir utilisé pendant quelques années Subversion, qui me satisfaisait pour la gestion des sources de mes projets personnels (composants Talend, entre autres…), j’ai décidé par curiosité de tester Git, à cause des différents articles que j’ai pu lire récemment à ce sujet, dont la quasi-totalité vente les mérites.
Lorsque l’on a l’habitude d’un gestionnaire de configuration centralisé comme Subversion, la prise en main est rude… Les concepts ne sont pas les mêmes, et lorsqu’on essaye d’appliquer ceux dont on a l’habitude, on se retrouve face à quelques problèmes : mon premier réflexe a par exemple été de chercher comment lancer le « serveur Git » avant utilisation. #FAIL, comme on dirait sur Twitter…
Heureusement, vu la popularité croissante de ce système, je n’ai eu aucun mal à trouver des tutoriels qui m’ont ré-aiguillé sur la bonne voie. Je me suis ainsi rapidement mis à « la philosophie » de Git. Effectivement, j’approuve ce que j’ai pu lire : une fois qu’on l’a essayé, on a du mal à s’en passer. Je vais y revenir… Mais avant ça, voici ma liste de remerciements et des liens qui m’ont aidé à découvrir Git :
- le site officiel, pour commencer, qui propose le programme (évidemment), mais aussi un tutoriel de mise en place, le manuel ainsi que le Git Community Book.
- ProGit, ou Git Magic, deux autres ouvrages de référence disponibles en ligne
- Understand Git conceptually pour bien comprendre les concepts de Git
- Why Git is better than X, dont le titre en dit long sur le contenu : un plaidoyer sur les avantages de Git par rapport aux autres gestionnaires de configuration
- Git attitude, fournissant à ce jour deux articles très intéressants en français sur l’installation de Gitosis (même si je ne l’utilise pas) et sur l’installation de Git avec un « prompt » gérant l’auto-complétion des commandes Git.
- Le pense-bête de Nicolas de Loof sur l’utilisation de Git avec un repository central SVN, ainsi que son article sur le refactoring d’un projet SVN sous Eclipse en utilisant Git
Avec toutes ces lectures, j’ai pu me mettre correctement à Git. Les liens ci-dessus contenant toute la littérature nécessaire pour prendre un bon départ, je vous épargnerai un n-ième tutoriel qui se contenterait de recopier ce qui existe déjà…
Le premier projet personnel qui est passé de SVN à Git, ce sont les composants Talend que je développe. Chaque composant étant dans un répertoire distinct, et constitué d’une quinzaine de fichiers maximum, j’ai jugé plus simple de les regrouper dans un unique projet.
Et c’est là que les mécanismes de Git vont m’aider. Car souvent, j’ai des idées d’amélioration (ou de création) pour plusieurs composants n’ayant rien à voir : finition du bcFileOutputOOSpreadsheet, possibilité de logs conditionnelles dans tLog4J, etc.
Il existe sur SVN un mécanisme de branches, mais passer d’une branche à l’autre et effectuer des fusions de branches une fois le travail terminé n’est pas aisé :
- temps de switch relativement longs (surtout lorsque le projet a une taille conséquente). En développement Java sous Eclipse, quand je travaillais sur plusieurs évolutions fonctionnelles (branches) différentes, j’en suis venu à cloner mon projet en associant chaque projet à une branche différente pour pouvoir changer de branche en un temps acceptable.
- de très fréquents « faux » dans les conflits remontés par SVN lors des fusions (principalement en cas de suppression, de renommage ou de déplacement d’un fichier). La gestion manuelle de ces conflits sous SVN est plus que pénible.
De ce fait, j’utilisais peu ce système, et la plupart de mes commits étaient effectués dans le trunk.
Dans Git, le mécanisme de branche est beaucoup mieux géré, et est donc au coeur du système. Le réflexe à avoir sous Git, c’est « une nouvelle idée = création d’une nouvelle branche ». Si cette idée aboutit, elle sera fusionnée dans la branche principale (master). Sinon, elle sera simplement supprimée. Voici pourquoi ça marche :
- le repository Git, étant local, créer ou changer de branche est une opération très rapide, et on n’a plus besoin de cloner son projet. La « stash » (boite à idées), permet de garder en mémoire le travail en cours sur une branche avant d’en changer, sans pour autant devoir effectuer un commit
- la fonctionnalité de fusion des branches fonctionne beaucoup mieux que sous SVN. Quand le travail sur une branche est terminé, on la fusionne dans le « master » (équivalent du « trunk »). Et les mécanismes utilisés par Git, avec ses différentes stratégies de fusion, font que ça marche vraiment bien.
Après un changement dans mes habitudes de travail, je m’y retrouve donc beaucoup plus facilement avec Git, avec une branche par évolution de composant.
Dernière étape : sauvegarder mon travail, voire synchroniser mon travail entre mes différents postes de développement. Pour cela, SVN tournait sur un serveur distant et gérait très bien ce double aspect sauvegarde/synchronisation. Jusqu’ici, Git est uniquement installé sur une de mes machines de développement.
Plusieurs solutions sont possibles :
- installer git sur un serveur distant, avec un repository « bare » (cf. les nombreux tutoriels sur le travail collaboratif avec GIt que l’on trouve en ligne) et y accéder directement par le protocole Git+SSH.
- installer Gitosis (cf. tutoriel sur Git-attitude), offrant une gestion plus fine des droits sur plusieurs projets. Cette solution a beaucoup d’intérêt dans le cadre de « l’urbanisation de Git » dans le système d’informations d’une entreprise
- utiliser un hébergeur dédié, comme GitHub.
L’utilisation de GitHub est gratuite pour les projets Open Source, et payante pour les autres. Mes composants étant justement publiés en Open Source, j’ai opté pour cette dernière solution, beaucoup plus rapide à mettre en place (un formulaire de création de compte à remplir).
Outre le repository Git, la plate-forme GitHub, propose, comme SourceForge, un ensemble d’outils de suivi de projet : un historique du projet, des pages WIKI de documentation, un bugtracker…
J’ai apprécié cet aspect « Tout en un », qui manque (encore) à Talend Exchange. J’ai donc décidé de me servir de cette base pour créer le site du projet de mes composants Talend. Par rapport à Exchange, il ne contient que les composants encore vivants (dont les fonctionnalités n’ont pas été intégrées à la version de base du produit). Si vous avez des remarques (bugs) sur mes composants, ou envie de contribuer à ce projet, c’est maintenant par là-bas que ça se passe…
Il ne me reste plus qu’à éditer les liens des composants sur Exchange pour indiquer la nouvelle adresse du support…
Google Apps Marketplace
14/03/10
J’ai déjà eu l’occasion de parler des Google Apps lors de la panne générale de Google.
Depuis cette époque, j’utilise toujours Google (et les Google Apps) :
- personnellement, pour gérer mon domaine courtine.org
- à titre professionnel, AlcionGroup ayant franchi le pas de la gestion des mails par Google
Dans les deux cas, j’en suis tout à fait satisfait, et cette gestion infogérée n’a pas à rougir face à d’autres solutions professionnelles (synchronisation avec les terminaux mobiles des contacts et des calendriers, gestion de mailing-lists, etc.). Un certain nombre d’entreprises de tailles variées a d’ailleurs déjà franchi le pas.
Il y a maintenant quelques jours, le Google Apps Marketplace a été lancé. Il fonctionne exactement comme Apple AppStore ou Blackberry App World, à cette différence près qu’on y trouve des applications fonctionnant en interaction avec les Google Apps.
On trouve ainsi des applications ERP comme myERP.com, des logiciels de gestion de projet, etc.
Toutes ces applications (comme les Google Apps), gardent les données sur les serveurs de leurs éditeurs respectifs (en “Cloud Computing”). C’est certainement ce qui sera le plus grand frein au développement de ces solutions, car on perd la maîtrise de ses données (avec donc, le risque d’éventuelles fuites d’informations).
Cette solution est à mon avis néanmoins très intéressantes pour les consultants indépendants, TPE ou PME : elles sont peu coûteuses par rapport à un investissement dans des logiciels dédiés, permettent de bénéficier d’un système d’information de qualité dont on n’a pas à se préoccuper (risque d’incendie, de vol, de crash de disque dur, etc.).
Du point de vue des développeurs, le mode de facturation de Google est très similaire à celui d’Apple : un ticket d’entrée à 100$, auquel il faut ajouter 20% des revenus si on développe des applications payantes (le mode de paiement étant assez libre : par application, par abonnement, par utilisateur, etc.). A noter qu’il est possible (pour les philanthropes) de développer des applications gratuites.
