Romain Soufflet, free software engineer

Transition Devops (1er partie) : Les erreurs à éviter

2020-10-16T11:16:32+00:00

De nos jours, le modèle “Devops” attire de plus en plus mais se conçoit à travers de nombreux changements. Le fait de vouloir intégrer rapidement de tels changements peut se solder par des échecs et une frustration décourageante.

Cet article est un moyen d’expliquer quelles peuvent être les difficultés rencontrées à travers une telle démarche. Il s’agirait de pouvoir identifier pour quelles raisons se créer de telles difficultés, comment faire pour les éviter et intégrer plus simplement un modèle Devops.

Il existe trois problèmes principaux qui pourraient expliquer le fort taux d’échec d’une transition “devops” :

La volonté de se transformer, d’évoluer vers un modèle “devops” mais sans rien changer dans son organisation
Le fait de demander à une équipe de se débrouiller seule pour « faire du devops »
Le manque d’objectifs mesurables et concrets

Se transformer sans rien changer

De nombreux articles vantent les mérites de la culture “devops” et les bonnes pratiques qui en découlent. Pour autant vous n’y trouverez pas de plan d’action concret et réalisable pour intégrer cette culture “devops”.

Même si le CEO ou CTO peut avoir une vision claire de ce qu’il aimerait obtenir après transformation, c’est la transmission aux différents profils de l’entreprise qui s’avère être le point le plus complexe et le plus problématique.

Cette différence de point de vue entre la direction et le reste de l’entreprise est le point de départ de nombreux problèmes. Ces problèmes peuvent prendre différentes formes et apparaissent généralement avec le schéma suivant:

Le CEO/CTO produit une demande pour faire davantage de Devops
Le manque d’information sur les actions précises à entreprendre se solde par la création d’un pôle devops
L’entreprise poursuit son fonctionnement traditionnel sans rien changer à ses pratiques

L’effet pervers que dessine ce schéma est que cette nouvelle unité Devops n’a pas la possibilité de faire ses preuves. L’entreprise continue de fonctionner de la même manière sans prendre en compte les changements qu’un pôle Devops pourrait suggérer. Les personnes et les compétences qui composent ce nouveau pôle ne sont pas mises en avant, voir même ignorées. Dans ce cas il n’y a pas d’intégration à proprement parler.

Prenons l’exemple suivant: une nouvelle unité Devops a mis en place un pipeline d’intégration continue. Dans le schéma décrit précédemment, cette unité a travaillé en autonomie sur ce sujet et cela sans la participation des équipes qui devront se servir dudit sujet.

Dans ce cas le résultat est toujours le même: les équipes qui se verront imposer ce nouveau pipeline devront modifier leurs habitudes, elles devront s’adapter à ce nouveau système. Le problème principal n’est pas la qualité du nouveau service, la vraie source de frustration pour ses équipes, c’est le manque d’informations. Sans informations préalables sur le changement et travaillant avec un ancien modèle qui, sans être parfait est souvent fonctionnel, les équipes ne comprennent pas ce qu’elles considèrent comme un changement sans fondements apportant davantage de contraintes sans résoudre de problèmes apparents.

Pour ces équipes déjà en place, la transition DevOps se pose donc comme une contrainte, un élément perturbateur dans leur travail.

Pour régler ces problèmes, chaque équipe qui sera impactée par les changements liés à la transition Devops devra faire partie du processus global. Sans cela, toute nouvelle initiative sera jugée comme inappropriée et mettra en danger la cohérence globale du projet. L’intégration de la culture Devops doit se faire en douceur en prenant en compte les individus si l’on ne veut pas créer un chaos nuisible pour l’entreprise. Il s’agit ici de ne pas “brusquer” les composantes de l’entreprise en leurs imposants des processus qu’elles ne comprennent pas et dont elles n’ont aucunes connaissances préalables.

Les équipes « Devops »

Les nouvelles entités Devops ou les anciennes à qui l’on demande de “faire du Devops” sont aussi dans une position délicate : elles ne savent pas quoi faire pour être “davantage devops”.

La conséquence directe de ce flou derrière le terme Devops se traduit par une incompréhension de la part des équipes qui doivent devenir devops sans comprendre ce que cela sous entend et comment le faire.

Les notions Devops étant assez nouvelles dans le monde de l’entreprise et sujettes à différentes interprétations, il devient dès lors complexe d’aligner les visions de tous derrière celles-ci.

Si la définition précise du Devops et de la culture qui en découle vous intéresse, j’ai écris un article qui pourra vous permettre de mieux intégrer ces notions plurielles.

Même en ayant une définition commune, les équipes ne peuvent pas s’en sortir seules puisque le point principal de la culture Devops se base sur la communication et l’entraide.

C’est pour cette raison que les initiatives demandant à une seule équipe de « faire plus de devops » sont vouées à l’échec. Comment une équipe seule pourrait permettre à toute l’entreprise de mieux communiquer et améliorer les relais de travaux ?

Chaque équipe doit être impliquée dans cette transition, chaque équipe doit pouvoir y voir son propre bénéfice dans les changements de l’entreprise. Ce n’est qu’en voyant ces bénéfices que les équipes voudront y participer.

La culture devops nous apporte aussi plus de vitesse dans les déploiements. Cette vitesse s’exprime à travers l’automatisation de certains process. Certaines personnes le vivront comme une opportunité de créer de nouveaux outils, d’autres y verront la menace d’être remplacés par ces scripts et de perdre leurs emplois.

Il est illusoire d’imaginer que l’ensemble du processus de déploiement sera automatisé. Il est tout autant illusoire de s’imaginer que l’on aura plus besoin de nos employés une fois la transition entamée. Malgré tout, cela reste une peur très présente dans l’entreprise.

Les outils et pratiques devops rencontreront donc une forte résistance sur le plan humain et organisationnel. Tous les nouveaux développements ont des bugs, c’est un effet que l’on ne peut éviter. En plus des problèmes déjà évoqués, ces nouveaux bugs seront autant de nouveaux arguments pour les anti-devops.

Il est donc important dans chaque transition devops de surveiller les réactions de chaque équipe comme le lait sur le feu. L’idée selon laquelle la culture Devops serait néfaste et contre-productive peut se répandre très vite et il vous sera alors encore plus difficile de persévérer dans cette direction sans soutien.

La vision et les objectifs du changement

Toute transformation implique un état initial et un état final. Prenons un instant pour y réfléchir :

Un état initial dans lequel votre entreprise fonctionne mais pas de manière optimale, vous aimeriez y apporter des améliorations notamment à travers la culture Devops
Un état final, idéal, dans lequel les points d’améliorations sont des acquis

Il est donc primordial de se poser la question suivante pour aligner tout le monde sur la transition : Que veut on changer dans notre organisation ?

Quand il s’agit d’augmenter le nombre de déploiements par exemple, les questions qui suivent seront “combien en faisons-nous actuellement ?” et “combien souhaitons-nous en faire à l’avenir ?”.

Dans le même raisonnement, il est aussi important de définir ce que l’on souhaite garder. Il est, par exemple, courant de voir une étape de validation humaine avant les passages en production. Puisque passer de 4 déploiements par an à 4 déploiements par mois ne changera pas le besoin de validation humaine, les équipes devront prendre en compte ce nouveau rythme dans leur emploi du temps et dans leur gestion quotidienne. Ce sont des éléments à discuter avant d’entreprendre les changements.

De manière implicite et parce que cela fait aussi partie de la culture devops, il est nécessaire de pouvoir mesurer les objectifs. Dans l’exemple précédent, la mesure de l’objectif et de la performance est évidente mais si votre objectif est une meilleure communication cela sera beaucoup plus compliqué de trouver les bons indicateurs et les bons objectifs.

Ce point est particulièrement important car cela fait partie des éléments derrière lesquels les équipes pourront se concentrer et réfléchir ensemble. Les objectifs seront donc un moteur de transition devops, une façon d’introduire du travail d’équipe entre équipes.

Conclusion

Même s’il existait la possibilité dès aujourd’hui de créer le plan parfait qui corresponde totalement à votre organisation, l’application de ce dernier restera difficile. J’ai pris l’habitude de dire à mes clients et collaborateurs que les problèmes les plus importants sont rarement techniques, ce sont davantage des problèmes humains.

Tout changement rencontrera de la résistance. Il y aura des profils qui auront peur de perdre leur emploi. Certains seront très heureux de changer d’équipe, d’autres se sentiront contraints de partir. Les difficultés humaines liées au changement doivent être le centre d’attention principal de toute transformation dans une entreprise.

J’aborderai la transition devops de manière plus concrète dans la deuxième partie de cet article. Dans le but de vous donner les clefs pour mener ces changements avec succé.

Transition DevOps en terrain difficile

2020-01-29T08:26:32+00:00

Retour d’expérience d’une transition DevOps dans un contexte à fortes contraintes techniques et humaines.

De nos jours, beaucoup d’entreprises se transforment et adoptent la culture DevOps. Les bienfaits de cette transformation semblent aujourd’hui faire partie des faits établis. Cependant, bien que de nombreux articles en parlent, mener la transformation n’est pas toujours simple.

Les slides sont disponnibles en ligne

5 minutes pour les conteneurs (docker)

2019-05-22T12:32:10+00:00

En informatique, coexistent de nombreuses technologies. Dans tout cet écosystème, il y a des technos qui naissent, d’autres qui meurent, mais il y a surtout des technos tellement hype et funky que passer à côté est un exploit à part entière.

Dans ces technos hype, on peut trouver docker. Si vous travaillez en informatique, vous avez sûrement entendu parler de docker ou plus généralement de la notion de conteneur.

Par contre, en avoir entendu parler ou l’avoir utilisé ne garantit pas la compréhension de l’ensemble ni sa bonne utilisation. Alors si on en parlait ? Notre objectif : 5 minutes de lecture pour comprendre les conteneurs.

C’est quoi un conteneur en informatique ?

Avant d’aborder le sujet des conteneurs je vais faire une digression sur les processus.

Sur une machine, qu’elle soit virtuelle ou physique, on a un OS (Operating System) dont le travail est de gérer des processus et leurs liens avec le matériel. Basiquement, les applications que votre entreprise produit seront des processus que l’OS pourra exécuter et gérer sur les machines de production.

Pour qu’un processus fonctionne correctement, en simplifiant il lui faudrait 3 éléments:

De la puissance de calcul (accès au CPU, la RAM, les ressources matérielles)
Du stockage, pour garder les données qu’on peut réutiliser plus tard
Du réseau, pour communiquer avec l’extérieur, notamment les clients

Le conteneur, c’est la boîte qui va donner ces 3 éléments aux processus.

Pourquoi utiliser un conteneur ?

Un processus, avec ou sans conteneur, effectue le même travail. J’irai même jusqu’à dire qu’il va légèrement plus vite sans conteneur. Alors pourquoi cette euphorie autour des conteneurs ?

En un mot : l’Isolation. C’est là que le mot conteneur est très bien choisi : on place le processus dans une boîte où il se retrouve seul.

Un conteneur n’a pas accès aux autres conteneurs, ils ne savent pas que d’autres peuvent exister sauf si on les relie entre eux explicitement. Ainsi, en regardant la configuration de nos conteneurs, on sait quelles applications tournent et comment elles communiquent entre elles.

Donc pour faire une liste non-exhaustive:

Sécurité, un processus A n’a pas accès aux fichiers manipulés par le processus B
Sécurité, le processus n’a accès qu’aux ressources réseaux qu’on a défini pour lui
Portabilité, quel que soit l’OS sur lequel on utilise nos conteneurs, ils fonctionneront de la même manière
Possibilité pour les développeurs d’utiliser le même conteneur dans leurs phases de tests et en production et ainsi réduire les sources d’erreurs
Clarté de l’infrastructure, lister les conteneurs et leurs configurations suffit pour présenter l’ensemble de la solution déployée

Doit-on dire « Docker » ou « Conteneur » ?

Alors oui, il y a souvent confusion parce que docker est l’outil le plus utilisé et le plus connu actuellement pour faire des conteneurs mais en réalité ce n’est qu’un moteur parmi d’autres. N’hésitez pas à vous renseigner sur le site d’Open Container Initiative (OCI).

La volonté d’OCI est de définir un standard industriel pour utiliser les conteneurs. Pour cela, il définit deux normes. La première est runtime-spec qui spécifie comment doit être exécuté un conteneur. La deuxième est image-spec pour définir comment sauvegarder, partager et réutiliser les images de conteneur.

Les images ?

Une image de conteneur est une archive qui contient tout ce dont votre conteneur a besoin pour être exécuté. Vous pourrez donc l’utiliser sur différentes machines.

Ces images peuvent être partagées, copiées, modifiées puis repartagées. Si je prend l’image du projet nginx par exemple, elle est quotidiennement utilisée par des milliers d’entreprises. Nous pouvons donc en déduire que l’image est fiable.

On avait dit 5 minutes !

Arf, j’ai dépassé, mais au moins vous avez du contenu pour pouvoir répondre si on vous parle de conteneur maintenant.

À vous de jouer ! ;)

Tranformez votre équipe de l'intérieur

2019-01-08T10:26:32+00:00

Je propose une méthode concrète, mais pas forcément simple, pour parvenir à mettre en place dans votre équipe des bonnes pratiques tel que le « Code review », les tests, une CI (« Continuous Integration ») et une CD (« Continuous Deployment »).

Le but étant de déclencher, dans vos équipes des effets secondaires : l’entraide, la communication et un apport de valeur plus rapide et plus efficace pour les clients finaux

Devops et SRE, de quoi s'agit-il ?

2018-08-11T16:38:25+00:00

Dans le précédent article je parle de la production et de ce que cela implique de s’en occuper. Mais quels rapports avec les termes DevOps et SRE ?

Je ne prétends pas pouvoir donner une définition claire et universelle pour ces mots mais j’aimerais pouvoir les démystifier et en rendre la compréhension plus accessible.

Dans la plupart des projets informatiques, nous avons une équipe de développeurs et une équipe d’administrateurs systèmes. Regrouper des unités fonctionnelles est une construction naturelle que l’on retrouve dans la plupart des entreprises. Il en va de même pour l’équipe comptable, l’équipe commerciale et toutes les autres. Cependant cette séparation en différents pôles engendre de nombreux problèmes de communication.

Les développeurs sont amenés à créer de nouvelles fonctionnalités, répercuter les changements demandés par les clients dans l’application qu’ils construisent et corriger les éventuelles erreurs remontées par les utilisateurs. Leur mission est caractérisée par les évolutions du code source qu’ils écrivent, par le changement et l’ajout de fonctionnalités.

Les administrateurs de leur côté sont en charge du maintien en conditions opérationnelles. Chaque mise à jour peut mettre en danger l’intégrité des produits et des services de l’entreprise. C’est pourquoi chaque changement doit être appréhendé comme un potentiel risque. Leur mission est donc la mise en place et la gestion de la stabilité du produit

Par définition, ces deux rôles sont amenés à être en conflit. D’un côté les développeurs apportent du changement et de l’autre côté les administrateurs cherchent à stabiliser les environnements de production. C’est pourquoi les deux rôles sont souvent opposés et que le dialogue est difficile entre ces profils.

C’est dans ce contexte que naissent les notions Devops et SRE. Ce sont ces notions que je souhaite développer en parlant de ce qu’est la culture DevOps, ainsi que du poste SRE.

La culture DevOps

La culture DevOps se présente, dans un premier temps sur un plan organisationnel. Il s’agit d’abolir les barrières entre les équipes de développement et les équipes d’administrateurs. Le but étant de réconcilier des missions ayant des objectifs différents: Nous travaillons dans la même entreprise, pour les mêmes clients, nous devrions le faire ensemble.

En s’affranchissant de ces barrières, on permet aux développeurs et administrateurs de communiquer et collaborer. On obtient ainsi des développeurs qui prennent conscience de ce qu’est la production et comment on s’en occupe, mais aussi des administrateurs capables d’automatiser leurs besoins en maintenance et les mécanismes de mise en production.

La collaboration permet aussi de redéfinir comment l’application se construit. On passe d’un modèle en deux étapes dans lequel des développeurs proposent un paquet livrable et des administrateurs installent celui-ci tant bien que mal, à une collaboration à tous les niveaux de conception.

En généralisant un peu, on arrive à un processus qui ressemblerait à ça:

Et pour chacunes de ces étapes, les différents profils pourront s’entraider:

Définir les tâches suite aux idées ou besoins émis par le client
Développer / Exécuter cette tâche
Revue de code et automatisation des tests sur une infrastructure la plus proche possible de ce que sera la plateforme de production
Tester fonctionnellement, directement par le client si possible, sur un environnement clone de la production
Automatiser le déploiement en production

On introduit de cette manière la notion de pipeline de production, celle-ci étant à l’image des chaînes d’assemblage automobile. On peut parfois parler d’usine logicielle pour désigner les chaînes telles que celles-ci.

Vient ensuite la mise en place de l’amélioration continue. Les équipes techniques se réunissent autour d’une table et prennent le temps d’étudier leurs propres manières de travailler. Elles identifient les passages douloureux afin d’apporter les corrections leur permettant d’augmenter leur vitesse et leur fiabilité.

En appliquant cette méthode régulièrement, on se laisse le temps de faire évoluer les us et coutumes de l’entreprise progressivement, au rythme des humains qui travaillent sur le projet.

C’est ainsi que l’on comprend l’une des notions clefs de l’implémentation de la culture DevOps: tout le monde est DevOps et tout le monde travaille dans l’intérêt de l’équipe. Il y a donc une très forte composante humaine dans l’équation.

Différentes définitions et conflits

La question qu’on peut naturellement se poser est : « Comment mettre en place cette culture DevOps dans mes équipes ? ». Je n’ai malheureusement pas de réponse toute faite à cette question et suivant l’entreprise, les projets et les équipes en place, les grandes étapes peuvent changer.

Il y a souvent une confusion entre culture et profil DevOps, créant deux schémas récurrents dans le monde de l’entreprise actuel:

Un premier schéma où l’équipe de développeurs est renommée équipe DevOps: Ils ont une liberté totale sur leurs déploiements mais n’ont plus de support d’administrateurs systèmes pour les aider à s’occuper de la supervision, de la sécurité, de la redondance des services et des autres sujets spécifiques aux environnements de productions.

Un second schéma où l’équipe d’administrateurs est renommée DevOps: Ils gardent les mêmes rôles et attributions mais on leur demande en plus d’automatiser malgré le fait qu’ils n’ont pas forcément les compétences en développement ou l’expérience pour le faire.

DevOps est une culture. On peut parler de mouvement, d’un ensemble de bonnes pratiques à la limite mais pas d’une discipline en tant que telle. Ce sont des facteurs humains qui me conduise à déployer des solutions techniques.

Il n’y a pas de consensus sur une définition claire et par conséquent personne n’a la même. La plupart des offres d’emplois ou de missions portant le titre DevOps ont du mal à définir leur besoin. Les entreprises recherchent donc des profils très avancés techniquement sur une multitude de domaines et bien entendu, le mouton à 5 pattes n’existant pas, ces offres ne sont pas pourvues.

De plus, lorsque le poste est pourvu il est très difficile pour un profil seul de mettre en place tous les outils dont l’entreprise a besoin et même si les outils sont installés et configurés, faut-il encore que les autres employés s’en servent.

Par conséquent, répondre à la question « Comment mettre en place cette culture dans mes équipes » reste une tâche très difficile. Pour bien comprendre les actions à mettre en place, nous avons besoin de creuser encore un peu le sujet DevOps.

C’est ici que l’on introduit la notion de SRE.

SRE et DevOps partagent les même principes fondateurs et beaucoup voit SRE comme une implémentation spécifique du mouvement DevOps avec quelques extensions.

Je compte tout de même écrire prochainement un article sur la reprise de projet et l’implémentation de bonnes pratiques pour une transition vers une culture DevOps.

SRE: Site Reliability Engineer

Ben Treynor, le fondateur de l’équipe SRE chez Google, dit que c’est lorsque l’on donne les tâches d’administration à une équipe de développeurs, qu’émerge la notion de SRE.

Il est commun d’entendre que SRE est une implémentation concrète de la culture DevOps.

Bonne nouvelle, on parle bien de profil SRE puisque le terme Engineer en anglais fait référence à un ingénieur, donc une personne.

Commençons par discerner 5 piliers dans la culture DevOps:

Faciliter la communication dans l’entreprise
Accepter et banaliser les erreurs
Appliquer des changements plus petits mais plus fréquents
Automatiser les tâches les plus chronophages
Relever tous les indicateurs qui pourraient être pertinents

Et pour chacun de ces points, nous verrons comment les profils SRE l’implémentent.

Faciliter la communication dans l’entreprise

Commençons par détailler l’aspect communication qui porte davantage sur l’organisation que sur des problématiques techniques. Il s’agit ici, d’apporter un véritable esprit d’équipe dans lequel on sensibilise chaque personne aux enjeux auxquels nous devons faire face. J’en parle dans un précèdent article (en anglais) mais aussi dans mon intervention Comment moderniser l’organisations de votre équipe de développement

On oppose souvent les organisations en silos à la culture DevOps. Le silos c’est un grand conteneur à grains opaque que l’on compare au fonctionnement des équipes refermées sur elles-mêmes. À l’image de ces conteneurs, nous retrouvons un fonctionnement opaque (manque de communication) et le moins de contacts possible avec l’extérieur.

L’organisation en silos mène parfois à des situations gênantes ou deux équipes peuvent travailler sur le même sujet sans en avoir conscience. Cette organisation peut également créer des situations dans lesquelles, une équipe peut partir 6 mois sur un projet qui n’apporte que très peu de valeur à l’entreprise.

Cependant détruire ces silos et rétablir la communication peut parfois être mal vécu, n’oublions pas que les équipes sont constituées d’êtres humains qui ont leur repaires et leurs habitudes. J’ai globalement pu observer que rétablir la communication permet de faire naître une meilleure ambiance de travail et économiser du temps mais cela passe forcément par une période transitoire qui n’est pas toujours facile à vivre.

De plus, une fois que la communication revient, il faut rester vigilant afin de maintenir ce niveau de communication. C’est un effort constant à fournir, au risque de tomber de nouveau dans une organisations en silos.

Dans ce contexte, notre profil SRE saura mettre en place les outils permettant aux équipes de communiquer. Que cela passe par des listes de diffusions ou des feuilles de papier collées aux portes des autres bureaux.

L’incorporation d’une personne ayant une culture DevOps ou ayant le rôle SRE est aussi une bonne occasion d’identifier les manques de communication entre équipes.

Accepter et banaliser les erreurs

Le deuxième aspect de l’approche SRE concerne la prise de risque et la tolérance aux erreurs. C’est contre-intuitif pour une entreprise et par conséquent l’un des points les plus difficile à mettre en place.

On va d’abord définir ce qu’est une erreur, et on va se mettre d’accord sur un taux acceptable d’erreur, sur une marge de manœuvre. Dans notre cas, on parle de taux de fiabilité sur l’environnement de production, il s’agit du pourcentage de temps pendant lequel le service est en conditions opérationnelles.

Pour le petit paragraphe mathématique, on va partir sur le nombre de secondes dans une année. Et nous définissons avec les clients la durée qu’il est acceptable de “perdre”. À 100%, nous considérons que nous ne voulons pas une seule seconde d’indisponibilité. À 99% nous serons indisponible 7,2 heures par mois.

La logique est simple, maintenir un service à 100% demande des efforts considérables, je pense même que cela est impossible pour la plupart des entreprises. Alors que maintenir un service pour 99% du temps est relativement simple. Quoi qu’il puisse arriver, nous disposons de 7 heures et 15 secondes par mois pour réparer la production.

Google va encore plus loin dans cette approche et parle d’un crédit d’erreur qu’il faut dépenser. Si l’équipe n’a pas eu assez de panne c’est qu’elle ne prend pas assez de risques.

Sans aller jusqu’à faire un crédit pour casser la production, il est important de rester réaliste. J’imagine que votre client voudra avoir 100% de temps de production disponible mais l’effort technique pour atteindre cette objectif est immense.

Dans l’approche SRE on distingue d’autres notions sur les niveaux de services, si le sujet vous intéresse, il s’agit des notions de SLA, SLO et SLI. Je ne détaillerai pas ces notions ici, les différences sont assez subtiles. Par contre, j’aimerais préciser que j’ai donné ici des niveaux de service entier, on peut avoir des décimales tel que 99.9% voire 99.9999%.

Augmenter les fréquences des déploiements

J’ai souvent observé chez mes clients une réticence à la mise en production. Le plus souvent cette peur est liée à des traumatismes de mise en production précédentes échouant et entraînant plusieurs heures de casse tête pour les équipes de développement et d’administration.

Dans la plupart des cas, cette peur est l’occasion d’ajouter des vérifications et des procédures plus strictes pour chaque livraison. De cette manière, les mises en production s’espacent dans le temps et chaque livraison comporte de plus en plus de fonctionnalités.

Le piège se situe justement au niveau de la taille des livraisons : plus de fonctionnalités à déployer, plus de problèmes potentiels lors de la livraison. Et lorsque l’on rencontre de nouveaux problèmes, on implémente de nouveaux process et de nouvelles vérifications et ainsi de suite.

Dans une approche SRE nous allons découper les évolutions pour toujours avoir de petits incréments sur le produit en production, moins de nouvelles fonctionnalités pour un périmètre mieux maîtrisé. On se reposera ici sur la notion d’industrialisation que je décris dans mon précédent article.

Grâce à l’industrialisation, mettre en production peut devenir simple et rapide. On en profite donc pour le faire plus souvent avec des améliorations plus petites. Nous savons que notre version actuelle (appelée N) fonctionne correctement. Nous pouvons donc déployer notre version suivante (appelée N+1), voir si tout fonctionne, et re-déployer la version N si ça ne fonctionne pas comme on le souhaite.

Nous avons parfois même un modèle inverse où une version N+1 ne fonctionne pas et lorsque l’on consulte les développeurs de l’application pour en discuter, la bonne solution qui émerge est de déployer tout de suite la version N+2.

Augmenter le nombre et la fréquence des mises à jour devient dès lors un gage de stabilité. Mais il faut garder à l’esprit que ceci ne serait pas possible sans la marge de manœuvre négociée en amont.

Reparlons aussi brièvement de l’aspect communication: que l’on veuille revenir en arrière ou déployer une nouvelle version, l’opération se fera conjointement entre les équipes de développement et les équipes de production.

On commence à voir les bénéfices du profil SRE.

Automatisation

Un aspect des plus importants est l’automatisation. La plupart des équipes SRE cultivent une vision utopiste de leur plateforme. Une vision dans laquelle ils n’auraient plus de travail et pourraient rentrer chez eux alors que la production fonctionne parfaitement.

Pour atteindre ce but, les équipes SRE ont recours à l’automatisation. Cela veut simplement dire qu’elles vont écrire des programmes pour travailler à leur place. Cela parait simple dit comme cela.

L’inconvénient majeur de l’automatisation, c’est qu’écrire du code implique immédiatement deux choses:

La création de bugs, de comportements inattendus.
La maintenance de ces programmes et le fait de les faire évoluer avec l’entreprise.

Il faut donc être prudents sur cette partie et bien réfléchir avant de se lancer dans un chantier d’automatisation. Cela peut parfois créer plus de problèmes qu’en résoudre.

D’un autre côté les avantages sont nombreux, le gain de temps à long terme est indéniable et on gagne aussi en fiabilité sur les tâches automatisées. Les différentes actions sont aussi plus rapides car on n’hésite plus avant de lancer un script : cela coûte du temps machine, peu cher contrairement au temps humain.

L’automatisation apporte aussi une plateforme neutre, indépendante des machines sur lesquelles les développeurs travaillent. On peut ainsi être sûr et certain que le programme fonctionne correctement quelque soit la machine qui l’exécute. Et si on pousse ce raisonnement plus loin, on fera en sorte de créer nos environnements de tests automatisés au plus proche de ce que sera l’environnement de production final. On évite ainsi au maximum les erreurs qui surviennent lorsque l’ont change des éléments entre l’environnement de développement et l’environnement de production.

Les indicateurs

La plupart des développeurs travaillent sur leur ordinateur personnel dans un environnement maîtrisé. Dès lors que l’on change d’environnement (que ce soit un environnement de qualification ou de production), nous ne sommes plus maître de nos machines. Beaucoup d’entreprises aujourd’hui ont recours à des services cloud tel que AWS (Amazon Web Services) ou GCE (Google Cloud Engine).

Dans ces environnements, plusieurs paramètres peuvent influer sur les machines et impacter plus ou moins directement la production.

Énormément de choses peuvent mal tourner et afin de garantir que l’application reste en ligne, il faut utiliser des sondes qui vont récolter des métriques. On peut imaginer la sonde comme étant le thermomètre et la température comme la métrique.

Tout comme pour l’automatisation, il faut rester vigilant et ne pas se laisser entraîner par une campagne de récolte de métriques qui pourrait être inutile.

Pour qu’une sonde soit utile, il faut être en mesure de la comprendre et de mener des actions face à la mesure. Ainsi, si votre mesure concerne la moyenne des tailles de chaussures dans votre équipe et que votre activité concerne la production de pot de yaourt, vous pourrez comprendre la mesure mais elle ne sera pas pertinente pour votre prise de décisions. Par contre, mesurer le nombre d’utilisateurs par minutes sur votre site en production peut vous permettre de mener les actions qui permettront de tenir la charge.

Il faut donc rester le plus pragmatique possible et toujours se poser ces deux questions pour chacune des métriques mise en place:

Que signifie notre mesure ?
Quelles actions pouvons nous mettre en place lorsque la mesure varie ?

Il faut aussi garder à l’esprit que nous pouvons mettre toute sorte de mesure en place, ce n’est pas un domaine uniquement technique. Un autre exemple de mesure qui a pu m’être utile par le passé est le nombre de déploiement par semaine : lorsque l’indicateur à commencé à baisser, nous avons identifié une difficulté croissante dans la création des nouvelles fonctionnalités et nous avons donc pu acter qu’il nous fallait refaire un travail de fond sur notre base de code pour améliorer la situation.

Vos métriques peuvent être soit de nature organisationnelle soit porter sur le développement des nouvelles fonctionnalités, sur le nombre de tickets ouverts ou simplement sur la production qui tourne actuellement.

La mise en place de ces métriques permet de mener des actions face à elles. Nous pouvons donc automatiser certaines réponses.

L’exemple le plus courant est celui de l’autoscaling. Scaling en anglais signifie « mettre à l’échelle ». Ici il s’agit de mesurer la charge sur les machines de productions afin que si l’on dépasse les seuils définis en amont, on puisse démarrer automatiquement de nouvelles machines pour tenir la charge. C’est ce qu’il se passe sur beaucoup de site de commerce les jours de fortes affluences tel que le black friday ou les soldes.

Finissons ce sujet avec un dernier point d’attention. Imaginons que vous avez à mesurer la satisfaction de vos équipes via un formulaire que chaque membre doit remplir à la fin de la semaine. Au bout de 3 semaines, votre indicateur à légèrement baissé et vous décidez d’offrir des croissants pour toute l’équipe. Deux semaines plus tard, le niveau baisse à nouveau et vous achetez de nouveau des croissants. Il est fort probable que suite à cela, les formulaires soient toujours remplis négativement : vos équipes ont trouvé un moyen d’obtenir des croissants et vous ne savez plus du tout où en est le niveau de satisfaction.

Bien qu’amusante cette situation reste fréquente, il faut alors rester vigilant face à nos propres méthodes. Il faut garder à l’esprit que l’on peut toujours s’améliorer. Faites l’effort de garder vos mécanismes d’amélioration continue.

Conclusion : À quoi ressemble donc une entreprise avec du SRE

Je ne vais pas mentir, intégrer tous ces aspects dans la vie de votre entreprise n’est pas chose aisée. Mais rêvons un peu et imaginons que c’est le cas, à quoi ressemble votre quotidien désormais ?

Les développeurs, les profils SRE et les administrateurs travaillent main dans la main. Ça ne veut pas dire qu’ils sont toujours d’accord mais ils discutent autour de leurs différences et contraintes et trouvent de meilleures solutions.

La créativité de vos équipes augmente, de nouvelles idées émergent et peuvent être testées car les développeurs n’ont plus peur de demander plus de ressources sur les différents environnements de tests et même de productions. Les administrateurs quant à eux, osent demander des ajustements particuliers aux développeurs afin d’avoir une architecture plus stable et pérenne.

Mais le point le plus important, c’est l’accélération du cycle de valeur de votre entreprise. Le passage de l’idée à la mise en production est plus fiable et plus rapide. On passe de l’idée à la conception puis la réalisation, les tests, la validation et la mise en production en un temps record et en respectant chaque rôle dans la chaîne.

Bien que tout ne soit jamais parfait, le cadre de travail obtenu de la sorte est plus agréable à vivre et pourrait même avoir des effet bénéfique sur les aspects recrutements.

Prochainement

Je prévois d’écrire un article sur les architectures immutables ainsi qu’un article sur la transition d’une équipe « classique » vers un modèle plus proche d’un SRE.

Cependant, l’écriture me prenant beaucoup de temps, je ne pourrais m’occuper que d’un article à la fois, n’hésitez pas à me dire ce que vous en pensez dans les commentaires, par mail, sur twitter ou linkedin :)

Dev'Obs Light #1 : Les déploiements

2018-08-01T11:16:32+00:00

Aujourd’hui dans Dev’Obs on parle déploiement, bonne écoute.

C’est l’été, beaucoup de collaborateurs sont en vacance, vous êtes peut-être vous-même en vacance. De notre côté on en profite pour expérimenter des formats plus court et plus léger.

Production deployments, DevOps, SRE and other strange subjects

2018-05-15T11:16:32+00:00

I am often asked what I do in life and I’m not able to give a clear answer.

Not because my work is fuzzy, but because it’s based on concepts that most people do not understand. The least technical way I explain what I’m working on is:

“I’m in charge of putting into production”.

Certainly, but what is a “production”? It is not a complicated notion but it is a notion that is based on many other concepts that make its explanation quite difficult.

Moreover, we do not really answer the question, to know what “putting into production” really includes.

I also talked a lot with developers I meet and I realized that few of them are interested in my area of expertise. It’s just not their job.

To go further, I take care of the production in the broad sense. And this includes the following areas:

Architecture of the solution
Transition from development to production (deployment pipeline)
Maintain Operational Conditions
Security
Disaster Recovery

And each of these areas deserves further development to explain the ins and outs. Each of these notions is based on other, more technical ones.

We will try to skim over each of these points in this article.

Architecture

To make it accessible, I will start from the presentation of a common case: an application containing a backend and a frontend. In our example, the application will be used to find restaurants.

To do this, the company will have to develop several elements:

A database to store the addresses and specificities of each restaurant
A backend, the heart of the application that will make research, register new restaurant, etc …
A frontend, the visible part for the end user, often in the web browser or a mobile application.

Architecture is the part of the work that will allow us to draw the following diagram:

We see that for this small application, we already need 7 machines, configure network layers and provide redundancy services.

This remains a very simple example, it is quite common to be faced with twenty services spread over 30 to 40 machines.

Of course, all companies do not implement all this complexity from the first line of code. You have to make trade-offs and know what is important for the service to be properly delivered to the end user.

Just by looking at this diagram, I have already a dozen ideas to complete the architecture. So this is the first part of my job, think about the system as a whole to see the strengths and weaknesses of the solution.

Industrialization

Once we have our architectural scheme, we have 30 machines running 20 different services… how do we maintain all this? How do we evolve?

From a technical point of view, it would be enough to connect to the machines to configure them correctly, one by one. This is a way of doing that I often meet in companies and unfortunately, this is not the right solution.

Connecting to the machines to configure them by hand gives configurations in snowflakes. Because it’s done by hand, even if we want all our machines to be configured in a similar way, there are always small differences between them. All machines are the same, but not quite #SameButDifferent

Consequences of this are disastrous: put in production is difficult as hell under these conditions. Each machine must have a different treatment, putting in production can take days and we are never sure to get something out of it.

Industrialization is therefore the second part of my work, and I would say the most important. This is a fairly long process, which requires investment in both duration and means. The added value is not immediate so it is not always the priority of companies.

By industrializing, we automate the creation of images. Because, connecting to machines to update them involves risks, so we create images instead.

An image in this context has nothing to do with the images found on the internet in png or jpeg formats. This is an “instant picture” of a machine already configured and ready to use. Thus, when we deploy a machine with our image, it is ready to deliver the service that is expected of it without the need for manual operation.

Then, we automate the replacement of old images with new ones, to ensure a smooth transition in production, with the least possible downtimes.

And this will especially allow to press the button “go for production” with peace. This is thanks to the tests of each of our images. This is where our production pipeline is important.

The pipeline is the concept of a production line, a bit like car assembly lines. Our chain starts with the work of developers who will propose new features. Then those features will be tested and approved by other developers. Then it will go through the step of creating our image, which will serve to create a qualification environment. This environment will allow customers to validate the feature before validating the release.

The main idea behind industrialization is therefore to create a production line that allows the company to:

Deliver customers faster
Improve reliability of deliveries
Banalize delivery (more frequent, faster)
Be able to validate or invalidate new features more quickly

Even if, at first glance, the establishment of this software factory may seem complicated, the added value is undeniable. I have never seen a company regretting having invested in the industrialization of their platform.

In many cases, the company is not aware that it could invest in industrialization.

Maintain production in operational conditions

Putting into production is fine but life does not stop there. Despite several years of dealing with different software platforms, I am always amazed by the amount of things that can go wrong, especially in production environment.

But once the application is in production, we must maintain it in working order. A stopped production is a loss for the company. The application can only bring money to the company if it is available to its end users, its customers. We must therefore distinguish several possible states:

Optimal operational conditions, customers have no trouble connecting.
The deteriorated conditions, there are some delays, some disconnections. This state is very frustrating for the user.
Shutdown, production is no longer accessible, no more customers can connect.

So we talk about maintaining in operational conditions. It’s a pretty way of putting it, but incorrect in my opinion. In reality, we can not really guarantee to stay in optimal conditions all the time.

However, what we can do is recover an optimal state when an alert is raised. When a machine stops, if the architecture is solid, the service will remain available but in degraded mode.

Degraded mode is better than no longer having service. The goal is to find a fully operational state to ensure a good experience for users.

The good news is that by industrializing the start of production, creating new machines to replace broken ones is easy and fast. However you have to get the information that something is wrong in order to take actions.

Here is the third aspect of my work, keeping the best possible conditions in production, also called monitoring and supervision. It’s about setting up tools to receive alerts if something goes wrong on our system.

But, we can go further than just receive an alert and wait for a technician to do something, we can automate the repair: We dismiss the machine “sick” (we keep it to understand the error), then we starts a new machine that works and finally we start all healthchecks

Healthchecks are the equivalent of unit tests under development. These are small programs that can ensure that the service is in good health.

It is quite difficult to automate this part but if the industrialization went well, monotiring and supervision will be fine too.

Security

Our product is deployed in an industrial way and it self-repairs in case of problems. Everything is awesome !

But there are things I did not talk about. It is difficult to make a separate section to talk about security because it is not a project that can be added, there is no miracle recipe to secure what already exists.

We must have security in mind in all the previous steps. We must always have an eye on this aspect. From development to production, every effort must be made to ensure that important data are protected, encrypted and isolated.

Let’s start with encryption. It is about transforming a message so that nobody can read it and your application will then be the only element to be able to decipher it. Thus, if an attacker manages to intercept data, he will not have the ability to read them and therefore have no way to exploit them. If this topic interests you, I recommend this article: HTTPS with carrier pigeons

Then, what is important and that few companies put in place is the hiring procedure and the departure procedure. When a new colleague arrives, how are we given access to all the tools? How do you do when you leave the company?

Many security flaws arise from this part. Few companies are able to list precisely who has access to the different tools they use and some people are able to act on their productive environments without the company having explicitly agreed.

Finally we have to keep the tools that we use frequently. One of the benefits of industrialization of releases is that we can apply updates more often and be less vulnerable.

However, the problem of computer security is that it remains very illusory. You can never really be sure of your own safety. We can only reduce the risks.

Security is part of my job, through all the services I offer.

Survive cataclysmic events

I told you about what we can put in place to have a production that holds up. And that’s how we get to the last aspect of my work, disaster recovery, or the art of surviving the apocalypse.

Well, OK, in the event of a meteorite fall that would end humanity, your production may be not a priority. But when an excavator pulls the fiber optics out of your datacenter, the production will just not be accessible.

Concretely, you can overcome this kind of event easily if you have done correctly your industrialization. It will just take time to restore normal operating conditions.

The goal here is to stay proactive, predict the worst cases imaginable and become aware of the probability of this kind of event. Losing a datacenter does not happen every day but unfortunately it is frequent enough that I have to endure about 2 per year. I do not count the ones I hear about but do not affect the services I work on.

There is not much to do when the infrastructure itself breaks under your feet, as solid as your installation is, you will be a victim.

But instead of giving up and praying, we can prepare for it:

Imagine potential disasters
Assess the risks of each
Assess the potential impact on your production
Prepare for impact

These painful events are theoretically rare but believe me, it happens, and more often than we think. Preparing for it is a bit like taking first aid training in the background, we hope we never have to use it but when we need it we are happy to have made the effort to take these courses .

Conclusion

I recently realized that this whole universe of skills was completely foreign to the people I meet. They continue to ask me, even after several years, “But concretely, what is your job? “.

It was this recurring question that made me decide to write this article. I think I’ve done a quick tour of my work here, clarified some of the things I’m working on.

As I said at the beginning, explaining what I’m doing is a small challenge in itself.

Meeting someone, not knowing their affinities with the computer world and explaining my work is a recurring problem.

Every point that I mentioned in this article could be the subject of other articles, without counting the notions that I did not address such as the DevOps culture, methodologies that we put in place with the development teams or networks related issues.

I hope that following this article, you will have a better vision of what can be a website or a mobile application in the background.

I will write other articles in this style, to clarify the concepts that we work on every day.

See you soon,

Déploiements en production, SRE, DevOps et autres sujets obscurs

2018-05-15T11:16:32+00:00

On me demande souvent ce que je fais dans la vie et je n’arrive pas à répondre.

Non pas parce que mon travail est flou, mais parce qu’il repose sur des concepts que la plupart des gens ne maîtrisent pas.

La manière la moins technique que j’ai d’expliquer ce sur quoi je travaille est la suivante:

« je m’occupe de la mise en production ».

Certes, mais c’est quoi une « production » ? Ce n’est pas une notion compliquée mais c’est une notion qui repose sur pleins d’autres concepts qui rendent son explication assez ardue.

De plus, on ne répond pas vraiment à la question, de savoir ce que la mise en production inclut comme travail.

J’en ai aussi beaucoup parlé aux développeurs que je rencontre et je me suis aperçu que peu d’entre eux s’intéressent à mon domaine d’expertise. Ce n’est simplement pas leur métier.

Pour aller plus loin, je m’occupe de la production au sens large. Et cela inclut les domaines suivants:

L’architecture de la solution
Le passage en production (pipeline de développement, ou chaine de production)
Le maintien en conditions opérationnel (MCO)
La sécurité
Faire face à l’imprévu, évaluer les risques (connu sous le nom «Disaster Recovery»)

Et chacun de ces domaines mériterait un développement plus approfondi pour en expliquer les tenants et aboutissants. Chacune de ses notions reposant elle-même sur d’autres notions plus techniques.

On va essayer de survoler chacun de ces points dans cet article.

L’architecture

Pour que cela reste accessible, je vais partir de la présentation d’un cas courant : une application contenant un backend et un frontend. Dans notre exemple, l’application servira à trouver des restaurants.

Pour ce faire, l’entreprise devra développer plusieurs éléments:

Une base de données pour y stocker les adresses et les spécificités de chaque restaurants
Un backend, le cœur de l’application qui permettra de faire des recherches, d’enregistrer de nouveaux restaurants, etc…
Un frontend, la partie visible pour l’utilisateur final, souvent dans le navigateur web ou une application mobile.

L’architecture, c’est la partie du travail nous permettant de dessiner le schéma suivant :

Comme on peut le voir sur le schéma ci-dessus, nous avons déjà besoin de 7 machines, puis de configurer les couches réseaux et de prévoir la redondance des services.

Cela reste un exemple très simple, il est assez fréquent de se retrouver face à une vingtaine de services répartis sur 30 à 40 machines.

Bien évidemment, toutes les entreprises ne mettent pas en place toute cette complexité dès la première ligne de code. Il faut faire des arbitrages et savoir ce qui est important pour que le service soit correctement rendu à l’utilisateur final.

Rien qu’en regardant ce schéma, j’ai d’ores et déjà une douzaine d’idées pour compléter l’architecture. Voilà donc la première partie de mon travail, à savoir réfléchir au système dans sa globalité pour voir les forces et les faiblesses de la solution. L’industrialisation (Le passage en production)

Sauf que voilà, une fois qu’on a notre schéma d’architecture, qu’on a 30 machines qui font tourner 20 services différents… Comment est-ce qu’on maintient tout ça ? Comment le fait-on évoluer ?

D’un point de vue technique, il suffirait de se connecter aux machines pour les configurer correctement, une par une. C’est une manière de faire que je croise très souvent dans les entreprises et malheureusement, ce n’est pas la bonne solution.

Se connecter aux machines pour les configurer à la main donne des configurations en flocons de neige (snowflakes en anglais). Puisque cela est fait à la main, même si on désire que toutes nos machines soient configurées de manière similaire, il y a toujours de petites différences entre chacune. Toutes les machines sont les mêmes, mais pas tout à fait #SameButDifferent

Les conséquences de cette pratique sont désastreuses : mettre en production est un enfer dans ces conditions. Chaque machine devant avoir un traitement différent, la mise en production peut donc prendre des jours et on est jamais certain du résultat.

L’industrialisation est donc la seconde partie de mon travail, et je dirais la plus importante. Il s’agit d’un processus finalement assez long, qui demande un investissement aussi bien en durée qu’en moyen. La plus-value n’étant pas immédiate ce n’est donc malheureusement pas toujours la priorité des entreprises.

En industrialisant, on automatise la création des images. Parce que oui, se connecter aux machines pour les mettre à jour comportent des risques, donc on crée plutôt des images.

Une image dans ce contexte n’a rien à voir avec les images que l’on trouve sur internet aux formats png ou jpeg. Il s’agit d’une « photo instantanée » d’une machine déjà configurée et prête à être employée. Ainsi, lorsque l’on déploie une machine grâce à notre image, elle est prête à délivrer le service que l’on attend d’elle sans qu’il y ai besoin d’opération manuelle à effectuer.

Ensuite, on automatise le remplacement des anciennes images par de nouvelles, afin d’assurer un passage en production en douceur, tout en réduisant le risque d’éventuelles interruptions.

Et cela va surtout permettre d’appuyer sur le bouton « mise en prod » l’esprit tranquille. Ceci grâce aux tests de chacunes de nos images. C’est ici que notre pipeline de production est important.

Le pipeline est la notion de chaîne de production, un peu à l’image des chaînes d’assemblage des automobiles. Notre chaîne commence avec le travail des développeurs qui proposeront de nouvelles fonctionnalités. Ensuite, cette fonctionnalité sera testée et approuvée par d’autres développeurs. Puis elle passera par l’étape de création de notre image, qui servira à créer un environnement de qualification. Cet environnement permettra aux clients de valider la fonctionnalité avant de valider la mise en production.

L’idée principale derrière l’industrialisation est donc de créer une chaîne de production qui permet à l’entreprise de:

Livrer plus rapidement ses clients
Fiabiliser les livraisons
Banaliser la livraison (plus fréquent, plus rapide)
Pouvoir valider ou invalider plus rapidement les nouvelles fonctionnalités

Même si, à première vue, la mise en place de cette usine logicielle peut paraître compliquée, la plus-value est indéniable. Je n’ai encore jamais vu d’entreprise regrettant d’avoir investi sur l’industrialisation de leur plate-forme.

À l’inverse, dans de nombreux cas, j’ai pu voir que l’entreprise n’est pas au courant qu’elle pourrait investir dans un projet d’industrialisation de ses mises en productions.

MCO: Maintien en conditions opérationnelles

Mettre en production c’est bien beau mais la vie ne s’arrête pas là. Malgré plusieurs années à m’occuper de différentes plateformes logiciel, je suis toujours stupéfait par la quantité de choses pouvant mal tourner, même en production.

Or une fois l’application en production, il faut maintenir celle-ci en état de marche. Une production à l’arrêt est une perte sèche pour l’entreprise. L’application ne peut rapporter de l’argent à l’entreprise que si elle est disponible pour ses utilisateurs finaux, ses clients. Il faut donc distinguer plusieurs états possibles:

Les conditions opérationnelles, optimales, les clients n’ont aucune difficultée à se connecter.
Les conditions dégradées, on constate certaines lenteurs, quelques déconnexions. Cet état est très frustrant pour l’utilisateur.
L’arrêt, la production n’est plus accessible, plus aucun client ne peut se connecter.

On parle donc de Maintien en Conditions Opérationnelles (MCO). C’est un joli nom, mais incorrect selon moi. En réalité, on ne peut pas vraiment garantir de rester dans les conditions optimales tout le temps.

Cependant, ce qu’on peut faire c’est récupérer un état optimal dès lors qu’une alerte est levée. Lorsqu’une machine s’arrête, si l’architecture est solide, le service restera disponible mais en mode dégradé.

Le mode dégradé c’est toujours mieux que de ne plus avoir de service du tout. Le but, c’est de retrouver un état complètement opérationnel afin d’assurer une bonne expérience pour les utilisateurs.

La bonne nouvelle c’est qu’en industrialisant la mise en production, remettre de nouvelles machines pour remplacer celles qui sont cassées c’est facile et rapide. Cependant il faut avoir l’information que quelque chose va mal pour lancer ces actions.

Voici donc le 3éme aspect de mon travail, garder les meilleures conditions possibles en production, aussi appelé monitoring et supervision. Il s’agit de mettre en place des outils pour recevoir les alertes si quelque chose tourne mal sur notre système.

Mais en y réfléchissant, on peut aller plus loin que juste recevoir une alerte et attendre qu’un technicien intervienne, on peut automatiser la réparation:

On écarte la machine «malade» (on la garde pour comprendre l’erreur)
On redémarre une nouvelle machine neuve qui fonctionne
On relance les vérifications (healthchecks en anglais)

Les vérifications sont l’équivalent des tests unitaires en développement. Ce sont de petits programmes qui peuvent nous assurer que le service est bel et bien en place et en bonne santé.

C’est assez difficile d’automatiser cette partie mais si l’industrialisation s’est bien passée, il n’y a pas de raison pour que la partie MCO ne se passe pas bien.

Sécurité

Quand on en arrive là c’est que notre produit se déploie de manière industrielle et qu’il s’auto-répare en cas de problème.

Mais il reste des aspects dont je n’ai pas parlé. C’est délicat de faire une section à part pour parler de la sécurité car il ne s’agit pas d’un projet que l’on peut ajouter, il n’y a pas de recette miracle pour sécuriser ce qui existe déjà.

La sécurité, on doit l’avoir à l’esprit dans toutes les étapes précédentes. On doit toujours avoir un œil sur cet aspect-là. Du développement à la production, tout doit être fait pour que les données importantes soient protégées, chiffrées et imperméabilisées.

Commençons par le chiffrement. Il s’agit de transformer un message afin que personne ne puisse le lire et votre application sera alors le seul élément à pouvoir le déchiffrer. Ainsi, si un attaquant arrive à intercepter des données, il n’aura pas la capacité de les lire et donc aucun moyens de les exploiter. Si ce sujet vous intéresse, je vous conseille cet article (en anglais) : HTTPS with carrier pigeons

Ensuite, ce qui est important et que peu d’entreprises mettent en place, c’est la procédure d’embauche et la procédure de départ. Lorsqu’un nouveau collègue arrive, comment lui donne-t-on accès à l’ensemble des outils ? Comment fait-on lorsqu’il quitte l’entreprise ?

De nombreuses failles de sécurités découlent de cette partie. Peu d’entreprises sont capables de lister précisément qui a accès aux différents outils qu’elles utilisent et certaines personnes sont donc capable d’agir sur leur environnements productifs sans que l’entreprise n’ait explicitement donnée son accord.

Finalement nous devons maintenir à jours fréquemment les outils que l’on utilise. L’un des avantage de l’industrialisation des mises en production nous permet d’appliquer les mises à jour plus souvent et d’être moins vulnérable.

Cependant le problème de la sécurité en informatique, c’est qu’elle reste très illusoire. On ne pourra jamais être vraiment sûr de sa propre sécurité. On peut seulement diminuer les risques.

La sécurité fait partie de mon travail, au travers de tous les services que je propose.

Survivre aux cataclysmes

Jusque-là, je vous ai parlé de ce qu’on peut mettre en place pour avoir une production qui tient la route. Et c’est ainsi qu’on en arrive au dernier aspect de mon travail, disaster recovery, ou l’art de survivre à l’apocalypse.

Bon, OK, en cas de chute de météorite qui mettrait fin à l’humanité, votre production sera peut-être le cadet de vos soucis. Mais quand une pelleteuse arrache les fibres optiques de votre datacenter, la production ne sera juste plus accessible.

Concrètement, surmonter ce genre d’évènement n’est pas un problème si l’on a correctement industrialisé les mises en production. Cela nous prendra juste du temps pour rétablir les conditions normales de fonctionnement.

Le but ici c’est de rester proactif, prévoir les pires cas imaginables et prendre conscience de la probabilité de ce genre d’événement. Perdre un datacenter, ça n’arrive pas tous les jours mais c’est malheureusement suffisamment fréquent pour que j’en subisse environ 2 par an. Je ne compte pas ceux dont j’entends parler mais qui n’affecte pas les services sur lesquels je travaille.

Il n’y a pas grand chose à faire quand les infrastructures elle-même cassent sous vos pieds, aussi solide que soit votre installation, vous en serez victime.

Mais plutôt que de baisser les bras et prier pour que cela ne se produise pas ou se produise peu, nous pouvons nous y préparer :

Imaginer les catastrophes potentielles
Évaluer le risques de chacune
Évaluer l’impact potentiel sur votre production
Se préparer à l’impact

Ces événements douloureux sont théoriquement rares mais croyez-moi, ça arrive, et plus souvent qu’on ne le pense. S’y préparer c’est un peu comme suivre une formation aux premiers secours dans le fond, on espère ne jamais avoir à s’en servir mais quand on en a besoin on est heureux d’avoir fait l’effort de suivre ces cours.

Conclusion

Je me suis récemment rendu compte que tout cet univers de compétences était complètement étranger aux personnes que je rencontre. Elles continuent de me demander, même après plusieurs années, « Mais concrètement, c’est quoi ton travail ? ».

C’est cette question récurrente qui m’a décidé à écrire cet article. Je pense avoir fait un rapide tour de mon travail ici, éclairci quelques notions sur lesquelles je travaille.

Comme je le disais au début, expliquer ce que je fais est un petit challenge en soi.

Rencontrer quelqu’un, ne pas connaître ses affinités avec le monde informatique et lui expliquer mon travail est une problématique récurrente.

Chaque point que j’ai évoqué dans cet article pourrait être l’objet d’autres articles, sans compter les notions que je n’ai pas abordés tel que la culture DevOps, les méthodologies que nous mettons en place avec les équipes de développement ou encore les problématiques liées aux réseaux.

J’espère que suite à cet article, vous aurez une meilleure vision de ce que peut être un site internet ou une application mobile.

Je vais écrire d’autres articles dans ce style, pour éclaircir les notions sur les lesquelles nous travaillons tous les jours.

À bientôt,

Comment moderniser l’organisation de votre équipe de développement

2017-07-04T11:16:32+00:00

On entend souvent parler de « tests automatisés », de « pair programing » ou encore de « mises en production automatisés ».

C’est toujours si simple chez les autres.

Mais concrètement, que pouvons nous en tirer pour notre équipe chez nous ? Comment mettre en place une « CI » ? Et puis ça veut dire quoi d’abord une « CI » ?

Sérieusement, c'est quoi un DevOps ?

2017-07-04T11:16:32+00:00

Les « dev » et les « ops » se livrent une guerre depuis que le monde est monde ! Le clan « dev » n’arrive plus à comprendre les rouages de ce terrible conflit. Il est temps de rétablir la vérité vrai

Modernize your team !

2017-03-14T18:42:32+00:00

We often hear about great organization with multiple teams, where everyone can talk to everyone else and every piece of information is accessible. We can hear about pair programing, code review, CI or CD.

Yeah, all of this seems so great, but this is happening in other companies. What about my team ? How can I use all of this for our project ? And men, what the hell is a CI ?

I was employed in a startup two years ago, where each task has to be delivered immediately, and every thing was urgent. How can you put all those great tools without any time allocated to it ?

It won’t be easy, it won’t be cheap, but we can work this out, find solutions, and transform ANY team to achive more.

For that, I’ll take a little analogy, please think about your team as a role playing game character. This character will increase its power through different level, and we starting with a level 0, before our game can begin.

Level 0 : Create your team

This first level is more like creating your character, you know, before you start your Donjon & Dragon campaign, you have to create your character and assign some skill points. This is the same with your team.

Most team I met in my life weren’t really ones: this is not just several lads hanging arround and sharing a manager. Team defines themselve by interractions, and it implies to create connections between people.

Those connections will create unexpected behaviour, team member won’t work for a manager, but they will for the sake of the team.

To achieve that, treat your team like a person, give it a name to refer to it.

Then, you can give it responsabilities. Your team needs to embrace the project, it needs to know exactly the goal behind each actions.

With this new person, you won’t assign a task to a specific person, give it to the whole team and let all members decide who will do the actual job. If someone gives you a task, talk with the entire team before doing anything.

When you put that together, your people will start to work as a team, together, to solve global problems that makes sense. But it’s not enough, you need a second person: a neutral judge

Because several peoples working together will generate conflict, you need someone or something to help them decide what to do. If you give this role to a human, that’ll just be another manager… let’s try something different: Give this to automation tools.

Examples:

Code quality : Use eslint and ask the team to define rules
Code review : Use Pull request and ask the team to chose a way to review each one of them
Documentation : Decide to write a README.md and let the team complete it

Once you put all of this in place, you have a team, a strong base to build something great !

Level 1 : Train your neutral judge

But hey ! your neutral judge is not a person… it’s not a single thing either, it’s just a bunch of tools !!

Yes, but we can work this out, by giving it a personality. You can call it Jarvis like Iron Man, Skynet like Terminators or HAL if you want. In the reste of this article, we will call it Timmy.

Timmy won’t be define as a single thing, your team know that because it’s your team that took Timmy in place.

And Timmy is not really smart, but he is rigorous and impartial. So let’s ask him to do more stuff. Try to make him install your product for example.

You’ll see, it’s not the simplest task in the world. And when you successfully see your product run by Timmy, you know that every new team member will succeed too, because, hopefully, this new team member will be smarter that Timmy.

You can, afterwards, define testing on your product, cause you’ll have a standard plateform and launch procedure to launch tests.

The goal behind all of this might be difficult to see: by default, humans evolved with an individual mindset. People in your team will try to get credit for themselves, they’ll try to implement their idea even if they were proven wrong.

By giving all of the validation stuff to Timmy, team members won’t be able to tell things like « it worked on my laptop », they’ll colaborate to have Timmy’s approbations for the work. All team members are equal with accptance criteria.

Little Break

Just take a moment to think about first two levels. If you follow this, you’ll have a real team, and a real process to change an idea into code and then commit that code into the product.

Normally, following this two levels will create another unexpected behaviour, but a good one : A culture !

Your team will developped their own private jokes, history and legend. They also have a mascott with Timmy.

Don’t try to implement all of it in one day, it won’t work. Let the team, as a person, integrate the whole thing. And most important, when adding a new rule or item to your team, get feedback, don’t force them.

You have now the foundations of the greatest team you ever had. You can pass to the level 2.

Level 2 : Team automation

Try now to focus on what’s important for your team. If you try to automate anything because it’ll save you time, it’s not the good approach.

Automation is the next level for you neutral judge. It’ll help your team to make less errors. Timmy is not the smartest of your team member, but it won’t make mistake, remember he is not human.

From now on, Timmy will tell you if your tests pass, or not. He will reject or approved new pull request. Timmy can update your documentation alone or send email to your customers, just ask him.

This level is quite hard, cause for everything you want to automate, you need a human of your team to take time on this automation. And sometimes, managers won’t agree to let you do that.

Automation will save time to your team only once it is in place. It will be difficult to sell non-feature thing to your executives.

If you reach this level with your team, you have a pretty good place to work. A team with its own culture, some neutral testing and building platforme. Clear README files to newcommers. Now is the time to make your team a success you can talk about to other company.

Level 3 : CI/CD : Continuous Whatever

The normal workflow of developement is the following

Step 1 : Idea
Step 2 : Transform your idea into code
Step 3 : Let Timmy tests that code, if it’s not working, back to step 2
Step 4 : Let Timmy integrate the code to the product (fallback to step 2)
Step 5 : Let Timmy deploy your code
Step 6 : Let Timmy get feedback from customers

And as you can see, Timmy will do most of the work, human team member can concentrate on important human things: Getting idea and find a way to code them.

You don’t need a Jenkins or Drone or any other specific tools to make your own automation, let your team decide from their needs, let them give life to Timmy

The more Timmy is developped, the less your team as to work to get from Idea to Customer feedback. The team itself will reduce the development time. And that’s the ultimate goal of every Continuous integration.

Conclusion

Managing a team is not an easy task, every one is different, every one has its own approach to problem solving. Getting every one to work on an idea is really hard.

That’s why it shouldn’t be a single person job, give this to your team and look at them taking more and more responsabilies as weeks goes by.

As your team is getting stronger, member will get closer and good thing will spontaneously shows up ! Trust your team ! They are good, they are working hard too !

Thank you.

Mastering GIT by reducing the pain

2016-11-09T18:42:32+00:00

Using GIT every day is quite normal for a developer. We work with GIT, we trust it to keep our files safe and we trust it to share them too. A long time ago, when I was on my first internship at Easter-eggs I wrote a small web service to automate a customer’s GIT workflow.

I learned a lot about GIT at that time. Not only the command line interface, but also some internals and structures. Since then, I love it, and I use it every time I deal with text files… well, I’m always dealing with text files, so I’m ALWAYS dealing with GIT.

But, even if I’m loving it, I have to say : GIT is also painful:

You have a long list of command to type to do what you want to do
Lots of repetition through a single day developing in a team
Through repetition, us, poor human beings, make mistakes
More command to revert those errors
More command to complete the task you wanted to de before you made those errors
More error due to more commands…

It’s difficult to make GIT act the way you want, you have to learn a lot for that. I saw a lot of programmer who actually adopted a simpler approach

cd ..
mv my-repo my-repo.bak
git clone <url-of-my-repo>

So let’s try to learn some ways to do better, some ways to master your repository and not going crazy about it.

Stash and Discard

First painpoints in your workflow will happen locally, on your machine. You’ll have to organize your commits before pushing them to the team. Let’s avoid some dangerous shortcut. Never commit everything in your directory, carefully select your changes and put a clean and clear commit message to help people understand your patch.

Once you got clear commits, and are ready to push, or rebase on remote branches, you’ll often find yourself in a situation were you have some more changes that you can’t send. It may be configurations, debug logging instruction, or even some code commented out during your work. This files and changes will prevent GIT from performing further operation including merges and rebases.

So, let’s use the most important script to me: git-stash. It’ll let you save your working tree in a separate commit, not in your current branch. You can then do whatever you want on a clean working tree without worying of all the little changes you might want to keep. Nobody will ever notice your stash.

You just have to apply your stash once you finish manipulating your repository and you’re good to go.

But wait, this isn’t magic and you’ll have to deal with possible conflict between your stashed changes and your local files. I often find myself in a situation were I got multiple stash on my repos, and I can’t remember what’s in it.

There is no solution right now to deal with this with a simple installation of GIT. You can find some addons to help you, but in my opinions, best ways to avoid possible issues is to apply simple rules to keep a sane repository:

Configuration files in .gitignore file. You don’t want to commit configuration variables (sometimes contains credentials)
If you add local files and can’t commit them even in .gitignore, put them in a ignored directory referenced in .gitignore
Force yourself to always work on a clear and updated repository. Rebase often on team’s work.
Communicate with your team ! Share your solutions, there’s pretty good chances your coworkers have the same issues !

Then, logically, when you want to commit and push your work, you quickly take habits with stash. You multiply commands on your terminal and end up with some aliases or meta-command to help you.

Repository, remotes and branches

Another complexity that often occurs is implied by remotes and branches. You don’t work alone, and you need to use your coworkers’ work. It’s easy to lose grip.

Switching repositories, remotes and branches is hard, don’t count on your memory, it sucks at remembering things correctly… humans…

The simplest solution is the same as everyone does with their code: conventions also known as Branching models. Except here, all companies have different ways to do that, and you often find in a single team several ways of doing things.

First solution : A single repository

Simpler solution is to remove complexity through a single repository. You avoid this particular issue and some team may like it.

The main advantage of this approach is your commits, they are bigger, but contains everything you need and you can add or remove thing by editing single commits.

I personally discourage this as it won’t scale with whatever your team do next.

If your company grows, chances are that your repos will grow too. You add teams on some other project and everything inside your repository. Rebasing always and always on a repos that admit so much changes will be harassing.

Second solution : Hooks

You can also forbid any human to do thing and automate your team workflow with git hooks. This will automate some task, like submitting a pull request or cleaning up the project. You can automate your tests with the commange git commit to ensure your commit has run your tests.

You can basically add anything you want to your workflow automatically with hooks.

Your team will perform good operations, but they won’t understand them. Worse, they won’t be able to detect when it goes wrong. Write your hooks in bash and there’s pretty good chances that some of your users will fail executing them.

So, git-hooks might be a good thing, but check the following before telling everyone to use it :

Everyone have to be able to execute your scripts
Everyone must understand what it does

Third solution, the hardest : Learning

By far, learning GIT is the better solution to all your problems. If your team understand how GIT works, there won’t be any trouble using it. You’ll eventually find people doing complex things in unexpeted way.

This might sounds obvious, but it isn’t. I’ve seen team where everyone know how to use GIT but no one ever used it the same way before. Team members were all so sure to understand what they were doing that nobody listen to other team member.

This is the best advice I could ever make here: Take the time teach every person in your team. It will take some weeks, or month to have ervyone on the same page, but it worth it !

Conclusion

So, yes, GIT is awesome and everyone is using it. But it’s also a complex tools, it will hurts your feelings. You can make mistake, you can loose time.

There won’t be any magic tool to do things you want right away. All we can do is a bunch of script and conventions that suits you and your team.

The way we’re using GIT tells us more about how we organise ourselve than the work we do. And the greatest tool you can imagine to be more productive with GIT as a team is learning.

Don’t hesitate to communicate on tools, tips or any conventions you saw on other teams: lots of developper are seeking help with GIT and every plugins could save their day.

Discovering GO

2015-06-18T09:46:42+00:00

Since I began to work a CloudWatt, I’ve been quite busy and I didn’t wrote a thing. Today, this will change, I have learned so much in 6 month, I HAVE to share !

CloudWatt is a public cloud provider. behind this words, it’s a instance of openstack delivering virtual private servers for its customers.

I’ve learned a lot and today I’ll talk about my journey with the GO programming language.

My first project in GO

There’s two main reason for me to learn more about GO. The first one is the fact that some people, friends and colleague talk about this language regularly. and the second one, some project I like are written in GO.

Project like wego of Goaccess are written in GO and save me everyday.

I decided to start my own project, and created friend-bots.

Through this simple exercice I can explore some of the language basic feature:

Basic syntax
Compilers
Source code linter
Packaging
Libraries
Community surrounding the language
… etc…

Result

Let’s take a tour with me.

I’ll start with a negative point, its basic syntax. It may be confusing at first and I find it less readable than Python. It’s not a big issue because we can write correctly and produce readable code anyway (I had to mention this).

But then, all the good parts. First, let me talk about the “default” command line client for GO. This command line is a wrapper, like GIT and it allow the users to launch several tools.

With this single entry point, the command go gives you :

The linter, it will format your code properly
The compiler to build a valid executable file
The packaging manager to download and manage external libraries
It run your tests !
This command also let you run your code (a build and run shortcut)

And I didn’t to learn or do some crazy stuff to have all of that working, the most difficult part was to set up the GOPATH environement variable and modify PATH.

Afterward, I can speak about libraries and packaging. GO can handle several versioning system like GIT, you just have to name your library and give a URL where your system can fetch the specified library :

import irc "github.com/fluffle/goirc/client"

You can note here, I’m importing a module called goirc and naming it irc.

But, I had to mention it too, there’s one issue with this. A few days ago, a library migrated from code.google.com to github.com. So travis could not built my project anymore as he couldn’t retrieve sources.

I made a pull request to fluffle and change the import line as below.

import irc "github.com/gentux/goirc/client"

This story is a bad point for me, we are using internet resources for internal code, and it might break anytime.

Conclusion

I could talk more about GO, but I really think you should give it a try if you want to learn more :)

This is a great tool for every small components you might need. You can build an executable file for every platform and deploy it very fast.

Bye, and happy hacking !

Soufflet.IO services

2014-12-15T15:46:42+00:00

It’s been 3 weeks since I acquired the Firefox OS Flame device. I finally have a working smartphone were I can read mails, calendar events, access a real browser… etc…

I am very proud to use only services I manage myself : no Google, no other companies services or piece of hardware, just me and my RaspberryPI (RPi for short).

My services are working for about a year now, my brother use it, my parents use it and I think it stable enough for me to speak a little about it.

Hardware

First of all, the hardware part.

What resources do I need ?
What about the bandwith ?
Backups ?

So, as I did not had any clue for these question, I used a simple RPi at home. I got fiber installed a few days after that and did not need to bother about bandwith anymore.

The main problem behind a RPi is resources. My first try to have a set of personal services was Owncloud, performances were very bad.

Then, I tried cozycloud but no more success with it.

I decided to install all services I wanted one by one:

Postfix / Dovecot for mails
Radicale for CalDav and CardDav
Apache moddav for remote storage
Vsftpd for FTP
OpenVPN

SSL Certificates

All those services run on one single RPi.

And I use them with the Desktop at home, my laptop at work and my phone anywhere else.

On first version I installed this year, I used some self-signed certificates. It’s perfectly fine to use those, but when I got my FirefoxOS device, those certifiacates were rejected.

The solution is named StartSSL : on this website, you can create free SSL certificates and they’re valid in most of modern browser.

FirefoxOS accept these certificate without any issues. So, big thank to StartSSL team !

Users setup

Installing those services is not very difficult. You have to spend some time to understand their configuration, to make something clean, something that works. But you can handle it.

The challenge that comes next is your users. In my case, family members.

They are ruthless ! They can’t imagine how difficult it is to find free and opensource solution for these services. Google’s services run so well that my family does not really understand problems behind.

So I had to make something really sure and relyable before letting them use it.

Moreover, I had to configure their devices myself. That’s the most painful point. But then, they’re realy happy and proud to see that all is working well.

Backups

That’s the last point.

When it’s not working, you do not need to setup your backup. But when you begin to have users, it become important.

For now, I use a CRON job to export data into my laptop. And once a week, the RPi at my parents’ house fetch data to have an external backup.

Conclusion

25$ for RPi, 20$ for cable and a few hours to lose and you got your personal services, free and open source based.

I am proud of what I’ve done here, it does exactly what I intended to :

It’s cheap
Relyable
Standard user can rely on it

So I invite anyone interrested on this subject to write me a mail if they need assistance.

Compiling «Boot 2 Gecko» on Debian

2014-11-19T19:32:42+00:00

I wrote about my Peak phone a while ago. It’s time to write again on FirefoxOS !

Using the geeksphone peak is a pain. Got lots of bug, my battery last for a few hours when I use it and it became very slow.
But I discovered the flame device and my doubt about FirefoxOS disapeared !
The device itself is beautiful, heavy as it should (in my opinions) and it works.
The only issues I got is about compiling my own image of FirefoxOS (cause I like to have my own). So I’ll explain how I did it here.

Why is there an issue ? In fact, I don’t really know, I didn’t dug into to find out, build scripts are asking for a particular version of gcc, a particular version of GNU make… etc…
I had the idea of using a Docker container to install those dependancies, but it’s already there

Just keep in mind before reading the README in this repository that you’ll need at least 20GB of free space on your disk in order to download all git repositories.
You can also find usefull information and scripts in this repositories:

https://github.com/Mozilla-TWQA/B2G-flash-tool.git

Happy Hacking :D

Software development in 2014

2014-09-09T15:31:55+00:00

At work, we have a lot of project. Different part of many solutions developed for many customers. As an example, Comarquage, a solution I have to maintain contains following sub-projects :

Biryani
Cosmetic
Etalage
Petitpois
Territoria
Some internal libraries
… etc…

You can find sources of those project and other here.

Problem

Those projects share lots of internal element, dependencies through each others and third party python libraries.

Moreover, we have some dependencies I’ll call “vicious dependencies”, like our CDN. You can easily change CDN in configuration files, but other CDN won’t have the same structure as ours… that’s how our CDN became a dependency in those project.

Nobody here at work seems to worry about those. Lead developers left the company and I find myself alone against all that code.

The problem lies in I’m the only one who can actually work on these project. No one can know where are dependencies, where are all git repositories, where are prod and preprod servers for all services. I am the only one who can install and run the Comarquage solution.

Solution

So I began a campaign through my company to put in place a few set of default behaviour all developers should have ! And I’ll adapt those software I have to maintain as examples.

README

First of all, lot of old project doesn’t have a README file, this is the most important file on a project, you have to write it and keep it up to date.

It must contains at least :

Description : What is this project, Why developing it ?
Quickstart / Installation : What should I do to begin development
Author
How to contribute

Those are a minimal requirement so any developer can find his mark fast and begin the work.

Dependencies list

The quickstart section in the README impose this point. A project has to be simple to install.

Sys/Admin will be happy… almost
Other developer can install dependencies faster and work faster

Minimal test suite

OK, you are an old and grumpy dev and you don’t want to write tests. I can understand… in fact, I don’t, whatever.

But please ! Write a minimal setup script, something we can run to tell if the project run or not.

Conclusion

Those elements are not enough in my opinion. A real project should have :

His documentation up to date
Unit test to avoid regression
User documentation… just telling what the project is designed for in a few line

I’m not asking to stop working and write poetry, just asking to do the job well enough to allow contribution.

The way we're reading mails is wrong ! Let's go fix it

2014-07-11T11:47:26+00:00

Since I started to work in a company, I keep receiving more and more emails days after days… And I know I’m not the only one.

I tried Thunderbird, I kept it a long while, it does the job :

Receiving mail
Reading them
Display them in thread
Replay to them

Except one big flaws, It doesn’t suit my work environment. I have another window.

Under gnome, e17 and almost every desktop I’ve been using, I created another workspace to separate mail from my text editor or web browser : I had to adapt my working environment to my mail software.

This is unacceptable, mails are simple, software that manage email must adapt to me, not rule over me !

So I tried Mutt, much better, but still, if I want to let it go in a corner in order to continue downloading mail when I’m working, I have to let an entire window, in another workspace and adapt myself the way Mutt works.

But wait, there are a lot of mail management software, mail fetcher or mail indexer out there, let’s give a try to those.

I configured fecthmail, to download my entire mailbox, then, with notmuch, I indexed them all, wonderful, I finally got a command line tools for getting/retrieving and writing responses with the editor of my choice !

BUT, that’s not fully suitable in my case…

I tagged my mails, I sorted them… LOCALLY, and that is not possible. It’s important for me to have the exact same information on my phone too.

And then, I realized that all I wanted, all the great features I miss, was in fact already implemented in the IMAP protocol…

Why the hell Thunderbird does not display my mails tags properly ? Why is there no software to have a mailbox state or search via IMAP SEARCH command ?

I look up for that on internet and find nothing. Is my request totally dump ? Am I crazy ?

In front of that huge problem of mine, I think I’m the only one complaining, but still, I have a problem with mail management software. So, I decided to make my own, a piece of software solving my problems… and perhaps solve someone else problems.

Imap-CLI aims to provide a command line interface, a python API and a REST API to consult and manage IMAP accounts:

Get IMAP account status (New mails, mail counting… etc…)
Get list of mails in INBOX (or any other directory)
Search amongst mails by tag, header, or full text search
Read mail
Flag mail (Read, Unread, Delete… etc…)
Reply, Forward, Bounce mails

Hope this proof of concept will help people as it already help me :)

Jump between often used directories

2014-06-11T17:36:21+00:00

When I’m showing code or asking for advice to a colleague, I’m always surprised by their reactions when they see my jump function.

I am not a huge fan of aliases, but the few ones I use are really priceless. And amongst them, my favourites is still jump.

Jump is a little collection of functions in my bashrc file allowing me to mark projects folder and jump to them from anywhere. For example :

$ cd ~/projects/client-dir/project-dir
$ mark
/* … */
$ cd ~/projects/another-client-dir/project2-dir
/* … */
$ jump project-dir
$ pwd
/home/gentux/projects/client-dir/project-dir

Jump is not alone here, functions include :

mark (create a new symlink)
marks (list symlinks)
unmark (remove mark)
jump (jump to mark)

All people I told about these little functions asked me to send them by mail, so, today I decided to create a new github repository to store it.

I can’t recall where I originally found those functions, I’ve been using them for a pretty long time now and I hope it’ll be useful to other people now :)

Upgrade Geeksphone Peak to nightly build

2014-05-02T10:25:54+00:00

About a year ago, I left my Nokia N900 phone to buy a Geeksphone device ( Peak ). This was hard, very hard… and it still is.

The phone I bought was a developper preview device, I couldn’t import contacts from my old device, I couldn’t check my personal calendars through it… But still, I wanted to be part of the FirefoxOS adventure.

Last stable update from Geeksphone was received on November 2013 and this situation began to really bothered me. Every bugs I experienced were solved and my apps weren’t updated either. Sometime I could even find nice apps wich were not compatible with my version of FirefoxOS.

So I put me fears aside and stepped into the flashing process to get a nightly build installed on my peak. Every step is simple, but if it goes wrong, I could lost all my contacts… Wich I entered by hand…

You can read the original version of these steps here.

First and Second steps are simple verification, have at least 50% of battery remaining and activate Remote debugging on the phone (go to Settings, Device Information, More Information, Developer and check on Remote Debugging).

Third step is for windows users only. Didn’t need it on my Debian.

You will then have to download a FirefoxOS image build for your phone. You can found those build in Geeksphone download pages. You can safely unzip it afterwards.

But wait a minute before running sixth step. You can found some piece of information out there, but nobody could clearly tell me if my data will be or won’t be lost.

First thing first, on Debian system, you’ll have to installed those package to run though next step :

android-tools-adb
android-tools-flashboot

Then, you will have to run adb as root. So plug your phone with USB cable and run :

# adb devices

It will start adb deamon and now can read throught your phone. You can then follow instruction to backup some data here (I didn’t need those)

If all goes well till now, you can safely do the last part. But I couldn’t run the flash.sh script given by Geeksphone because it don’t use adb and flashboot installed on my system.

So I edited the flash.sh script :

#!/bin/bash
adb reboot bootloader
fastboot flash boot boot.img
echo "Do you want to keep your user data ? (Some users has problems in first reboot, if you have, please reflash and select not to keep the data)"
select yn in "Yes" "No"; do
    case $yn in
        Yes ) break;;
        No ) ./fastboot flash userdata userdata.img; break;;
    esac
done
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot erase cache
fastboot reboot

Wait until your phone reboot and that’s it, you have the latest version of FirefoxOS :)

I’m using it every day and I really see how much progress FirefoxOS have made the last few month. To go further, I will rtry to build my own image of this OS and maybe I will have time to fix some bugs ;)

Reject badly encoded request in Python WSGI applications

2014-04-28T17:12:02+00:00

At Easter-eggs we use Python and WSGI for web applications development.

The last few months some of our applications crashed periodically. Thanks to WebError ErrorMiddleware, we receive an email each time an internal server error occurs.

For example someone tried to retrieve all of our french territories data with the API.

The problem is simple: when the request headers contains non UTF-8 characters, the WebOb Request object throws an UnicodeDecodeError exception because it expects the headers to be encoded in UTF-8.

End-user tools like web browsers generate valid UTF-8 requests with no effort, but non UTF-8 requests can be generated by some odd software or by hand from a ipython shell.

Let’s dive into the problem in ipython :

In [1]: url = u'http://www.easter-eggs.com/é'

In [2]: url
Out[2]: u'http://www.easter-eggs.com/\xe9'

In [3]: url.encode('utf-8')
Out[3]: 'http://www.easter-eggs.com/\xc3\xa9'

In [4]: latin1_url = url.encode('latin1')
Out[4]: 'http://www.easter-eggs.com/\xe9'

In [5]: latin1_url.decode('utf-8')
[... skipped ...]
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 27: unexpected end of data

This shows that U+00E9 is the Unicode codepoint for the ‘é’ character ( see Wikipedia), that its UTF-8 encoding are the 2 bytes ‘\xc3\xa9’, and that decoding in UTF-8 a latin1 byte throws an error.

The stack trace attached to the error e-mails helped us to find that the UnicodeDecodeError exception occurs when calling one of these Request methods: path_info, script_name and params.

So we wrote a new WSGI middleware to reject mis-encoded requests, returning a bad request HTTP error code to the client.

from webob.dec import wsgify
import webob.exc


@wsgify.middleware
def reject_misencoded_requests(req, app, exception_class=None):
    """WSGI middleware that returns an HTTP error (bad request by default) if the request attributes
    are not encoded in UTF-8.
    """
    if exception_class is None:
        exception_class = webob.exc.HTTPBadRequest
    try:
        req.path_info
        req.script_name
        req.params
    except UnicodeDecodeError:
        return exception_class(u'The request URL and its parameters must be encoded in UTF-8.')
    return req.get_response(app)

The source code of this middleware is published on Gitorious: reject-misencoded-requests

We could have guessed the encoding, and set the Request.encoding attribute, but it would have fixed only the read of PATH_INFO and SCRIPT_NAME, and not the POST and GET parameters which are expected to be encoded only in UTF-8.

That’s why we simply return a 400 bad request HTTP code to our users. This is simpler and does the work.

Four month using Rasberry Pi

2014-04-15T16:30:32+00:00

It’s been a long time since my last post. I’ve been through some difficulties in my professional life and that’s why I didn’t had time to worry about my Rasberry Pies.

And I’m glad to see how well they handled their job during this period.

In my first post I described what I was planning to install on a single RPi in order to handle all services I needed.

Since that, I openned 3 other accounts for my broser and my two parents… and I forgot about this.

In 4 month, nothing to report, all services are doing well for every account without performance issues. I’ll open some other account for close friends.

I’ll try to make a little documentation in the next few week to explain how it works

Make a NAS with Rasberry Pi

2014-01-19T18:42:32+00:00

The first step in making my own space on Internet with RPi is storage.

Nothing is possible without data storage, I need :

Backup (mail, configurations…)
Public Data (Shared links, shared photos… ect…)
Private Documents for users (and myself)

And the SD Card is not enough to store all that (in addition of that fact, I won’t store backups on the same drive as the backuped system)

I thought RPi was the right way to make all of this. I plugged in a 2To external HardDrive with its own power supply and began to backup configurations files and every home directory.

RPi works very well with backup and private documents, but problems appear when you need to share big files. My USB drive froze every minutes for a few second.

As for today, I haven’t found any viable solution to use RPi as the center of my world at home. Everything works fine appart sharing hard drives.

The solution I use today consist of sharing disks via my routeur (which provide samba sharing for external drives).

Gentux.IO opening

2014-01-09T18:42:32+00:00

I launch today officially the Gentux.IO project.

This will handle several aspect of my life and aim to centralize interactions with my friends.

Since I got a good connection at home (around 100Mbps), my thought about personal web services changed. I can consider now that anyone can store a little computer in a corner of the living room and forget about it. That’s, in my opinion, the purpose of Raspberry Pi computers.

So I bought one and installed the following services on it :

IMAP/SMTP
Web Server
WebDav Server
CalDav and CardDav Server
NFS shares

All services runs correctly using less than 300Mo of RAM (Raspberry Pi has 512Mo available). Services runs perfectly for me.

The next step is to open web services access to my family and friends. After that, I will write about performance and how Raspberry Pi handle those users.