Category Archives: architecture

Let’s GIT it started

“Pour apprendre  il faut pratiquer, pour comprendre il faut expliquer” ça ne doit pas être la citation exacte mais l’idée est là et s’applique parfaitement à GIT. Il n’y a qu’à voir le nombre de blog de geek qui éprouve l’envie irrésistible de faire un billet sur ce sujet. Je n’échappe pas à la règle, après quelques mois de pratique de ce DVCS.

Même si certain recommande de tout oublier de svn avant de se mettre à git je préfère pour ma part démarrer par une comparaison des concepts

Les concepts de SVN

Un repository svn ne gère que 3 types d’objets:

  • répertoire
  • fichier (ou plutôt la différence d’une version à une autre)
  • revision

Les revisions sont numérotées de 1 à n, elles se suivent de manière linéaire. Chaque révision pointe vers un arbre décrivant l’état du projet. Les branches et les tags n’existent pas dans un repository svn. Ce ne sont que des répertoires désignés comme branche ou tag uniquement PAR CONVENTION.

Voir  bubble up method pour approfondir

Les concepts de GIT

Un repository git gère 4 types d’objets

  • tree (répertoire en svn)
  • blob (fichier en svn)
  • commit (revision en svn)
  • tags

Et en plus des références qui sont utilisées pour désigner les branches On distingue les références des objets car ceux-ci sont immuables alors que les références sont volatiles (i.e.: HEAD est une référence qui peut pointer sur n’importe quel commit alors qu’un objet sera toujours identifié par le hash SHA-1 de son contenu).

Le stockage de cette structure est si bien optimisé que tout l’historique d’un gros et vieux projet ne prend pas plus de place qu’un seul checkout svn.

Mais surtout cet historique n’est pas linéaire comme celui de svn. Les commit sont stockés dans une structure en graphe (un  DAG pour être précis). Un commit peut avoir un ou plusieurs parents (commit avec plusieurs parents == commit de merge). Cette structure en graphe reflète de manière fidèle la notion de branche.

Voir  getting git pour appronfondir

Workflow de SVN

Svn est extrêmement simple, il y a le repository central et des checkouts partiels en local. Les seules commandes à connaitre pour débuter sont les suivantes:

# copier une révision du projet en local
svn checkout http://monprojet/trunk
# génèrer une nouvelle révision sur le serveur dont l'identifiant sera incrémenté de 1 par rapport à la revision précédente
# Par exemple: touch newFile.txt
svn commit
# mettre à jour son projet en local
svn update

La structure et le workflow simplistes de svn font qu’une bonne pratique est d’utiliser le moins de branches possible, tout simplement car les merges sont longs et risqués.

Workflow de GIT

GIT est un DVCS, donc distribué: il peut y avoir plusieurs repository égaux entre eux. Mais de manière pratique on désigne souvent par convention un repository comme central. On a donc

  • un repository central
  • des repositories locaux (contient les mêmes infos que le central)
  • des workspace locaux (contient un checkout d’un commit du repo local)
  • des  index (contient les prochaines modifications à commiter)
  • des  stash

Une utilisation classique de git est donc la suivante

#dupliquer un repository en local
git clone
#Création d'un branche (MonDevAmoi = nom de ma nouvelle branche, créée à partir de la branche nommée BrancheDeReference)
git checkout -b MonDevAmoi BrancheDeReference
#Ajout des modifications dans l'index
git add ...
#commit de l'index dans le repo local
git commit ...
#récupération d'éventuelles modifications sur le repository central
git fetch
#merge de ces modifications avec notre branche
git merge
#Partage des modifications locales avec le repository central
git push

Avantages de git

Après cette présentation on se rend surtout compte que git est plus complexe. Quels avantages apporte cette complexité?

Rapidité

Toutes les opérations se font en local, git est plus rapide de plusieurs ordres de grandeur.

Merges rapide et facile

La structure de données de git a été pensée pour répondre à ce besoin, git est bien plus intelligent que svn sur ce point. Il devient possible de faire des  feature branch et d’envisager des  workflows évolués

Un historique propre

C’est tout de même la fonctionnalité principale d’un système de gestion de code: conserver l’historique. Conserver l’historique c’est bien, avoir un historique propre et utile c’est mieux. Combien de repository svn sont pollués par des commits du type “oups erreur lors du merge” ou “oublié de commiter un fichier” ?

Git ne résout pas ce problème de manière magique mais il donne les outils pour améliorer la situation

  • L’index:

L’index est l’espace où l’on ajoute les modifications que l’on va commiter, il formalise une bonne pratique qui consiste à préparer et valider un commit avant de le faire réellement.

  • La modification d’un commit:

Mais même avec l’index, il reste difficile de faire des commits “parfait”. Un fois un commit créé il est impossible de le modifier (signé avec un SHA-1) par contre il est tout à fait possible de le supprimer pour le remplacer par un autre tant que l’on a pas “pusher” ses commit vers un repo distant. C’est le  git commit amend qui permet de modifier un commit existant.

  • La revision de l’historique:

Et si ce n’est pas suffisant  git squash et rebase permettent de manipuler l’historique lorsque l’on merge des branches.

Par exemple une feature branch qui contient des dizaines de commit peut se transformer en un seul commit lorsqu’on la merge dans la branche principale.

GitHub

Il faut l’essayer pour comprendre. La fonction phare de github est la pull request qui exploite à merveille les capacités de merge de git. La pull request est aussi le moment idéal pour faire un code review.

Inconvénients de git

La courbe d’apprentissage: il faut investir en formation pour bénéficier pleinement de git.

L’outillage, par encore aussi mature que ce qui est disponible pour svn mais ça viendra, pour l’heure la ligne de commande est ton amie.

Git Flow VS pull request

Git permet de mettre en oeuvre de nombreux modèles de développement. Deux en particulier ont émergé:  Git Flow et  github pull request. Le premier est plus orienté workflow d’entreprise aux release régulières mais espacées, le deuxième est adapté aux projets open source, de nombreux contributeurs et un nombre restreint de “committers” qui valident les développements.

Mais rien n’empêche d’utiliser les deux: On peut très bien pusher vers github les features branchs de git flow. Et faire une pull request sur celle-ci pour les merger sur develop.

C’est la grande force de git on peut imaginer et mettre en oeuvre toute sorte de workflow, un autre exemple pour la route.

Pour aller plus loin

 

UPDATE: Think like (a) git est de loin le meilleur tuto sur git

Je maintien une liste de délicieux liens à propos de git mais la meilleure façon de se documenter sur Git est probablement de googler Scott Shacon, employé de github c’est l’évangéliste n°1 de git il a entre autre commis:

Mais si vous en avez assez de la théorie voici pour la pratique

TATA: Automatiser, Tester, Architecturer

Si au lieu de se concentrer sur les mauvais points distribués par thoughworks on regarde leurs recommandations on voit émerger un patern:

  • Automatiser
    • Continuous delivery: en lien avec devops, le boulot et terminé si et seulement si le code est en production
    • Infrastructure as code: c’est la révolution IAAS initié par Amazon EC2, poursuivie par les Chef et autre Puppet
    • DevOps: Mettre de l’agile entre les devs et les ops, à moins qu’avec les 2 points ci-dessus, ce soit que les devs vont enfin pouvoir se débarraser des ops?
    • Automated database deployment: voir flyway
  • Tester
    • Test Load Balancer: pour paralléliser les tests
    • Thoughtful caching : et oui le cache n’est pas une solution magique à tous les problèmes de perf.
    • Early performance tests : Je repéte: il n’y a pas de solution magique à appliquer à la fin du projet pour résoudre les problèmes de perf.
  • Architecturer
    • Evolutionary database: que les DBA nous laisse rajouter une colonne sans remplir un formulaire en 3 exemplaires.
    • Evolutionary architecture: A mort le big design up front.
    • Event API: pourquoi ce qui marche pour l’UI ne marcherait pas pour le backend ?
    • Event sourcing : L’idée est de conserver les logs transactionnels de la base pour l’audit, l’historique, le débuguage, à creuser…

Automatiser, Tester, Architecturer et recommencer je propose donc un acronyme récursif:

TATA: TATA Automatiser, Tester, Architecturer là maintenant vous pouvez vous mettre à coder.

ThoughtWorks Technology Radar 2011: the good parts

Le thoughtWorks Technology Radar 2011 a fait la une récemment en tapant maladroitement sur GWT:

GWT is a reasonable implementation of a poor architectural choice. GWT attempts to hide many of the details of the web as a platform by creating desktop metaphors in Java and generating JavaScript code to implement them. First, in many ways, JavaScript is more powerful and expressive than Java, so we suspect that the generation is going in the wrong direction. Secondly, it is impossible to hide a complex abstraction difference like that from event-driven desktop to stateless-web without leaky abstraction headaches eventually popping up. Third, it suffers from the same shortcomings of many elaborate frameworks, where building simple, aligned applications is quick and easy, building more sophisticated but not supported functionality is possible but difficult, and building the level of sophistication required by any non-trivial application becomes either impossible or so difficult it isn’t reasonable.

 

Mais il n’y a pas que GWT qui en prend pour son grade la base de données déguste elle aussi:

We often see problems caused by manual configuration of firewalls and load balancers, and especially by DBAs cutting and pasting SQL scripts to run against production databases

 

It is startling to us that we continue to find new systems in 2011 that implement significant business logic in stored procedures. Programming languages commonly used to implement stored procedures lack expressiveness, are difficult to test, and discourage clean modular design. You should only consider stored procedures executing within the database engine in exceptional circumstances, where there is a proven performance issue.

Ainsi que les portails java

 A continuing cause of delivery problems lies in the use of Java Portal Server packages. These problems occur in both open source and commercial portal platforms. The promised productivity of these platforms is hindered by their complex and unwieldy programming models and difficulty in automating deployment, data migration, and tests.

Concernant les portails on remarquera qu’en guise de portail Google avec Google + se contente d’une barre de navigation unifiée en haut de tous ses produits.

Ce ne serait pas Thoughworks s’ils n’ajoutaient pas un clou dans le cercueil de WS-*

Previously our advice has been to tread carefully when using the WS-* stack beyond the basic profile. Given the progress and acceptance of simpler web-as-platform techniques such as REST and OAuth and the known issues with the WS-*, it should only be used cautiously.

Dans le prochain billet on va regarder ce qu’ils mettent en avant

Github, Cloudbees, Feature Flags

Quand les enfants ne sont pas là le geek code 😉

Mettre en oeuvre un processus d’intégration continue peut se faire rapidement, avoir une suite de test unitaire couvrant de manière satisfaisante son code est une autre histoire… Particulièrement sur un “code  legacy” (qui a été écrit sans test unitaire) ,  trop souvent les bugs sont découvert en production par les utilisateurs finaux.  Il faut alors revenir en arrière, reproduire et corriger le bug dans un environnement et re-livrer plus tard, sans parler d’une éventuelle reprise des données qui auraient été corrompues. Oui il y a du vécu.

Une technique pour réduire les effets néfastes d’un bug en production est de déployer progressivement à des populations restreintes les nouveautés. Pour cela il faut séparer la livraison du code de l’activation des fonctionnalités qu’il contient.

Un simple if/else peut suffire, on parle de feature flags chez Flikr.

if (newStuffIsOn) {
	doIt
} else {
	doNot
}
Voilà donc ce que j’ai codé ce week-end… Bon un peu plus en fait. Car il faut un moyen propre et élégant de gérer, d’activer et de désactiver ces flags en production.

Voici donc Feature Flags

L’idée est de gérer les flags dans un enum:
public enum Flags implements FeatureFlags {
    ONE("First Feature Flag"),
    TWO("Second Feature Flag", FlagState.UP),
    THREE("Third Feature Flag");
}
if (ONE.isUp()) {
	doIt
} else {
	doNot
}
Feature Flags génére dynamiquement à partir de l’enum une page html pour activer désactiver ces flags en live, mais aussi une interface RESTful pour les manipuler comme on souhaite.

RESTful

GET http://yourhost.net/flags/ONE pour connaitre l'état
POST http://yourhost.net/flags/ONE pour inverser l'état
PUT http://yourhost.net/flags/ONE avec UP ou DOWN en contenu pour forcer l'état d'un flag
Rien de fantastique que ce soit fonctionnellement ou au niveau du code mais il s’agissait aussi d’un pretexte pour me mettre à git et github

GitHub

Quelle claque. J’ai mis du temps à comprendre pourquoi Linus disait que svn ne marchait pas par conception, après tout ça a marché pour moi pendant des années. Git est clairement le bon concept. La preuve: github, il n’existera jamais de svnhub, avec github nous sommes tous à un click de pouvoir contribuer à des milliers de projets open source. D’ici quelques années github aura produit un impact majeur sur la croissance et la vitalité de l’open source. En fait c’est déjà le cas, mais j’ai la conviction que l’on a encore rien vu. Un peu comme les moteurs de blogs ont déclenché la vague web 2.0 du web participatif. On peut parler d’open source 2.0.

Cloudbees

Deuxième claque. Le projet Feature Flags contient une webapp de démo, le plus simple pour montrer ce que fait Feature Flags est encore une démo (vous allez pouvoir découvrir mes talents de designer web, please fork it ! du html là aussi). Mais héberger un war java sur Internet a toujours été un problème. Les différents clouds publiques apportent des solutions. Avec cloudbees déployer du code java est presque aussi simple qu’uploader une appli php. Il s’est écoulé une petite 1/2heure entre le moment où j’ai décidé de m’inscrire à Cloudbees et le moment où mon application était live, le plus long a été de lire un peu la doc. Petite déception, il n’est pas possible n’était pas possible hier de déployer directement un war généré dans le jenkins de DEV@cloud vers le tomcat RUN@cloud.

Age d’or du développeur

Ajouter à ça le mobile (android), html 5, l’adoption des méthodes agiles, le développement vit un nouvel age d’or.

La qualité logicielle

Je viens de lire comme du petit lait le dernier livre blanc de Xebia sur la qualité logicielle. On apprécie toujours énormément lorsque d’autres expriment mieux qu’on ne saurait le faire ce que l’on pense déjà. Si vous êtes un “artisan du logiciel”, nul doute que vous vous y retrouviez aussi.

Les principes énoncés sont ceux que je m’efforce de mettre en oeuvre au quotidien, voici donc petit tour d’horizon des outils utilisés. Continue reading →