Blog myBlog = BlogFactory.getWordPressBlog();
Article tagué SVN
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.
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 >
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.
Changement d’hébergeur vers un serveur dédié
6/04/10
Depuis son ouverture, il y a un peu plus d’un an (le 14 février très exactement), ce blog était hébergé chez 1&1, à l’adresse http://www.bcourtin.info/blog/ (que je laisse ouverte pour le moment, même si je ne la mettrai pas à jour).
1&1 m’a toujours convenu, avec une qualité de service correcte pour un prix attractif (8Go de stockage, 15 bases de données MySQL… et tous les services usuels pour moins de 30€ TTC par an). Note : ne la cherchez pas, cette offre promotionnelle n’existe malheureusement plus.
Ce n’est donc pas par mécontentement que je change d’hébergeur, mais pour franchir le cap du serveur dédié. J’ai finalement opté pour l’offre d’hébergement de mon registrar Gandi, qui est très modulaire puisqu’on achète un nombre quelconque de “parts” (à 12€ HT par mois la part de 8Go de stockage, 256 Mo de RAM dédiée, et un tiers de coeur dédié).
Ce serveur dédié me permettra de jouer avec les serveurs virtuels d’Apache (et ainsi de ne plus avoir de sous-répertoire dans l’URL de mes sites), et d’héberger de manière permanente un serveur Subversion.
Note : je n’ai pas changé d’avis par rapport à cet article, et je conserve à domicile mon serveur Java/J2EE : l’unique part de serveur dédié Gandi me sert à héberger des sites PHP/MySQL, mais elle est très largement insuffisante pour espérer faire tourner des serveurs d’applications Java (et en particulier un serveur d’intégration continue qui est très gourmand en puissance de calcul).
Migration du blog
La migration du blog Dotclear vers mon nouveau serveur s’est passée sans aucun accroc. Pour ceux qu’une telle opération effraie, voici la marche à suivre, pas à pas (je suppose que MySQL, Apache et PHP sont correctement installés) :
- export de la base de données (sous la forme de scripts SQL
- modification de ces scripts, pour prendre en compte le changement d’environnement (adresse du blog, adresse des ressources qui passent de “/blog/public/…” à “/public/…”, etc.)
- import de la base de données sur le serveur, en ligne de commande (après avoir créé un utilisateur et une base). Je passe rapidement sur les détails techniques de cette opération, que l’on trouve sur n’importe quel bon tutoriel.
- export des fichiers du site via FTP
- import des fichiers sur le nouveau serveur, dans un répertoire dédié (le tout appartenant à l’utilisateur www-data pour qu’Apache y aie accès)
- modification du fichier de configuration, pour prendre en compte les paramètres de la base
- création d’un serveur virtuel Apache, écoutant à l’adresse http://blog.courtine.org/ et pointant vers ce répertoire. Là encore, un autre bon tutoriel pourra s’avérer nécessaire si vous ne maîtrisez pas le sujet.
Enfin, après un redémarrage d’Apache (“/etc/init.d/apache2 restart”), le blog devrait être accessible, avec les plugins, l’historique des articles/commentaires, les ressources… de l’ancien.
Vous aurez d’ailleurs noté que pour fêter cette migration et différencier ce “nouveau blog” de l’ancien, le thème a changé (j’ai au passage intégré à celui-ci un bloc de publicités Google Adsense : le but étant de déterminer quelle par de l’hébergement ce bloc peut financer…) !
A très bientôt donc pour de nouveaux billets techniques !
Installer un serveur dédié
10/03/09
Le développement, ce n’est pas seulement un travail… c’est aussi une passion : ce sont juste les projets et les technologies qui changent ! Il y a quelques temps, je me suis dit qu’il n’y avait pas de raison pour que mes projets personnels soient moins bien développés que ceux sur lesquels je travaille dans un contexte professionnel. J’ai donc décidé de sécuriser mes développements personnels :
- utilisation d’un gestionnaire de configuration ;
- intégration continue, tests et déploiements automatisés des builds réussis ;
- etc.
Pour cela, il me fallait un serveur, distinct de ma machine de développement.
