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.
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.
