Cher journal-pas-franchement-intime,
Hier*, j'ai effectué les premiers commits de mon stage. Et hier, j'ai cassé le build. \o/
Pour les non-geeks:
- Le commit: Lorsque vous avez finit de modifier un programme, vous envoyer ces modifications sur un serveur central pour les partager rapidement avec tout vos collègues. L'envoi de ces modifications est ce qu'on appelle le "commit" (ou parfois le "submit").
- Le build: Les gros projets informatiques sont en général particulièrement longs à construire de zéro. Mais cette construction est nécessaire pour s'assurer que tout le projet est cohérent. Du coup, un ordinateur est dédié à la construction périodique de l'ensemble du projet. Cette construction est ce qu'on appelle le "build".
- Casser le build : Ça consiste à commiter des changements qui empêche la construction du projet. Du coup, la machine chargée de le construire, après avoir lutter pendant au moins 1/2h pour construire le projet, se prend les pieds dans le tapis avant d'avoir fini. Du coup tout les programmeurs reçoivent un mail disant que quelqu'un a fait une boulette. Une fois le coupable démasqué, il se doit de commiter de nouveaux changements pour réparer le build (selon les habitudes de l'équipe, il peut aussi avoir un gage). C'est pas bien méchant, mais ça fait perdre un peu de temps à tout le monde.
Globalement, casser le build est quelque-chose qui arrive rarement, mais ça arrive. Parait que je suis un "membre à part entière de l'équipe" maintenant :)
(Au passage, mon collègue a flingué le build d'une autre équipe récemment, et eux, c'est un build nettement plus important que le notre :)
Quelques illustrations (en anglais) pour que vous compreniez bien à quel point casser le build est malpoli:
http://www.youbrokethebuild.com/
That is the law
* : Je l'aurais bien bloggué le jour même, mais ma connexion Internet à la NASA en a décidé autrement