Featured post

My schedule for Google I/O 2014

This year Google I/O will be about DDD, have you read the blue book ? Oh wait, sorry, it’s not about Domain Driven Design but Design, Develop, Distribute. Interesting to see that Google choose to replace the more common “Run” theme with a Distribute one. It feels like they are saying don’t worry anymore about how you will run your application, just use our cloud. But instead think how you will Distribute your mobile application… on google store of course.

We can expect a lot of announcements and sessions around Android. And a lot more, as you can see in the list of sessions I’m planning to attend. Can’t wait to learn more about Docker, Polymer, DevOps and the Google cloud platform !

Day one June 25

Day 2 June 26

Et en attendant…

Je me promène
San Francisco House San Francisco Parking

 

Featured post

Another Git branching model

We’ve switched to git at work a few month ago. Not an easy task but the rewards are worth the trouble. Our branching model was based on Git Flow because it’s well documented and gives you a structure to start with DVCS. Well, after a few iterations it wasn’t working as expected in our context. So we had to come up with our own workflow.

I guess Git Flow works well on a clean code base with good test coverage. But on legacy code, where one feature means two regressions, a release branch is like the vietnam war, you never know when you will get out of it. That was one of our main problem on subversion, we were creating release branch to go to production. And it would take forever to actually ship the code. Meanwhile all other development efforts remain stuck.

I though that cheap branching and merging in git would solve our issue. But cheap merging is not enough, you also need to be able to easily pick what to merge. And with Git Flow it’s not easy to remove a feature from a release branch once it’s there. Because a feature branch is started from develop it is bound by its parents commits to other features not yet in production. As a result, if you merge a feature without rebasing you always get more commits than wanted.

So here is the workflow we use to solve those issues:

The main branches

We have three branches with an infinite lifetime based on the classical trio (dev/test/prod):

  • master
  • staging
  • develop

Master is the same as in git flow:

We consider origin/master to be the main branch where the source code of HEAD always reflects aproduction-ready state.

Staging is a bit like develop in Git Flow :

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.

Develop is there for continuous integration, this is where we constanly merge all the changes to detect bugs and conflicts as soon as possible. The source code in the develop branch never reach a stable point where it is ready to be released. Instead only some feature branches reach a stable point. Those stable feature branches are merge into the staging branch. Since feature branches were created from master and not from develop we can pick individualy which one will be merge to staging. In fact this is the main point of this workflow: We can easily choose which features will go into production next. 

To release the code to production we just merge staging into master.

Feature Branches

All work is done in feature branches which can be merge into

  • master for a quick fix in production
  • staging for bug fixes
  • develop constanly for continuous integration

Since we use github we usualy do a pull request to merge feature branches. We don’t always follow the rules and commit on master and staging happens, they are merge back to staging and develop. The only place where we don’t commit is develop ;) (only merge commit)

Summary

Git Flow was not working for us, but by creating feature branches from master instead of develop we gained the ability to easily choose which features we release next. This gave us much more flexibility and got us out of “vietnam release branch”.

Now I should tell about all the best practices to make this workflow really work, but I’m lucky, someone already wrote them down.

And you, what is your branching model ?

Featured post

L’architecte

La tête dans les nuages
Les mains dans le cambouis
Les pieds sur la prod

 La tête dans les nuages

Pas parce qu’il s’intéresse au cloud, mais parce qu’il doit prendre de la hauteur et du recul pour analyser, synthétiser et savoir restituer des vues adaptés à chacun des acteurs d’un projet. Il est le garant d’une vision partagée et cohérente des objectifs métiers stratégiques jusqu’aux déploiement des composants logiques sur des serveurs physiques ou virtuels.

Les mains dans le cambouis

L’architecte qui ne code plus (pire n’a jamais codé) a vite fait de s’envoler dans les nuages et de perdre le contact avec la réalité. De la vue aérienne d’un projet il doit pouvoir zoomer sur un composant logique, sa conception et la ligne de code. Seul un astro-architecte qui ne quitte jamais les stratosphères de sa cellule architecture et méthode peut retenir des technologies comme EJB1/2 ou JSF, qui en pratique sont inutilisables. Une technologie ou une architecture peut avoir toutes les qualités que l’on voudra, si elle n’est pas comprise et adopté par les développeurs ça n’ira pas loin.

Les pieds sur la prod

Tan qu’il n’est pas entre les mains des utilisateurs un projet informatique ne produit aucune valeur. Et le passage obligé pour atteindre les utilisateurs c’est la prod. Vous suivez à la lettre les recommandations du site 12factors ? Super votre application est prête à être déployé dans le cloud. Dommage, ce qu’attend votre prod c’est un ear pour déployer sur webFear ! Pour que le succès d’une application soit complet travailler en étroite collaboration avec les gens de la prod (Devops) et aussi important que de leur faire avec le métier (les méthodes agiles)

Et chez vous il fait quoi l’architecte (logiciel bien sûr) ?

10 ans

Il y a 10 ans, le 3 avril 2004 j’ouvrais ce blog. Google n’était encore qu’un moteur de recherche performant… Amazon qu’un libraire, Face… FaceQuoi ?? Les téléphones n’étaient pas smart et Nokia dominait le marché.

Il y a 10 ans Google lançait Gmail, un 1ere Avril, 1 Go de stockage gratuit, une application web aussi réactive qu’un client lourd, la bonne blague… Eh oui Ajax n’était encore qu’une marque de détergent. Subversion était un outil acceptable pour gérer les sources, Flex une solution d’avenir, Struts était en version 1 tout comme Spring, javascript était tout juste bon à ouvrir des pop-ups. Chrome n’existait pas, IE6 s’était imposé face à Netscape.

Il y a 10 ans la France votait la Loi pour la confiance dans l’économie numérique et aujourd’hui il faut écrire un rapport pour mettre en valeur les développeurs alors qu’il y a longtemps que le reste du monde a compris que le logiciel dévore le monde

Depuis 10 ans ce ne sont pas les sujets qui manquent, je vais profiter de cet anniversaire pour ranimer ce blog, rendez-vous dans 10 ans.

Des tweets et des plus n°22 – Et ça sert à quoi ?

La vérité sur le chiffrage en Sociétés de Services en Logiciels Libres : “Nous aimons coder. Coder ne nous coûte pas car c’est notre plaisir. D’ailleurs, nous codons  gratuitement une bonne partie de notre temps (dans le cadre de nos contributions open sources). Le reste de notre travail, en revanche, nous coûte.”

Stop Using Story Points :  “Like researchers of fast food, we now know that the Agile Happy Meal contains unnatural ingredients that decrease agility and cause process indigestion.”

What’s my IT strategy? : “Take a company’s IT strategy [...] Now remove XXX [...] What is left, is the IT strategy”

Java feature applicatbility : “I group Java features in three categories: day to day, occasionally and never (frameworks and libraries only). The rule is simple: if you find yourself using given feature more often then suggested, you are probably over-engineering”

Des tweets et des plus n°21 – Good Cheap Fast, pick two

The Most Important Question : “Everything involves trade-offs, where benefits must be weighed against their associated costs. Evaluating those trade-offs and choosing according to the needs of the customer is a key responsibility of an architect.”

Learnable programming : “A programming system has two parts. The environment is installed in on the computer, and the language is installed in the programmer’s head.”

Some things I’ve learnt about programming: “When writing code it’s sometimes tempting to try stuff to see what works and get a program working without truly understanding what’s happening.”

Dear “API providers”: “I just want the data on your website in a machine readable format. XML, JSON, RDF, CSV, YAML, I don’t particularly give a fuck.”

 

Des tweets et des plus n°20 – The road to hell

 OAuth 2.0 and the Road to Hell: “At the core of the problem is the strong and unbridgeable conflict between the web and the enterprise worlds”

Journey Through The JavaScript MVC Jungle: I want a javascrit framework…

Agile France : Le combat des chefs : avec  Bougetépostix et Testotomatix… tout un programme.

Le changement, c’est (bientôt) maintenant: “nos organisations privées ou publiques, notamment tertiaires, sont orientées vers leur maintien, plus que vers le service à leurs usagers”