Chaque année, des milliards d'utilisateurs interagissent avec les produits et services Google. Les offres clés telles que la Recherche, Gmail, Maps, YouTube, Chrome et désormais Google Cloud sont si bien intégrées à la vie moderne qu'elles contribuent à définir l'expérience du XXIe siècle. Cet impact planétaire est le résultat de la qualité éprouvée de nos offres et de l'attente que Google soit toujours disponible.
Chez Google Cloud, nous apportons en permanence des modifications de code à nos produits et services pour garantir la meilleure expérience utilisateur possible, améliorer la sécurité et la fiabilité, et respecter les exigences réglementaires et de conformité. Tout changement de ce type, qu'il soit important ou non, peut parfois entraîner des problèmes. Pour réduire ce risque, nous accordons la priorité à la sécurité des modifications tout au long de leur cycle de vie.
Ce document explique comment les équipes Google Cloud s'appuient sur les décennies d'investissement de Google dans l'excellence du développement pour mettre en œuvre des bonnes pratiques et des normes techniques en matière de fiabilité qui répondent aux attentes des clients Google Cloud en termes de vitesse et de fiabilité du développement.
Cycle de vie d'une modification chez Google Cloud
Les équipes produit Google Cloud partagent une grande partie du processus de gestion et des outils avec d'autres équipes d'ingénieurs de Google. Nous mettons en œuvre une approche standard de développement logiciel pour la gestion des modifications qui donne la priorité à l'intégration continue (CI) et à la livraison continue (CD). La CI implique souvent de proposer, de tester et d'envoyer des modifications, souvent plusieurs fois par jour pour un produit ou un service donné. La CD est une extension de la CI dans laquelle les ingénieurs préparent en continu des versions candidates en fonction du dernier instantané stable d'un codebase.
Cette approche consiste à créer et à déployer les modifications par étapes auprès des clients Google Cloud dès que possible, mais aussi de la manière la plus sécurisée possible. Nous prenons en compte la sécurité des modifications avant d'écrire du code, et nous continuons à nous concentrer sur la sécurité même après le déploiement des modifications en production. Notre modèle de gestion du changement comporte quatre phases générales : conception, développement, qualification et déploiement. Ces quatre phases sont illustrées dans le schéma suivant et sont détaillées dans la suite de ce document :
Conception sécurisée
Nous savons que même de petites erreurs au début du processus de développement peuvent entraîner de gros problèmes plus tard, qui auront un impact important sur l'expérience client. Par conséquent, nous exigeons que toutes les modifications majeures soient précédées d'un document de conception approuvé. Nous disposons d'un modèle de document de conception commun permettant aux équipes d'ingénieurs de proposer des modifications majeures. Ce document de conception commun nous permet d'évaluer de manière cohérente les modifications majeures apportées aux produits Google Cloud. Le schéma suivant illustre notre processus de conception standard pour un changement majeur :
La phase de conception commence lorsqu'un développeur logiciel propose une modification qui répond aux exigences métier, techniques, de coût et de maintenance. Une fois la modification envoyée, un processus d'examen et d'approbation complet est lancé avec des experts seniors, y compris des experts en fiabilité et en sécurité, ainsi que des responsables techniques. L'implémentation de la modification ne peut commencer qu'après que l'ingénieur qui a proposé la conception a pris en compte tous les commentaires des experts et que chaque expert a approuvé la conception. Ce processus de conception et d'examen réduit la probabilité que les équipes produit Google Cloud commencent à travailler sur des modifications susceptibles d'avoir un impact négatif sur les clients en production.
Sûr tel que développé
Notre processus de développement de code améliore la qualité et la fiabilité de notre code. Une fois la modification proposée approuvée, le processus de développement commence par une intégration complète des nouveaux ingénieurs, y compris une formation, un mentorat et des commentaires détaillés sur les modifications de code proposées. Une approche de développement et de test en plusieurs couches avec des tests manuels et automatisés permet de valider le code à chaque étape du développement. Chaque modification de code est examinée de manière approfondie pour s'assurer qu'elle répond aux normes élevées de Google.
Le schéma suivant montre un workflow qui illustre approximativement notre processus de développement :
La phase de développement commence lorsqu'un ingénieur commence à écrire du code et à effectuer les tests unitaires et d'intégration correspondants. Au cours de cette phase, l'ingénieur peut exécuter les tests qu'il a écrits et une suite de tests de pré-envoi pour s'assurer que les ajouts et les modifications de code sont valides. Une fois les modifications de code terminées et les tests effectués, l'ingénieur demande à une autre personne qui connaît le code de procéder à un examen manuel. Ce processus d'examen manuel est souvent itératif et peut entraîner des révisions de code supplémentaires. Lorsque l'auteur et l'examinateur parviennent à un consensus, l'auteur envoie le code.
Les normes de codage garantissent des modifications de haute qualité
La culture, les pratiques et les outils d'ingénierie de Google sont conçus pour garantir que notre code est correct, clair, concis et efficace. Le développement de code chez Google a lieu dans notre monorepo, le plus grand dépôt de code intégré au monde. Le monorepo contient des millions de fichiers sources, des milliards de lignes de code et un historique de centaines de millions de commits appelés "listes de modifications". Il continue de croître rapidement, avec des dizaines de milliers de nouvelles listes de modifications ajoutées chaque jour ouvré. Entre autres avantages, le monorepo facilite la réutilisation du code, simplifie la gestion des dépendances et impose l'application de workflows de développement cohérents sur les produits et services.
La réutilisation du code est utile, car nous avons déjà une bonne idée des performances du code réutilisé en production. En exploitant le code de haute qualité qui existe déjà, les modifications sont intrinsèquement plus robustes et plus faciles à gérer selon la norme requise. Cette pratique permet non seulement de gagner en temps et efforts, mais aussi de garantir la santé globale du codebase, ce qui permet d'obtenir des produits plus fiables.
Les services Google Cloud qui reposent sur des logiciels Open Source de haute qualité peuvent compléter le monorepo avec un autre dépôt, généralement Git, pour utiliser la ramification afin de gérer le logiciel Open Source.
Remarque concernant la formation
L'investissement dans la qualité du code commence lorsqu'un ingénieur rejoint une équipe. Si l'ingénieur est nouveau chez Google ou s'il connaît moins bien l'infrastructure et l'architecture de l'équipe, il suit un processus d'intégration complet. Dans le cadre de cette intégration, il étudie les guides de style, les bonnes pratiques et les guides de développement, et effectue manuellement des exercices pratiques. De plus, les nouveaux ingénieurs doivent obtenir un niveau d'approbation supplémentaire pour chaque envoi de liste de modifications. Les ingénieurs qui ont obtenu l'approbation pour apporter des modifications à un langage de programmation donné ont satisfait à un ensemble rigoureux d'attentes basées sur leur expertise et ont démontré leur capacité à rendre le code lisible dans ce langage de programmation. Tout ingénieur peut obtenir une certification de lisibilité pour un langage de programmation. La plupart des équipes ont plusieurs approbateurs pour les langages de programmation dans lesquels elles codent.
Le principe Shift Left améliore la vitesse en toute sécurité
Le principe du "Shift left" consiste à effectuer les tests et la validation plus tôt dans le processus de développement. Ce principe repose sur notre observation selon laquelle les coûts augmentent considérablement lorsque nous détectons et corrigeons un bug tardivement dans le processus de publication. Dans un cas extrême, imaginons qu'un client découvre un bug en production. Ce bug peut avoir un impact négatif sur les charges de travail et les applications du client. Il se peut également que le client doive suivre le processus Customer Care de Google Cloud avant que l'équipe d'ingénieurs concernée puisse atténuer le bug. Si l'ingénieur chargé de résoudre le problème n'est pas celui qui a introduit la modification contenant le bug, il devra se familiariser avec les modifications du code, ce qui augmentera probablement le temps nécessaire pour reproduire et éventuellement corriger le bug. L'ensemble de ce processus demande beaucoup de temps aux clients et à l'assistance Google Cloud, et exige que les ingénieurs abandonnent ce sur quoi ils travaillent pour résoudre un problème.
À l'inverse, imaginons qu'un bug soit détecté par un test automatisé alors qu'un ingénieur travaille sur une modification en cours de développement. Lorsque l'ingénieur constate l'échec du test, il peut le corriger immédiatement. En raison de nos normes de codage, l'ingénieur ne pourrait même pas envoyer la modification en cas d'échec du test. Cette détection précoce permet à l'ingénieur de corriger le bug sans impact pour le client et sans frais de changement de contexte.
Ce dernier scénario est infiniment préférable pour toutes les parties concernées. Par conséquent, au fil des ans, Google Cloud a massivement investi dans ce principe Shift Left, en déplaçant les tests traditionnellement effectués lors des phases de qualification et de déploiement des modifications directement dans la boucle de développement. Aujourd'hui, tous les tests unitaires, tous les tests d'intégration, sauf les plus importants, et les analyses statiques et dynamiques approfondies sont effectués en parallèle pendant qu'un ingénieur propose des modifications de code.
Les tests de préenvoi automatisés appliquent les normes de codage
Les tests de pré-envoi sont des vérifications qui s'exécutent avant que des modifications soient envoyées dans un répertoire donné. Les tests de pré-envoi peuvent être des tests unitaires et d'intégration spécifiques à une modification, ou des tests généraux (par exemple, analyse statique et dynamique) qui s'exécutent pour toute modification. Traditionnellement, les tests de pré-envoi s'exécutaient en toute dernière étape avant qu'une personne ne modifie un codebase. Aujourd'hui, en partie grâce au principe du Shift Left et à notre implémentation de la CI, nous exécutons des tests de pré-envoi de manière continue pendant qu'un ingénieur modifie le code dans un environnement de développement et avant de fusionner les modifications dans notre monorepo. Un ingénieur peut également exécuter manuellement une suite de tests de pré-envoi en un seul clic dans l'interface utilisateur de développement. Chaque test de pré-envoi s'exécute automatiquement pour chaque liste de modifications avant un examen manuel du code.
La suite de tests de pré-envoi couvre généralement les tests unitaires, les tests fuzz (à données aléatoires), les tests d'intégration hermétique, ainsi que l'analyse statique et dynamique du code. Pour les modifications apportées aux bibliothèques principales ou au code largement utilisé dans Google, les développeurs exécutent un pré-envoi global. Un préenvoi global teste la modification par rapport à l'intégralité du codebase Google, ce qui réduit le risque qu'une modification proposée ait un impact négatif sur d'autres projets ou systèmes.
Tests unitaires et d'intégration
Les tests approfondis font partie intégrante du processus de développement du code. Tout le monde est tenu d'écrire des tests unitaires pour les modifications de code, et nous suivons en permanence la couverture du code au niveau du projet pour nous assurer que nous validons le comportement attendu. De plus, nous exigeons que tout parcours utilisateur critique fasse l'objet de tests d'intégration permettant de valider le fonctionnement de tous les composants et dépendances nécessaires.
Les tests unitaires et tous les tests d'intégration, à l'exception des plus importants, sont conçus pour être effectués rapidement. Ils sont exécutés de manière incrémentielle avec un parallélisme élevé dans un environnement distribué, ce qui permet d'obtenir des commentaires rapides et continus sur le développement automatisé.
Fuzzing (tests à données aléatoires)
Alors que les tests unitaires et d'intégration nous aident à valider le comportement attendu avec des entrées et des sorties prédéterminées, le fuzzing est une technique qui bombarde une application avec des entrées aléatoires, dans le but de détecter des failles ou des faiblesses cachées qui pourraient entraîner des failles de sécurité ou des plantages. Le fuzzing nous permet d'identifier et de corriger de manière proactive les faiblesses potentielles de nos logiciels, ce qui améliore la sécurité et la fiabilité globales de nos produits avant que les clients n'interagissent avec les modifications. Le caractère aléatoire de ces tests est particulièrement utile, car les utilisateurs interagissent parfois avec nos produits de manière intéressante et inattendue. Le fuzzing nous aide à prendre en compte des scénarios que nous n'avons pas pris en compte manuellement.
Analyse statique
Les outils d'analyse statique jouent un rôle essentiel dans le maintien de la qualité du code dans nos workflows de développement. L'analyse statique a considérablement évolué depuis ses débuts avec l'analyse lint et les expressions régulières pour identifier les modèles de code C++ problématiques. Aujourd'hui, l'analyse statique couvre tous les langages de production Google Cloud et détecte les modèles de code erronés, inefficaces ou obsolètes.
Grâce aux interfaces de compilation avancées et aux LLM, nous pouvons proposer automatiquement des améliorations pendant que les ingénieurs écrivent du code. Chaque modification de code proposée est examinée à l'aide d'analyses statiques. Au fil du temps, nous ajoutons de nouvelles vérifications statiques. L'ensemble du codebase est constamment analysé pour vérifier la conformité, et les correctifs sont automatiquement générés et envoyés pour examen.
Analyse dynamique
Alors que l'analyse statique vise à identifier les modèles de code connus qui peuvent entraîner des problèmes, l'analyse dynamique adopte une approche différente. Il s'agit de compiler et d'exécuter du code pour détecter les problèmes qui ne se manifestent que lors de l'exécution, comme les problèmes de mémoire et les conditions de concurrence. Google a une longue expérience de l'utilisation de l'analyse dynamique et a même partagé plusieurs de ses outils avec la communauté des développeurs, y compris les suivants :
- AddressSanitizer : détecte les erreurs de mémoire telles que les dépassements de mémoire tampon et les utilisations après libération.
- ThreadSanitizer (C++, Go) : détecte les conflits de données et d'autres bugs de threading.
- MemorySanitizer : détecte l'utilisation de mémoire non initialisée
Ces outils et d'autres de ce type sont essentiels pour détecter les bugs complexes qui ne peuvent pas être détectés par une analyse statique. En utilisant à la fois l'analyse statique et l'analyse dynamique, Google s'efforce de s'assurer que son code est bien structuré, qu'il ne présente pas de problèmes connus et qu'il se comporte comme prévu dans des scénarios réels.
Les revues de code par des humains valident les modifications et les résultats des tests
Lorsqu'un ingénieur atteint un jalon critique dans son code et souhaite l'intégrer au dépôt principal, il lance un examen du code en proposant une liste de modifications. Une demande d'examen de code comprend les éléments suivants :
- Une description qui décrit l'objectif des modifications et tout contexte supplémentaire
- Code modifié
- Tests unitaires et tests d'intégration pour le code modifié
- Résultats des tests de pré-envoi automatisés
C'est à ce stade du processus de développement qu'intervient un autre humain. Un ou plusieurs examinateurs désignés examinent attentivement la liste des modifications pour vérifier son exactitude et sa clarté, en utilisant les tests joints et les résultats de pré-envoi comme guide. Chaque répertoire de code dispose d'un ensemble d'examinateurs désignés chargés de garantir la qualité de ce sous-ensemble du codebase, et dont l'approbation est nécessaire pour apporter des modifications dans ce répertoire. Les examinateurs et les ingénieurs collaborent pour détecter et résoudre les problèmes qui peuvent survenir avec une modification de code proposée. Lorsque la liste de modifications respecte nos normes, un examinateur donne son approbation ("LGTM", abréviation de "looks good to me", "cela me semble correct"). Toutefois, si l'ingénieur est encore en formation pour le langage de programmation utilisé, il doit obtenir l'approbation d'un expert qui a obtenu la certification de lisibilité dans ce langage.
Une fois qu'une liste de modifications a réussi les tests et les vérifications automatisées, et qu'elle a reçu un LGTM, l'ingénieur qui a proposé la modification n'est autorisé à apporter que des modifications minimes au code. Toute modification importante annule l'approbation et nécessite un nouvel examen. Même les petites modifications sont automatiquement signalées aux examinateurs d'origine. Une fois que l'ingénieur a envoyé le code finalisé, il passe par un autre cycle complet de tests avant envoi avant que la liste de modifications ne soit fusionnée dans le monorepo. Si un test échoue, l'envoi est refusé, et le développeur et les examinateurs reçoivent une alerte les invitant à prendre des mesures correctives avant d'envoyer à nouveau les modifications.
Qualification de version sécurisée
Bien que les tests de pré-envoi soient complets, ils ne constituent pas la fin du processus de test chez Google. Les équipes effectuent souvent des tests supplémentaires, tels que des tests d'intégration à grande échelle, qui ne peuvent pas être exécutés lors de l'examen initial du code (ils peuvent prendre plus de temps à s'exécuter ou nécessiter des environnements de test haute fidélité). De plus, les équipes doivent être conscientes des échecs causés par des facteurs indépendants de leur volonté, comme les modifications des dépendances externes.
C'est pourquoi Google exige une phase de qualification après la phase de développement. Cette phase de qualification utilise un processus de compilation et de test continu, comme illustré dans le schéma suivant :
Ce processus exécute régulièrement des tests pour tout le code affecté par des modifications directes ou indirectes depuis la dernière exécution. Tout échec est automatiquement transmis à l'équipe d'ingénieurs responsable. Dans de nombreux cas, le système est capable d'identifier automatiquement la liste de modifications à l'origine du problème et de la restaurer. Ces tests d'intégration à grande échelle sont exécutés dans un spectre d'environnements de préproduction allant d'environnements partiellement simulés à des emplacements physiques entiers.
Les tests ont différents objectifs de qualification, allant de la fiabilité et de la sécurité de base à la logique métier. Ces tests de qualification incluent le test du code pour les éléments suivants :
- La capacité à fournir les fonctionnalités requises, testée à l'aide de tests d'intégration à grande échelle
- La capacité à répondre aux exigences de l'entreprise, testée avec des représentations synthétiques des charges de travail des clients
- La capacité à gérer les défaillances de l'infrastructure sous-jacente, testée en injectant des défaillances dans la pile
- La capacité à maintenir la capacité de diffusion, testée avec des frameworks de test de charge
- La possibilité de revenir en arrière en toute sécurité
Déploiements sécurisés
Même avec les processus de développement, de test et de qualification les plus rigoureux, des défauts peuvent parfois se glisser dans les environnements de production et avoir un impact négatif sur nos utilisateurs. Dans cette section, nous expliquons comment le processus de déploiement Google Cloud limite l'impact des modifications défectueuses et permet de détecter rapidement les régressions. Nous appliquons cette approche à tous les types de modifications déployées en production, y compris les binaires, les configurations, les mises à jour de schémas, les modifications de capacité et les listes de contrôle d'accès.
Modifier la propagation et la supervision
Nous appliquons une approche cohérente pour déployer les modifications dans Google Cloud afin de minimiser les impacts négatifs pour les clients et d'isoler les problèmes dans des domaines de défaillance logiques et physiques individuels. Ce processus s'appuie sur nos pratiques de fiabilité SRE qui ont fait leurs preuves depuis des décennies, et sur notre système de surveillance à l'échelle planétaire pour détecter et atténuer les mauvais changements le plus rapidement possible. La détection rapide nous permet d'avertir les clients plus rapidement et de prendre des mesures correctives pour éviter systématiquement que des échecs similaires ne se reproduisent.
La plupart des produits Google Cloud sont régionaux ou zonaux. Cela signifie qu'un produit régional exécuté dans la région A est indépendant du même produit exécuté dans la région B. De même, un produit zonal exécuté dans la zone C de la région A est indépendant du même produit zonal exécuté dans la zone D de la région A. Cette architecture minimise le risque d'une panne affectant d'autres régions ou d'autres zones d'une même région. Certains services, comme IAM ou la console Google Cloud, fournissent une couche cohérente à l'échelle mondiale couvrant toutes les régions. C'est pourquoi nous les appelons des services mondiaux. Les services mondiaux sont répliqués dans plusieurs régions pour éviter les points de défaillance uniques et minimiser la latence. La plate-forme de déploiement Google Cloud partagée sait si un service est zonal, régional ou mondial, et orchestre les modifications de production en conséquence.
Le processus de déploiement Google Cloud divise toutes les instances répliquées d'un service déployé sur plusieurs emplacements cibles en vagues. Les vagues initiales incluent un petit nombre d'instances répliquées, les mises à jour se produisant de manière séquentielle. Les vagues initiales équilibrent la protection de la plupart des charges de travail des clients et la maximisation de l'exposition à la diversité des charges de travail afin de détecter les problèmes le plus tôt possible. Elles incluent des charges de travail synthétiques qui imitent les modèles de charges de travail courants des clients.
Si le déploiement aboutit à mesure que les instances répliquées de service sont mises à jour dans les emplacements cibles, les vagues de déploiement suivantes augmentent progressivement en taille et introduisent davantage de parallélisme. Bien qu'un certain parallélisme soit nécessaire pour tenir compte du nombre d'emplacements Google Cloud, nous n'autorisons pas les mises à jour simultanées vers des emplacements appartenant à des vagues différentes. Si une vague se poursuit pendant la nuit ou un week-end, elle peut terminer sa progression, mais aucune nouvelle vague ne peut commencer avant le début des heures ouvrées de l'équipe qui gère le déploiement.
Le schéma suivant est un exemple de workflow illustrant la logique de déploiement que nous utilisons dans Google Cloud pour les produits et services régionaux :
Le processus de déploiement Google Cloud utilise le service d'analyse Canary (CAS) pour automatiser les tests A/B pendant toute la durée du déploiement. Certaines instances répliquées deviennent des canaris (c'est-à-dire un déploiement partiel et limité dans le temps d'une modification dans un service), et les instances répliquées restantes constituent le groupe de contrôle qui n'inclut pas la modification. Chaque étape du processus de déploiement dispose d'un temps de préparation pour détecter les problèmes lents avant de passer à l'étape suivante. Cela permet de s'assurer que toutes les fonctionnalités d'un service sont bien utilisées et que les anomalies potentielles sont détectées par le CAS. Le temps de traitement est soigneusement défini pour équilibrer la détection des problèmes à évolution lente avec la vitesse de développement. Les déploiements Google Cloud prennent généralement une semaine.
Ce schéma offre un aperçu rapide du workflow CAS :
Le workflow commence par l'outil de déploiement qui déploie la modification sur l'instance répliquée canari. L'outil de déploiement demande ensuite un verdict au CAS. Le CAS évalue l'instance répliquée canari par rapport au groupe de contrôle et renvoie un verdict SUCCÈS ou ÉCHEC. Si un signal d'intégrité échoue, une alerte est générée pour les propriétaires de services, et l'étape en cours de déploiement est suspendue ou annulée. Si le changement entraîne une interruption de service pour les clients externes, un incident externe est déclaré et les clients concernés sont avertis via le service Personalized Service Health. Les incidents déclenchent également un examen interne. La philosophie post mortem de Google permet d'identifier et d'appliquer le bon ensemble d'actions correctives afin de réduire la probabilité de nouvelles défaillances similaires.
Surveillance des signaux et sécurité après déploiement
Les défauts logiciels ne se manifestent pas toujours instantanément, et certains peuvent nécessiter des circonstances spécifiques pour se déclencher. C'est pourquoi nous continuons à surveiller les systèmes de production une fois le déploiement terminé. Au fil des ans, nous avons constaté que même si un déploiement ne déclenche pas de problème immédiatement, il reste le principal responsable d'un incident de production. C'est pourquoi nos playbooks de production indiquent aux intervenants en cas d'incident de corréler les déploiements récents avec les problèmes observés et de procéder par défaut à un rollback d'un déploiement récent si les intervenants en cas d'incident ne peuvent pas exclure que les modifications récentes soient à l'origine de l'incident.
La surveillance après le déploiement repose sur le même ensemble de signaux de surveillance que nous utilisons pour les analyses A/B automatisées pendant une période de déploiement. La philosophie de surveillance et d'alerte de Google Cloud combine deux types de surveillance : introspective (également appelée "boîte blanche") et synthétique (également appelée "boîte noire"). La surveillance introspective utilise des métriques telles que l'utilisation du processeur, l'utilisation de la mémoire et d'autres données de service internes. La surveillance synthétique examine le comportement du système du point de vue du client, en suivant les taux d'erreur du service et les réponses au trafic synthétique des services vérificateurs. La surveillance synthétique est axée sur les symptômes et identifie les problèmes actifs, tandis que la surveillance introspective nous permet de diagnostiquer les problèmes confirmés et, dans certains cas, d'identifier les problèmes imminents.
Pour faciliter la détection des incidents qui n'affectent que certains clients, nous regroupons les charges de travail des clients en cohortes de charges de travail associées. Les alertes se déclenchent dès que les performances d'une cohorte s'écartent de la norme. Ces alertes nous permettent de détecter les régressions spécifiques à un client, même si les performances globales semblent normales.
Protection de la chaîne d'approvisionnement logicielle
Chaque fois que les équipes Google Cloud apportent des modifications, nous utilisons un contrôle de sécurité appelé Autorisation binaire pour Borg (BAB) afin de protéger notre chaîne d'approvisionnement logicielle et nos clients Cloud contre les risques internes. L'autorisation binaire pour Borg commence à l'étape de l'examen du code et crée une piste d'audit du code et de la configuration déployés en production. Pour garantir l'intégrité de la production, BAB n'accepte que les modifications qui répondent aux critères suivants :
- Sont inviolables et signées
- Proviennent d'un groupe de compilation et d'un emplacement source identifiés
- Ont été examinées et approuvées explicitement par une partie distincte de l'auteur du code
Si vous souhaitez appliquer certains de ces concepts dans votre propre cycle de développement logiciel, nous avons inclus les principaux concepts de BAB dans une spécification ouverte appelée Supply-chain Levels for Software Artifacts (SLSA). SLSA agit comme un framework de sécurité pour le développement et l'exécution de code dans les environnements de production.
Conclusion
Google Cloud s'appuie sur des décennies d'investissements de Google dans l'excellence du développement. La santé du code et la santé de la production sont des principes culturels inculqués à toutes les équipes d'ingénieurs de Google. Notre processus d'examen dès la conception garantit que les implications sur le code et la santé de la production sont prises en compte dès le début. Notre processus de développement, basé sur le principe du Shift Left et sur des tests approfondis, garantit que les idées de conception sont implémentées de manière sûre et correcte. Notre processus de qualification étend les tests pour couvrir les intégrations à grande échelle et les dépendances externes. Enfin, notre plate-forme de déploiement nous permet de nous assurer progressivement qu'une modification donnée se comporte comme prévu. Notre approche, qui s'étend de la conception à la production, nous permet de répondre aux attentes des clients Google Cloud en termes de vitesse de développement et de fiabilité.