 Je travaille chez Google depuis six ans et demi maintenant, puis je travaille sur Chrome depuis le début. J'ai travaillé sur quand même quelques projets, comme par exemple j'ai fait l'impression, donc si ça imprime mal, c'est un peu à cause de moi. J'ai travaillé aussi sur beaucoup d'infrastructures au fait depuis, j'ai travaillé un petit peu sur la sandbox aussi. Puis là, je travaille sur des nouveaux types d'infrastructures dont je peux vous parler. Je parlais des défis parce que Chrome, c'est quand même un assez grand projet avec une assez grande équipe, mais avant, je vais parler aussi un peu d'historique. Je vais parler de la génèse, de l'état actuel, comment on essaie d'aller vite, comment on essaie d'aller plus vite et comment l'infrastructure peut survivre là-dedans. Le tout a commencé le 2 septembre 2008. Au fait, on voulait sortir le 3, mais on s'est trompé dans la livraison. Alors, un des livres explicatifs est arrivé un petit peu trop vite. La version 1 est sortie le 11 décembre, mais je vais parler du pourquoi on a parti ce projet-là. La mission du projet, c'est move the web forward. C'est essayer d'augmenter ce qui était possible de faire avec le web dans le temps. On voulait vraiment dynamiser l'écosystème du web. Il ne faut pas oublier que dans la génèse du projet, Internet Explorer 7 était sorti en 2007. Internet Explorer 6, c'était sorti en 2001. Google fait des sites web entre autres. Donc, on voulait supporter, on a obligé de supporter une navigateur que les gens utilisent. Alors, on voulait augmenter un peu la possibilité de ce qui est possible de faire avec le web. Ici, il faut vraiment rendre le web une vraie plateforme. C'est vraiment le pourquoi le plus important. Si vous ne savez pas pourquoi vous faites quelque chose, en général, vous allez le faire assez mal. Donc, on s'est mis quatre principes. Une des techniques qu'on a utilisées, c'est d'utiliser le système de multiprocess. Donc, le renderer fait la gestion de charger le contenu des pages web et le browser fait l'interface usagée. Ça nous a permis de créer ce qu'on appelle la sandbox qui permet de sécuriser le parsing du HTML. Donc, beaucoup de membres de l'équipe contribuaient aussi à Firefox, mais c'était quelque chose qui, tant de temps, était difficilement un peu architecturé. Donc, nous avons décidé d'expérimenter avec quelque chose de nouveau. On n'était vraiment pas sûrs de réussir. On n'était pas sûrs que la sandbox avait fonctionné non plus. On aurait pu se planter vraiment solide. À la fin, on a quand même réussi à faire ce qu'on appelle un navigateur. Donc, c'est bien beau avoir une vision, mais il faut être capable de mesurer un peu l'impact. On est vraiment contents parce que le nombre d'utilisateurs a doublé à chaque année. C'est sûr là-dedans, il y a quand même quelques robots et personnellement, je dois compter pour au moins 10 utilisateurs. Mais l'idée ici, c'est qu'un utilisateur, ce n'est pas nécessairement un utilisateur heureux. Donc, peut-être ce qu'utilisaient, c'était good enough. Donc, ça a été quand même assez intéressant parce que, pour la majorité des gens qui utilisent Chrome, Google Chrome, ils ont eu à l'installer par eux-mêmes. Ça, c'était de loin la plus grande barrière. Donc, dès le départ, on a décidé de faire pour qu'un utilisateur, sans avoir les droits d'administateurs, puisse l'installer sur sa machine. Je pense que si on n'avait pas fait ça, je pense qu'on n'aurait jamais eu de succès. Puis, on a réussi quand même à percer quand même, atteindre les gens. Google Chrome est maintenant un des navigateurs les plus utilisés dans le monde. C'est sûr que les taux de part de marché sont toujours apprends avec des pincettes. Ça dépend toujours un peu comment on mesure les chiffres. Mais, une chose est claire, au moins, qui est indiscutable, c'est le nombre de versions. Mais là, encore, il faut dire, plus ou moins deux, parce que la version D avait rendu la version 33. On a eu une quantité innombrable de versions mineures. Mais, l'idée, c'est bien beau, mais à chaque version, c'est une très belle occasion de pouvoir briser Chrome pour tous nos utilisateurs, simultanément. Alors, on peut pas vraiment prendre ça à la légère. Par exemple, son brise de Chrome pour 1 % de sa tasse, c'est quand même presque 7,5 millions de personnes. Alors, on sort une version à toutes les six semaines maintenant. On n'est quand même pas fou, on ne fait pas de version à Noël ni en juillet. Mais, on garde quand même une cadence assez élevée. Alors, l'idée, au fait, c'est qu'on veut que chaque version soit similest, transparente, et qu'on ait, ça soit presque impercédible la majorité du temps. Alors, au fait, la plupart des gens pensaient qu'on allait se planter quand on a décidé de passer à six semaines. C'était quelque chose quand même assez audacieux en 2010, une saumée en 2013. Et pourtant, Mozia a fait de suite un an plus tard, et maintenant, enfin, une fois qu'on se rendait à la version 25, même maintenant, Internet Explorer... 26. 26, oui. Et Internet Explorer, maintenant, est mis à jour plusieurs fois par décennie. Nous, on trouve ça vraiment super. Au fait, c'est tout à fait en lien avec la mission. On peut faire plus de choses avec ce qui est possible avec le web. C'est ça qu'il faut qui arrive. Donc, une des premières choses que l'on avait décidé, c'était les mises à jour automatiques. C'était assez hors normes, mais il y avait plusieurs raisons. L'important pour nous, c'était de mettre à jour nos utilisateurs rapidement. La raison numéro un, c'était la sécurité. Si vous avez un trou de sécurité, vous êtes capable de mettre à jour tous vos utilisateurs rapidement. L'ouverture d'opportunités d'un ZROD est très, très réduite, et ça va l'air en être tout autant réduite. On voulait aussi que ça soit simple, comme je l'ai dit tantôt, donc un peu transparent, un peu comme le web. Je ne pense pas que personne aime ça, avoir une petite boire de dialogue, mis à jour et empêcher moi de travailler pendant cinq minutes. Alors, on ne voulait pas que les utilisateurs, cette expérience-là, on voulait que ça soit un peu comme l'utilisation du web. On n'a pas de mise à jour sur le serveur. Les utilisateurs, on ne voulait rien savoir de ça. Troisièmement, le pays est stable. Le web est le pays. Google Chrome est un terminal au sens classique du terme. Donc, les développeurs peuvent coder en fonction de la version courante, qui est la dernière version stable qui est sortie. Donc, évidemment, nos utilisateurs sont sur plusieurs plateformes. Ça représente beaucoup de défis. On a plusieurs dizaines d'utilisateurs sur cette thème d'exploitation-là. Puis, on a aussi beaucoup d'utilisateurs sur celle-là. Et au fait, ça a été un gros challenge le Chrome OS. Qui a déjà utilisé un Chromebook ici? Pas grand monde, ok? C'est vraiment bon. Oui, j'en ai plusieurs. Mais un des gros problèmes avec les Chromebooks, c'est qu'en général, ils vont bien. Je suis prêche pour ma paroisse. Mais un des gros problèmes, c'est que les gens ne redémarrent jamais. Il n'y a aucune raison de redémarrer un Chromebook. Alors, le mise à jour se fait durant le redémarrage. Donc, il y a beaucoup de gens qui restaient sur des anciennes versions. Alors, éventuellement, il a fallu comme forcer un peu les gens. Après une semaine, si vous me mettez en veille, on va redémarrer pour vous. Heureusement, ce qu'on essaie de faire aussi, c'est quand même garder la mise à jour le moins dérangeant possible. Puis, on s'entend, redémarrer une machine, c'est dérangeant. Donc, on essaie de recharger les tables, de sauvegarder l'état le plus possible. Étant donné que c'est des pages web, on a déjà tout parcé l'HTML. Donc, c'est quelque chose qui est quand même techniquement faisable. Donc, l'idée principale, il faut souvenir, c'est de mise à jour pas dérangeant. Seamless. Donc aussi, on a utilisé un peu la même idée sur le Chromecast. Qui connaît, c'est quoi un Chromecast? En gros, c'est une plug à télé. Donc, le Chromecast, au fait, c'est la même idée, il se met à jour pendant que vous l'utilisez pas, pendant la nuit, pendant que la télé est éteinte. Qui veut mettre à jour sa télé? Qui a déjà mis à jour sa télé? Je pense que c'est une des pires expériences que vous pouvez avoir. Donc, l'idée, au fait, c'est que ça, c'est les systèmes d'exploitation qui nous permettent de faire la mise à jour puis qu'on contrôle. Il y a les mises à jour où on ne contrôle pas et la mise à jour, on le fait notre place. Au fait, il y a Ubuntu. Moi, personnellement, j'utilise Ubuntu. Donc, il utilise le standard repository natif à des biens. Donc, ça prend un petit peu plus de temps avec les utilisateurs de mise à jour, mais ils savent quand même. Android a quand même un système de mise à jour assez performant maintenant. Donc, en général, une grande partie des utilisateurs sont mis à jour dans l'intérieur de quelques jours. Donc, c'est quand même assez efficace. Sera iOS aussi, c'est quand même pas trop pire. On supporte iOS 5, 6 et 7. Donc, les bugs sont différents. Il y a plusieurs types de devices à supporter. Donc, ça fait quand même beaucoup de devices à tester. Ça fait quand même une assez grande matrice. L'idée, au fait, c'est qu'on essaie de sauver du temps aux gens parce que 5 minutes à grande échelle, ça représente beaucoup de temps. Donc, on fait un effort vraiment fort pour l'humanité. Donc, c'était un peu l'idée au fait que Chrome, c'était quand même un assez gros projet. Maintenant, j'aimerais vraiment parler plus du technique. Qui peut me donner une ordre de grandeur du nombre de lignes de C++ que dans le projet, mais en excluant toutes les third parties, excluant V8, Webkit, whatever. Ce que quelqu'un peut me donner une ordre de grandeur en ligne de code en C++. Non, c'était un petit peu trop épaisant. 750 quoi? 1000 lignes de code. Ah, un petit peu plus. Une ordre de grandeur. Ok. Combien de comites vous pensez qu'il a pu se produire en 5 ans? Donc, de changements dans le code source. C'est dur à dire. Qui a déjà fait un check-out de Chrome? Ah, quand même. Et qui a réussi à compiler? Ah, un petit peu moins. Ah, excuse-moi. Mon travail fort. Donc, on a fait quand même beaucoup de changements. Ça, c'est depuis qu'on est rendu Open Source. Donc, chaque changement, c'est un changement atomique dans le code source, une modification transaccionnelle. C'est un humain en général, qui l'a fait. Ça exclut tout ce qui est comme blink, WebRTC, V8, etc. Ça exclut aussi l'infrastructure. Webkit aussi précède Chrome. Donc, je ne l'ai pas compté. Ça date du temps de codier, etc. Ça date au fait de 1999 dans ce coin-là. Donc, c'est quand même assez gros projet. Puis, c'est quand même beaucoup de lignes. C'est ça. Au fait, je n'ai même pas compté blink. Je n'ai pas compté l'objectif, si. Ça exclut aussi 680 000 lignes de commentaires. Et à peu près 830 000 lignes blanches. Donc, vous pouvez vous demander pourquoi il y a plus de lignes blanches que de commentaires. Je ne sais pas. Mais, il y a à peu près... Là, j'ai eu de la difficulté à compter. Il y a à peu près 200 000 lignes de Python. Le code d'infrastructure tendance est un petit peu plus éparpillé. Donc, c'était difficile d'avoir un chiffre plus exact. Et ça, ça exclut aussi Chrome OS, qui est un projet à part, qui inclut aussi le kernel de Linux. Donc, c'est quand même assez gros. Ce qui est intéressant, c'est que j'ai donné la présentation. Il y a 6 semaines à Sherbrooke. Vous voyez, depuis 6 semaines, 6 000 comites, 1 000 nouveaux fichiers, 200 000 lignes de code qui ont été écrites. Donc, ça vous donne une heure de grandeur. Donc, il y a des gens qui ont des questions sur l'état du projet. C'est la grosseur du projet. Donc, comment on explique qu'on a besoin de 200 000 lignes de code nouveaux en 6 semaines? J'ai un super manager. Donc, je ne peux pas répondre à cette question. Mais, c'est une excellente question. Le projet veut... veut... veut augmenter le nombre de choses qui sont possibles à faire sur le web. Comme, par exemple, faire un... un exemple très interrataire, WebRTC, être capable de faire de la videoconférence. Est-ce qu'on considère ça une fonctionnalité essentielle, web ou non? C'est discutable. Mais, c'est une des fonctionnalités qu'on a décidées de supporter de façon native, par exemple. Donc, l'idée au fait, c'est que, bon, on a quand même un assez gros projet. Il faut garder une bonne vitesse de développement. Surtout avec une grande équipe sans se piler sur les pieds. Donc, ben, vraiment, il faut beaucoup de protection. Puis, je veux vraiment insister sur le premier point, code reviews. Des code reviews, il y en faut. Ben, qui a une idée, c'est quoi un code review? OK. Donc, qui peut me dire pourquoi c'est bien un code review? Samyari. Pour Samyari, soi-même, oui. Pour rire des autres, oui. Mais, c'est pas bon à long terme. Pour... Hein? Ben oui, pour avoir une deuxième perdue, exactement. Est-ce qu'il y a des personnes qui peuvent penser à des désavantages à faire des codes reviews? Oui. Nous, on a un terme pour ce que la personne vient de créer au fait de faire du nitpicking. Essentiellement, aller chercher au niveau fonctionnel. C'est vrai. Est-ce qu'une autre personne peut parler de... Oui. Donc, c'est beaucoup plus long créer des comites parce qu'il faut attendre qu'une autre personne donne son opinion sur le changement qu'on a fait. Donc, ça a induit beaucoup de délais. En contrepartie, les avantages sont plus importants que les désavantages. En général, la qualité du code est extrêmement meilleure que si il n'y en avait pas. Donc, il faut tester un bon 80% des bugs qui ferait du code qui fonctionnerait tout simplement pas. Bien, probablement aussi, il faut tester un code complet dans le premier lieu. C'est plus facile à dire qu'à faire parce qu'on se porte plusieurs plateformes. Donc, c'est techniquement un peu difficile de pouvoir tester son changement simultanément sur Windows, OS X, Linux, ensuite de tester que ça fonctionne bien sur iOS ou bien sur Android. Donc, puis chacun des 27 par exemple, si vous savez que GCC 4.6 ou 4.8, les erreurs ne seront pas tout pareils. Si vous savez Clang 5 ou bien 4.4 ou plusieurs studios, chaque version de Visual Studio a des erreurs un petit peu différentes. Étant donné qu'on se porte beaucoup de tout le set, c'est très intéressant. Donc, ce qu'on fait au fait, c'est qu'on demande d'une infrastructure de tester pour nous. Parce qu'à un moment donné, on n'a pas juste ça à faire. Donc, j'ai codé quelque chose qui s'appelle a try server. Et au fait, ce que ça fait, c'est que ça roule des tests de pré-commit. Qu'est-ce que c'est ? C'est que ça roule comme si votre code avait été comité. Donc, ça applique votre patch, ça compilte et ça teste sur plusieurs configurations avec des tests pré-déterminés. Ça donne pas une couverture complète, mais ça donne déjà une bonne idée que le code a quand même un certain niveau de qualité. Puis ensuite, une fois qu'elle commite et prêt à être comité. Donc, je fais beaucoup de conjugaison de verbes comme ça. Donc, l'idée au fait, c'est qu'on utilise un autre infrastructure qui s'appelle la commit to, qui sert, c'est juste une petite checkbox. Puis ce qu'elle fait, c'est qu'au fait, elle essaie de faire ce type de vérification mais de façon automatisée. Et quand c'est possible de faire le commit vraiment dans le tree, il va le faire pour toi et mettre ton nom dessus. Donc, l'idée au fait, c'est qu'ensuite, on fait des vérifications sur le tree une fois que le commit est fait. Mais là, il y a des tests, vraiment des centaines d'heures de tests pour vérifier qu'aucune regression est attrapée là. L'idée au fait, c'est que si on ne mesure pas en continue, ça va regresser. Donc, mesurer, mesurer, mesurer tout le temps. C'est bien, mais c'est pas suffisant. Il faut quand même un certain niveau d'humanité dans l'infrastructure dans les processus. C'est une protection humaine concrète, donc on les appelle BuildSheriff. On peut voir ça un peu comme du cheap labor ou bien de porter volontaire contre leur gré. C'est les développeurs qui sont sur une rotation de deux jours ou est-ce qu'ils doivent être BuildSheriff. Ce qu'il faut en fait, est-ce que quand il y a eu des problèmes sur la Continuous Decoration Server, est-ce que c'était par exemple un test qui était flakie? Est-ce que c'est un test qui a fait un problème d'infrastructure? C'est un comité qui brise un test. Il faut enlever le comité. Comment on fait pour enlever un comité qui a déjà été comité? On comite l'inverse du comité. On fait ce qu'on appelle un revert. Entre-temps, il peut avoir eu d'autres comités. Ce qu'on fait, c'est qu'on fait notre changement, le changement mauvais, il y a d'autres changements. On va appliquer l'inverse, le négatif du changement par-dessus. Plus qu'on attend, pire que ça va être parce qu'il y a des chances qu'il y ait d'autres changements entre eux qui interfèrent. Donc, c'est la tâche des bitchiriffes de face là. Ici, c'est une petite visualisation de notre Continuous Integration Server. Au fait, on fait une vérification quand même assez minutieuse des changements. Cette page en passant est disponible sur le net. Donc, on a des tests spécialisés, par exemple pour la performance, la stabilité, la mémoire, les GPU, l'accélération graphique, les tests testés sur quatre, cinq, six plateformes. On compile Chromium, on compile Google Chrome. La raison qu'on l'appelle notre table de Noël, c'est quand les tests s'échouent, la petite boire devient rouge. Donc, ça crée des très belles guidelines. Le jaune est un test qui est en cours d'exécution et l'orange veut dire un avertissement. Donc, quand il y a beaucoup de tests qui échouent, au fait, c'est ça. Le tout devient rouge et non vert. Et c'est rarement ouvert. Quand le bitchiriff fait un diagnostic d'une régression, il ferme le tuer. Au fait, ce qui l'empêche les gens de pouvoir racheter des nouveaux comites. Ça bloque les comites, mais le problème, c'est que ça crée une accumulation. Pendant ce temps-là, les gens veulent continuer à racheter des changements, mais personne ne peut le faire. Alors, quand il rouvre le tuer, ça peut créer un effet de... d'avalanche ou est-ce que plein de comites arrivent d'un coup, puis là, l'infrastructure est capable de tester de façon efficace. Donc, il y a quand même une certaine nuance dans le travail des bitchiriffs qui rend la tâche encore plus intéressante. Donc, le problème, au fait, c'est qu'on ferme le tuer. Donc, les parties rouges, c'est quand le tuer est fermé. Donc, comme vous pouvez voir, il est très souvent fermé. Donc, c'est quand même pas facile, au fait. Puis, un des problèmes, c'est que quand un comité arrive, bah là, il faut faire checker des sources, il faut compiler, après ça, il faut rouler les tests. Puis, en plus, d'un point de vue purement probabiliste, par exemple, s'il y a un test qui choue 1 % du temps pour aucune raison. On appelle ça un test flakie. Puis qu'on roule 100 tests par comité, la probabilité qu'un comité ferme un comité arbitrable, qui a aucun rapport, ferme le tuer est quand même assez élevé. Donc, il y a-t-il des gens ici qui sont à l'université? Ah, pas grand-monde. OK, quelques personnes. Donc, en tout cas, pour ceux qui ont eu leur cours de probabilité, vous savez que c'est très important. Donc, les probabilités, les statistiques sont extrêmement importantes dans l'analyse de performance d'infrastructure. Donc, c'est beaucoup de travail. On fait la coordination sur l'IRC. On aime ça, c'est très autisteil. On est sur FreeNode, sur Chromium. Donc, ça aussi, au fait, c'est disponible sur les nets. Donc, ferrir de nous, on s'en cache pas. Est-ce que vous avez des questions sur la gestion des comités? Oui. Donc, la question était, bien, quand on a des tests qui ont été test aussi, il m'a donné, il faut arrêter de perdre son temps à regarder ce que le test fait. On le fait, mais de façon, pour l'instant, c'est semi-automatique. Donc, on a quand même une certaine infrastructure. Je discuterais pas de ça en particulier aujourd'hui, mais on a quand même une certaine infrastructure pour analyser ça. Donc, en général, le cas d'infrastructure est fait en Python et de facto, on essaie vraiment de tout faire open source. C'est une question philosophique. Mais un des grands défis, c'est qu'il faut avoir beaucoup, beaucoup de vision parce qu'une fois que les besoins actuels sont réglés, il faut vraiment être visionnaire pour être capable d'estimer les besoins futurs. Donc, on retourne toujours à la vision. Si on regarde pas la vie d'ensemble, on va se faire manger tout rond. Donc, bon, on a les tests, les codes review, c'est bien, mais c'est pas suffisant. C'est arrivé qu'on pousse des versions brisées. Alors, il faut un système de feedback, de rétroaction. C'est extrêmement important. Par exemple, des crashes pour nous, c'est des deal breakers. On constate que c'est pas acceptable que Chrome crash. Donc, il faut vraiment faire de la surveillance d'émétrique. Pour avoir un ordre de grandeur, qui roule le canal beta de Chrome? Ben, j'utilise pour ceux qui utilisent Chrome. Trois personnes qui utilisent le canal dev. Oh, une personne. Canary. Quatre personnes, c'est bizarre. Et qui en a aucune idée? Ah, quelqu'un. Vous, vous roulez la version stable. Et c'est correct comme ça. Au fait, l'idée, c'est que vous voulez quelque chose qui marche. Un moment donné, tu prends ton auto, il y a des gens qui prennent un auto, ils ont pas besoin d'avis. L'idée, c'est qu'il y a beaucoup de gens qui ont besoin d'un navigateur. Donc, l'idée, c'est qu'on veut juste qu'un navigateur qui est stable, par défaut, le canal est stable. Ce qui est triste, c'est qu'on peut pas vraiment atteindre zéro crash. C'est impossible. La raison est bien simple. Il y a des gens qui utilisent des ordre de grandeur brisés. Comme par exemple, on avait vu un crash report. Il y avait quelqu'un qui avait vu un crash, puis il y avait une ligne de commande et il y avait une lettre qui était pas bonne. Comment il peut se produire? Il dit qu'il y a une autre copie dans memory dump. On va regarder une autre copie. L'autre copie était bonne. Il y a vraiment vérifié et c'est un bit de changement. Donc, la personne, c'est dans sa rame, un bit qui reste tout en prix à un. Si ça donne que c'était un bit zéro que félix ou écrit, c'est juste too bad. C'est crash. Donc, les informations anonymes de même qui sont collectées de façon agrégée, nous, ça nous permet d'avoir des idées sur les statistiques. En fait, c'est vraiment de l'analyse statistique où est-ce qu'on se dit si tout le monde d'un jour arrête d'imprimer, c'est peut-être qu'on peut plus imprimer, par exemple. Donc, des choses comme ça, c'est quand même important. Donc, ça nous permet de savoir, par exemple, quand il faut faire des changements critiques. C'est tout ce que l'entend normal ça brise. Donc, comme je disais, on utilise des canaux. La section blanche en bas, au fond, c'est la section canaries, c'est le trunk, c'est qu'est-ce qu'on pousse carrément, qu'est-ce qu'on vient de commuter. Oui. Si on fait des tests avec les extensions, on en fait un peu avec les nôtres, mais on ne teste pas vraiment les extensions des autres. Donc, on s'assure que notre propre API est stable. Donc, c'est à nous de tester nos APIs pour s'assurer qu'elles sont stables. Mais on ne prend pas des extensions qui existent pour tester pour vérifier qu'on tient à fonctionner. C'est à nous de s'assurer que les extensions fonctionnent. Même les plus populaires. Donc, l'idée au fait qu'on fait du pipelining, un peu comme les processeurs, donc on pousse des versions puis on essaie de les envoyer dans les canaux supérieurs s'ils deviennent à Microsoft ou est-ce qu'ils font des tests avec des applications populaires. Au fait, les extensions sont mis à jour à l'intérieur de Sincar. Donc, si un développeur fait une mise à jour de l'extension, tous les utilisateurs sont mis à jour dans le Sincar. Donc, on ne peut pas faire de tests cohérents en continuous integration sur des extensions qu'on ne contrôle pas de code. Donc, c'est à nous de vérifier que l'API congénère est possible. Donc, au fait, comme je disais tantôt, on essaie de toujours monter une version plus stable. Puis l'important au fait, c'est que ça prend du temps avec les gens, on a du feedback, il y a un bug qui est introduit. Donc, l'idée au fait, c'est qu'on essaie d'affiner le produit dans chacun des channels. Puis après ça, six semaines plus tard, on le bombe dans le channel d'après. Donc, ce qu'on fait au fond, c'est qu'on le laisse pour des agents de marinades. Donc, l'idée au fait, c'est qu'on ne veut pas pousser une version brisée parce que au fait, ça crée beaucoup de tristesse. Donc, on essaie de limiter ça à peu près 1 % de nos tests, c'est-à-dire ceux qui utilisent la version dev. Donc, maintenant, on fait des versions toutes les six semaines, mais ça n'a pas toujours été le cas. Mais ça crée quand même beaucoup de... Au fait, dans le temps, on avait encore plus de changements par version. Par exemple, la version 5, le pic qu'on voit ici, ça a été la première version, au fait, à supporter officiellement l'INUX et OSX. Donc, on a décidé à partir de ce moment-là de sortir toutes les versions simultanément. Comme vous pouvez voir, il y a eu comme une dépression des développeurs à la version 8, ou est-ce qu'on est descendu en boite 650 comites par semaine. Mais maintenant, vous pouvez voir qu'il y a quand même une certaine tendance assez linéaire. Où est-ce qu'on s'approche d'engereusement du 10 000 comites par version par six semaines. Dix mille comites par six semaines, c'est 1660 comites par semaine et une semaine, ça ne change pas. C'est 168 heures. Donc, ça donne 10 comites par heure. 24 heures sur 24, 7 jours, c'est succès. Évidemment, il y a des bursts. Le monde travaille le jour, la semaine. On n'est quand même pas fou. Mais ça commence quand même à faire beaucoup de changements par version. Alors, c'est un peu difficile de faire des versions de ce genre. Alors, probablement, qu'est-ce qu'on peut faire? On peut mettre des bureaux partout dans le monde. Donc, on a peu près de vingtaine de bureaux dans tous les fusaux horaires. Et évidemment, au Canada, le plus meilleur pays du monde. Mais, même à ça, la vitesse c'est bien, mais l'accélération c'est mieux. Donc, on essaie de faire encore mieux. Alors, qu'est-ce qu'on fait pour augmenter la performance de l'équipe? Mais avant, est-ce que vous avez des questions sur comment on fait pour essayer d'être rapide? Oui. Oui, les tests sont très paralysés. Donc, la question est à propos de est-ce qu'on roule les tests en série ou en parallèle. On les roule beaucoup en parallèle. Je vais en parler au fait un peu tantôt. Donc, vous pourrez voir une des techniques consistes pour améliorer la performance. Oui. Donc, la question était, est-ce que c'est Google essentiellement qui fait des comites? Ou bien, il y a beaucoup de gens d'ailleurs. C'est encore, c'est toujours Google qui fait la majorité des comites, des Googlers, des employés de Google. Mais on a beaucoup, beaucoup de gens d'autres compagnies. J'ai pas de chiffres, mais c'est le cas des publics, donc pour y regarder vous-même, j'ai pas de chiffres exacts pour donner des proportions. Mais je vous dirais que c'est de plus en plus de compagnies qui contribuent. Mais je dirais que, aussi, plus de compagnies qui ont tendance à contribuer au OSC, à Chrome, spécifiquement. Tout simplement à cause de l'interaction directe avec le matériel. Donc, les compagnies ont souvent plus d'intérêt. Mais il y a beaucoup de compagnies qui contribuent. Donc, bien, au fait, l'idée, c'est que là, on fait accélérer. Donc, on veut faire comme des comites à toutes les quelques secondes. Le travail commence à être un peu intense. Bien, comment on fait ça? Bien, premièrement, on s'inspire beaucoup de comment Google fonctionne. Vous me regardez, je dis, tu travailles sur Google. Oui, mais Chrome, c'est un peu comme un app chez Google. On ne fait pas de service web. On fait une application client. Donc, au fait, ce qui est drôle, c'est que la cadence est vraiment plus élevée à l'intérieur de Google sur les projets de service web. Si ce sujet vous intéresse, Google Engineering 2 c'est un blog qui a posté quelques pièces en 2011 qui décrit à haut niveau comment ça fonctionne à l'interne. Il y a des détails aujourd'hui pour question de temps, mais je vous conseille d'aller voir les neuf entrées. Vraiment, par exemple, vous apprendrez par exemple que sur le code source de Google, on fait à peu près 20 comites par minute. Ça vous donne une idée. Vous faites un check-out, vous faites un changement, vous le poussez. Il y a peut-être 1000, 2000 comites qui ont eu lieu entre temps. Donc, c'est quand même assez intense. Le moteur de recherche. Bien, le moteur de recherche, c'est le code source des services de Google. En même temps, on pourrait essayer de faire des mises à jour plus rapides, mais le problème, c'est qu'on ne peut pas faire des mises à jour trop rapides. Parfois, ça prend plusieurs jours au même semaine avant d'avoir du feedback sur une régression, surtout sur des use cases très obscures, des choses que les gens ne font pas comme par exemple imprimées. Donc, puis aussi, il faut se demander est-ce que ça répond à un besoin primaire. Bien, pas de temps que ça au fait de faire des mises à jour plus rapides, à un moment donné, ça répond pas nécessairement aux besoins principaux de rendre l'application stable. Donc, comme j'ai expliqué plus tôt, la feedback loop est très, très importante et il y a un certain délai qui est inhérent à cette feedback loop. Donc, bien, au fait, quand je parle de la latence, je parle de la latence tu, alors il faut vraiment travailler fort pour réduire la latence dans toute l'infrastructure. Bien, qu'est-ce qu'on fait, par exemple, faire un check-out. Combien de temps ça prend faire un check-out, tu sais, l'an faire un check-out. Après ça, tout doit être exécuté en série, faire la compilation. Ensuite, bien, par exemple, on peut faire la distribution de compilation. Un des exemples, c'est d'ici, qui permet de faire de la distribution de compilation dans une forme, qui permet de diminuer le temps pour compiler un projet. L'idée ici, c'est qu'on essaie d'utiliser une approche philosophique spécifique pour s'assurer de réduire la latence entre... Pour savoir, au fait, c'est un comité bon ou mauvais. Alors, il vaut mieux prendre beaucoup de machines pendant un co-lapse de temps que prendre une machine longtemps. Par contre, utiliser beaucoup de machines simultanément mais de façon efficace est beaucoup plus difficile. Alors, bien, ce qu'on essaie de faire, c'est de faire la distribution des tests unitaires. En ce moment, on est en train d'atteindre une limite d'échelle que BuildBot peut fonctionner, parce que BuildBot, au fait, a une structure quand même assez lineée dans la façon que les builds fonctionnent à l'interne. Mais au fait, c'est un projet qu'on continue à utiliser beaucoup. Mais ça requiert quand même un petit peu plus de maintenance manuelle. Donc, ce qu'on essaie de faire, au fait, c'est qu'on essaie de décrire la dépendance au runtime, donc à l'exécution des tests. Et on appelle ça isoler les tests. Au fait, ce qu'on fait, c'est qu'on essaie de décrire... On décrit déjà dans le build system tout ce qui est nécessaire pour compiler un test. Pour maintenant, il faut décrire qu'est-ce qui est nécessaire pour le rouler. Et ce qui est nécessaire pour le rouler, c'est souvent des choses qui n'ont aucun rapport dans le build system, que par exemple des fichiers de tests, puis par exemple un browser test. On a un test qui va partir Chrome, donc l'exécutable. Là, on décrit les fichiers au runtime, mettant qu'on a un axe hier, qui est le liste des fichiers qu'on a de besoin au runtime. Par exemple, maintenant, on a un test qui load une charge d'une base de données qui n'auront pu, puis il vérifie que, même si la base de données n'auront pu, le process ne crash pas. Mettant que sur Android, il utilise une librairie spécifique Android, donc cette test-là n'existe pas, donc il faut créer un axe X qui est le système d'exploitation, et pour chacun des systèmes d'exploitation, la liste des fichiers nécessaires va être différente. Bon. Alors ensuite, on se dit, ben là, ça dépend, parce que quand on compile en debug, ben il y a des gens qui aiment bien ça rajouter de DBG, non d'exécutable. Alors des fois, il y a des non d'exécutables qui vont être différentes, dépendant du type de build qu'on fait. Alors on rajoute un axe Z qui va être aussi des modifications à la liste des fichiers de tests qui sont nécessaires pour rouler un test. Mais là, des fois, il y a des gens qui disent « ah, moi je veux compter 100 web RTC ou 100 NACL, native client ». Alors des fois, il y a des fichiers qui seront tout simplement pas là, donc on ne peut pas les lister. Donc on arrive dans une quatrième dimension qui va être encore des listes des fichiers différents, dépendants du type de build, dépendants du système d'exploitation. Donc essentiellement, on arrive dans une matrice d'exploitation qui faut réduire en plan pour avoir la liste des fichiers nécessaires. Donc, un cours d'âge obligatoire, c'est important. Donc, l'important ici, c'est d'être capable de réduire la matrice de toutes les possibilités possibles du nombre des fichiers nécessaires pour le type de test qu'on veut rouler, pour le type de système d'exploitation qu'on veut rouler, pour le type de build qu'on a fait. Deuxièmement, il faut que il y a de rouler les tests de façon faite, c'est qu'on peut rouler le test, mais il faut que le test ait aucun effet secondaire. Il ne faut pas qu'il dépendre qu'un autre test se roule avant. Il ne faut pas qu'il influence aucun test qui roule après. Il ne faut pas qu'il laisse aucune modification au système. Il faut qu'il soit capable de rouler sur des machines différentes. En plus, on force pour qu'on ait la capacité de rousser plusieurs tests qu'ils en même temps sur la même machine. Ça prend énormément de rigueur pour qu'on ait la capacité de rouler les tests. L'idée, c'est que si ce n'est pas imposé, ça n'arrivera jamais. Donc, il faut forcer les gens à coder des bons tests. Il ne sait pas que les gens sont nécessairement des mauvais cadards de tests. Ce qui s'est produit, c'est que ce n'est pas toujours évident qu'il va y avoir des interactions de test-case. Il faut vraiment s'assurer que tout l'infrastructure est extrêmement déterministe. On roule un test, on a un résultat qui est censément l'inverse d'avoir des tests flakies. Nous, ce qu'on utilise en ce moment, on est en train de commencer de l'utiliser, ça s'appelle Swarming au fait. C'est un projet qui roule en ce moment sur App Engine. Ce qui fait de la distribution de tâches. C'est très stateless. Une des raisons qu'on roule en ce moment sur App Engine, c'est que ça permet de passer en travers du GL, Global Interpreter Log de process à un côté de l'autre. Ce qu'on fait, c'est qu'on se réalise tout l'état de rouler des tests dans la base de données. Ça met énormément de pression sur la base de données. App Engine utilise Megastar. Il faut faire notre design d'entité, des tables en fonction des caractéristiques des performances de Megastar. Qui a déjà entendu parler de Megastar? Personne. Si vous avez le temps au fait, allez voir le site de BigChurch.google.com. Il parle de Bigtable Megastar Spanner. Si jamais vous avez entendu parler d'une base de données qui utilise des antennes GPS et une horloge atomique pour fonctionner, au fait, c'est Spanner. On a quand même des documents assez intéressants sur des méthodologies intéressantes de type de base de données. Je conseille de lire ça, mais c'est un peu à l'extérieur de mon commentaire pour une autre heure. Donc, ce qu'on fait, c'est que maintenant on a des tests qu'on peut rouler sur des machines arbitraires et on a des tests très jolis déterministes. Le problème, c'est qu'on a aussi, au fait, on a listé aussi toutes les fichiers qui sont nécessaires pour rouler un test. C'est beau, mais il faut aussi avoir un serveur de fichiers qui va contenir toutes ces tests-là. Il faut qu'il y ait l'air d'archiver ces tests-là et de pouvoir les faire très, très petits. Donc, ce qu'on fait, c'est qu'on utilise un Content Address Cache, c'est comme un jeu sur les Content Address Datastore. L'idée c'est que le contenu du fichier est le nom du fichier. Au fait, ce qu'on fait, c'est que le show-on du contenu du fichier et le nom du fichier, ça nous permet au fait, il y en existe beaucoup de Content Address Datastore, mais nous, on voulait vraiment une cache. Puis on voulait que le lookup soit à la fin de savoir si à peu près 10 000 fichiers sont présents ou pas présents sur le Datastore de façon extrêmement rapide. Donc, l'idée c'est qu'une fois qu'on a des données qui sont adressées par leur contenu, il y a une relation immuable entre le nom du fichier et son contenu. Alors, l'idée c'est qu'un bot qui va chercher les fichiers, qui est immable local pour pouvoir rouler son test, il peut garder un cache hit-rate sur les bottes. Donc, au fait, les bottes peuvent garder leurs fichiers puis ont un taux de succès d'à peu près de cache hit, d'à peu près 98 %. Donc, on peut pas changer le nom du fichier et ses contenus. Donc, l'idée au fait c'est que ça utilise une approche extrêmement fonctionnelle. Donc, les cours de programmation fonctionnel, c'est à ça que ça sert. Donc, l'idée au fait c'est qu'en à peu près de 98 %. Donc, on juste besoin d'aller chercher les fichiers qui ont effectivement été modifiés. Donc, ça réduit énormément la quantité de fichiers qui étaient déchargés. Ça roule à peine-t-il avec Cloud Storage, mais on est quand même assez... c'est juste parce que pour nous, c'était plus simple. Donc, on utilise beaucoup BillBot. BillBot est utilisé par plusieurs projets. Au fait, le maintainer principal de travail chez Mozia, BillBot est utilisé par WebKit, LLVM, Python, eux-mêmes, MongoDB. Donc, c'est quand même un projet quand même assez gros. Aussi, on utilise beaucoup RaidVel, qui est un système de code review. On utilise aussi GearIt, qui est un autre système de code review, parce que 1, c'est bien, mais 2, c'est mieux. Et on utilise aussi Swarming, qui est le projet sur lequel je travaille, qui sont aussi open source et en Python. Est-ce qu'il y a des questions rendies à ce point-ci? Au fait, GearIt a été inspiré de RaidVel, mais GearIt est codé en Java et RaidVel en Python. Donc, je n'appellerai pas ça un fort, parce qu'il n'utilise même pas le même langage. Aussi, la philosophie de développement est infinitivement différente. GearIt host c'est un serveur de code en même temps. C'est vraiment un SCM, c'est un serveur de Git, en plus d'être un outil de code review. Parce que RaidVel, c'est plus un outil de code review à doc. Donc, ici, au fait, on a beaucoup de codes, on a une grande équipe, on essaie de les faire avancer le plus vite possible. Bon, là, on essaie d'être une force, si on s'est entendu que les développeurs sont une masse. Je vous laisse ça à votre interprétation, mais l'idée est qu'on pourrait être une accélération négative. On veut être une force positive, évidemment. C'est un peu physique. Alors, l'idée, au fait, c'est qu'on utilise un peu les mêmes principes qui sont utilisés dans Chrome eux-mêmes, mais dans l'infrastructure de Chrome. Donc, par exemple, on utilise des canaux. On n'a pas besoin d'autant de canaux, parce que la feed back loop est très courte. Quand je brise quelque chose, en général, j'en entends parler assez vite. Donc, mais quand même, avoir l'infrastructure canaries, ça nous permet de faire des tests, pour que l'infrastructure survie. Ce qu'il faut, c'est qu'on n'a pas besoin de faire de opt-in avec les développeurs qui travaillent pour Google. On les surveille. Ça nous permet aussi de vérifier toutes les suppositions dans le code. C'est facile de tomber, par exemple, dans un profit d'utilisation un peu dégénératif par rapport à la base donnée, par exemple, ou la façon qu'on sort les pages web. Donc, ça pourrait causer d'horribles performances. Donc, on essaie d'avoir un code et un test d'une taille, vous ne le dira pas. Donc, il faut vraiment comme tester. Et aussi, on essaie d'avoir le code qui est assez résidiant à des erreurs d'infrastructure, par exemple, si la base donnée est maire, ou est partially available, ou par exemple, des problèmes de connexion de réseau, on essaie de survivre ces problèmes-là. Donc, l'idée, au fait, c'est qu'on essaie d'avoir des petits services qui rendent plus simple à travailler dessus et moins de processus. Avec des API très focussés, c'est plus simple à comprendre. Les services plus simples sont plus faciles à tester. Donc, on fait une tâche, on la fait bien. Donc, vraiment, l'idée de base, c'est que moins de process plus de services. Et les services, au fait, ce qui est intéressant, c'est vu que c'est souvent des services web, ça force à avoir le control flow explicite dans la base de données. Ça, c'est un très, très grand avantage. Ce qu'on essaie, c'est d'être très agide. Donc, on essaie aussi de décrire comment le code peut se tester lui-même. C'est quelque chose qui est en ce moment un Work and Progress. Où est-ce que le code peut décrire exactement le nombre de tests qu'il faut rouler et sur quelle plateforme et comment le rouler. L'idée, au fait, c'est de pouvoir faire des changements plus focussés et réduire les effets secondaires. Où est-ce qu'il faut faire un changement où, par exemple, on rajoute un test, puis là, il faut faire le changement d'infrastructure en même temps et s'incroniser de tout. Ça devient un peu compliqué. Donc, l'idée, au fait, c'est de réduire et faire des changements de script parce qu'on n'est pas très pratiquants. Donc, l'idée, au fait, c'est qu'on utilise beaucoup App Engine entre autres pour ça. Ça nous permet de... Une des choses qu'on aime beaucoup avec App Engine, c'est que ça nous permet de rouler plusieurs versions de notre serveur en même temps. Puis, de pouvoir tester les différences entre eux. C'est un avantage vraiment extrêmement élevé. J'ai jamais eu le recours, mais c'est un peu le même genre. Ça permet d'enlever des bases données. Tant qu'on a des bases données en bas d'un thérabyte, en général, t'as une machine, puis ça va aller. Mais quand on dépasse quelques thérabytes, en général, ça devient un petit peu plus compliqué. Il faut vraiment faire un formes de base données. En théorie, il y a une équipe de SRI, dont des sites Reelability Engineers qui travaillent pour nous. Puis aussi, ça permet de garder quand même un certain uptime. C'est pas sans pépin, mais ça fait quand même la job. Puis, comme je disais tantôt, ça permet de vraiment de rouler plusieurs versions simultanément. Ça permet aussi de faire horizontal scaling. Ça veut dire que pouvoir partir plusieurs services web simultanément. Puis le engine, le fait pour nous, donc on n'a pas besoin de commencer à partir de nouveaux serveurs à chaque fois qu'il y a un peu plus de l'autre. On utilise beaucoup Compute Engine qui est maintenant disponible à l'extrême. Au fond, c'est un peu la même chose que ici et tout pour ceux qui préfèrent Amazon. Donc, l'idée de base c'est d'avoir des VMs sur demande. Ça aide beaucoup de grosser l'infrastructure. Donc, au fait, on a un masque de solution open source. Puis comme j'ai, par exemple, BitBot, un autre exemple, c'est Jenkins. So they called review by ReviewedBold. Board est aussi un autre exemple. Donc, il y a quand même beaucoup, beaucoup de solutions. A chacun des types de besoin, il y a beaucoup de solutions qui sont open source qui peuvent être utilisées. L'idée au fait qu'on fait une infrastructure, c'est d'avoir une feedback loop. C'est très important. Puis aussi d'avoir une infrastructure de cannerie qui commence à rentrer à grande échelle ou est-ce qu'il y a des gens qui travaillent en continu ça devient indispensable. Est-ce qu'il y a des gens qui ont des questions sur l'infrastructure? Non. Ok, c'est bon. Alors, au fait, c'est ce qui conclut ma présentation. Donc, j'espère que vous avez bien apprécié ça. Ce qui est le fun, au fait, c'est que vu qu'on travaille beaucoup en open source, la plupart des choses sont disponibles à l'extrême. Par exemple, les codes review sont toutes sur un mailing list. Les check-in aussi, on est sur l'IRC. On est quand même facile à accéder. Donc, c'est tout. Merci.