Cada año, miles de millones de usuarios interactúan con los productos y servicios de Google. Las ofertas clave, como Búsqueda, Gmail, Maps, YouTube, Chrome y, ahora también, Google Cloud, se integran tan bien en la vida moderna que ayudan a definir la experiencia del siglo XXI. Este impacto a nivel mundial es el resultado de la calidad comprobada de nuestras ofertas y de la expectativa de que Google siempre esté disponible.
En Google Cloud, implementamos cambios de código de forma continua en nuestros productos y servicios para garantizar que brindemos la mejor experiencia del usuario posible, mejoremos la seguridad y la confiabilidad, y cumplamos con los requisitos regulatorios y de cumplimiento. Cualquier cambio de este tipo, por más grande o pequeño que sea, puede provocar errores. Para abordar ese riesgo, priorizamos la seguridad de los cambios durante todo el ciclo de vida de un cambio.
En este documento, se explica cómo los equipos de Google Cloud se basan en las décadas de inversión de Google en la excelencia del desarrollo para implementar prácticas recomendadas de confiabilidad y estándares de ingeniería que cumplan con las expectativas de los clientes de Google Cloud en cuanto a la velocidad y confiabilidad del desarrollo.
El ciclo de vida de un cambio en Google Cloud
Los equipos de productos de Google Cloud comparten gran parte del proceso de administración y las herramientas con otros equipos de ingeniería de Google. Implementamos un enfoque de desarrollo de software estándar para la administración de cambios que prioriza la integración continua (IC) y la entrega continua (CD). La CI incluye proponer, probar y enviar cambios con frecuencia, a menudo varias veces al día para cualquier producto o servicio determinado. La CD es una extensión de la CI en la que los ingenieros preparan continuamente versiones candidatas en función de la instantánea estable más reciente de una base de código.
Este enfoque prioriza la creación y el lanzamiento de cambios en etapas para los clientes de Google Cloud lo antes posible, pero también de la forma más segura posible. Consideramos la seguridad de los cambios antes de escribir cualquier código y seguimos enfocándonos en la seguridad incluso después de lanzar los cambios en producción. Existen cuatro fases generales en nuestro modelo de administración de cambios: diseño, desarrollo, calificación y lanzamiento. Estas cuatro fases se muestran en el siguiente diagrama y se analizan con más detalle en este documento:
Diseño de seguridad integral
Reconocemos que incluso los errores pequeños al principio del proceso de desarrollo pueden causar grandes problemas más adelante que afectan significativamente las experiencias de los clientes. Como resultado, requerimos que todos los cambios importantes comiencen con un documento de diseño aprobado. Tenemos una plantilla común de documentos de diseño para que los equipos de ingeniería propongan cambios importantes. Este documento de diseño común nos ayuda a evaluar los cambios importantes en todos los productos de Google Cloud de manera coherente. En el siguiente diagrama, se muestra cómo se ve nuestro proceso de diseño estándar para un cambio importante:
La fase de diseño comienza cuando un desarrollador de software propone un cambio que aborde los requisitos empresariales, técnicos, de costos y de mantenimiento. Después de enviar ese cambio, se inicia un proceso de revisión y aprobación integral con expertos sénior, incluidos expertos en confiabilidad y seguridad, y líderes técnicos. El trabajo para implementar el cambio solo puede continuar después de que el ingeniero que propuso el diseño aborde todos los comentarios de los expertos y cada experto apruebe el diseño. Este proceso de diseño y revisión reduce la probabilidad de que los equipos de productos de Google Cloud comiencen a trabajar en cambios que podrían afectar negativamente a los clientes en producción.
Seguridad durante el desarrollo
Nuestro proceso de desarrollo de código aumenta la calidad y la confiabilidad de nuestro código. Después de la aprobación de un cambio propuesto, el proceso de desarrollo comienza con una integración integral para los ingenieros nuevos, que incluye capacitación, orientación y comentarios detallados sobre los cambios de código propuestos. Un enfoque de desarrollo y pruebas de varias capas con pruebas manuales y automatizadas valida el código de forma continua en cada etapa del desarrollo. Cada cambio de código se revisa en detalle para garantizar que cumpla con los altos estándares de Google.
En el siguiente diagrama, se proporciona un flujo de trabajo que ilustra aproximadamente cómo se ve nuestro proceso de desarrollo:
La fase de desarrollo comienza cuando un ingeniero comienza a escribir código y las pruebas de integración y unidad correspondientes. Durante esta fase, el ingeniero puede ejecutar las pruebas que escribió y un conjunto de pruebas previas al envío para asegurarse de que las incorporaciones y los cambios de código sean válidos. Después de finalizar los cambios de código y ejecutar pruebas, el ingeniero solicita una revisión manual de otra persona que esté familiarizada con el código. Este proceso de revisión manual suele ser iterativo y puede generar revisiones de código adicionales. Cuando el autor y el revisor llegan a un consenso, el autor envía el código.
Los estándares de programación garantizan cambios de alta calidad
La cultura, las prácticas y las herramientas de ingeniería de Google están diseñadas para garantizar que nuestro código sea correcto, claro, conciso y eficiente. El desarrollo de código en Google se realiza en nuestro monorepo, el repositorio de código integrado más grande del mundo. El monorepo aloja millones de archivos fuente, miles de millones de líneas de código y tiene un historial de cientos de millones de confirmaciones llamadas listas de cambios. Continúa creciendo rápidamente, con decenas de miles de listas de cambios nuevas que se agregan todos los días laborales. Los beneficios clave del monorepo son que facilita la reutilización de código, simplifica la administración de dependencias y aplica flujos de trabajo coherentes para los desarrolladores en todos los productos y servicios.
La reutilización de código es útil porque ya tenemos una buena idea de cómo se comporta el código reutilizado en producción. Cuando se aprovecha el código de alta calidad que ya existe, los cambios son, de forma inherente, más sólidos y fáciles de mantener con el estándar requerido. Esta práctica no solo ahorra tiempo y esfuerzo, sino que también garantiza que el estado general de la base de código siga siendo alto, lo que genera productos más confiables.
Los servicios de Google Cloud que se compilan en software de código abierto de alta calidad pueden complementar el monorepo con otro repositorio, por lo general, Git, para usar la ramificación y administrar el software de código abierto.
Nota sobre la capacitación
La inversión en la calidad del código comienza cuando un ingeniero se une a un equipo. Si el ingeniero es nuevo en Google o no está tan familiarizado con la infraestructura y la arquitectura del equipo, realiza una integración extensa. Como parte de esta integración, estudian guías de estilo, prácticas recomendadas y guías de desarrollo, y realizan ejercicios prácticos de forma manual. Además, los ingenieros nuevos requieren un nivel adicional de aprobación para cada envío individual de la lista de cambios. Los ingenieros que aprobaron un conjunto riguroso de expectativas en función de su experiencia y que demostraron legibilidad en ese lenguaje de programación otorgan la aprobación para los cambios en un lenguaje de programación determinado. Cualquier ingeniero puede obtener legibilidad para un lenguaje de programación. La mayoría de los equipos tienen varios revisores para los lenguajes de programación en los que escriben código.
El desplazamiento hacia la izquierda mejora la velocidad de forma segura
El desplazamiento hacia la izquierda es un principio que traslada las pruebas y la validación a etapas anteriores del proceso de desarrollo. Este principio se basa en nuestra observación de que los costos aumentan de forma significativa cuanto más tarde en el proceso de lanzamiento encontremos y corrijamos un error. En un caso extremo, considera un error que un cliente encuentra en producción. Este error podría afectar de forma negativa las cargas de trabajo y las aplicaciones del cliente, y es posible que el cliente también deba pasar por el proceso de Atención al cliente de Cloud antes de que el equipo de ingeniería pertinente pueda mitigar el error. Si el ingeniero asignado para abordar el problema es una persona diferente de la que ingresó originalmente el cambio que contenía el error, el nuevo ingeniero deberá familiarizarse con los cambios de código, lo que probablemente aumentará el tiempo necesario para reproducir y, finalmente, corregir el error. Todo este proceso requiere mucho tiempo de los clientes y de la asistencia de Google Cloud, y exige que los ingenieros dejen lo que están haciendo para solucionar un problema.
Por el contrario, considera un error que detecta una prueba automatizada mientras un ingeniero trabaja en un cambio que está en desarrollo. Cuando el ingeniero ve el error de la prueba, puede corregirlo de inmediato. Debido a nuestros estándares de programación, el ingeniero ni siquiera podría enviar el cambio con la prueba con errores. Esta detección temprana significa que el ingeniero puede corregir el error sin ningún impacto en el cliente y que no hay sobrecarga de cambio de contexto.
La última opción es infinitamente preferible para todas las partes involucradas. Como resultado, con el paso de los años, Google Cloud invirtió mucho en este principio de desplazamiento hacia la izquierda, trasladando las pruebas que se realizaban tradicionalmente durante las fases de calificación de cambios y lanzamiento directamente al ciclo de desarrollo. Hoy en día, todas las pruebas de unidades, todas las pruebas de integración, excepto las más grandes, y los análisis estáticos y dinámicos exhaustivos se completan en paralelo mientras un ingeniero propone cambios de código.
Las pruebas previas al envío automatizadas aplican estándares de programación
Las pruebas previas al envío son verificaciones que se ejecutan antes de que se envíen cambios en un directorio determinado. Las pruebas previas al envío pueden ser pruebas de unidades y de integración específicas para un cambio o pruebas generales (por ejemplo, análisis estáticos y dinámicos) que se ejecutan para cualquier cambio. Históricamente, las pruebas previas al envío se ejecutaban como el último paso antes de que alguien enviara un cambio a una base de código. Hoy, en parte debido al principio de desplazamiento hacia la izquierda y a nuestra implementación de la CI, ejecutamos pruebas previas al envío de forma continua mientras un ingeniero realiza cambios de código en un entorno de desarrollo y antes de combinar los cambios en nuestro monorepo. Un ingeniero también puede ejecutar manualmente un paquete de pruebas previas al envío con un solo clic en la IU de desarrollo, y cada prueba previa al envío se ejecuta automáticamente para cada lista de cambios antes de una revisión manual del código.
Por lo general, el paquete de pruebas previas al envío abarca pruebas de unidades, pruebas de fuzz (fuzzing), pruebas de integración herméticas, así como análisis de código estático y dinámico. Para los cambios en las bibliotecas principales o el código que se usa ampliamente en Google, los desarrolladores ejecutan una verificación previa global. Una prueba global previa al envío prueba el cambio en toda la base de código de Google, lo que minimiza el riesgo de que un cambio propuesto tenga un impacto negativo en otros proyectos o sistemas.
Pruebas de unidades e integración
Las pruebas exhaustivas son fundamentales para el proceso de desarrollo de código. Todos deben escribir pruebas de unidades para los cambios de código, y hacemos un seguimiento continuo de la cobertura de código a nivel del proyecto para asegurarnos de validar el comportamiento esperado. Además, exigimos que cualquier recorrido crítico del usuario tenga pruebas de integración en las que validemos la funcionalidad de todos los componentes y dependencias necesarios.
Las pruebas de unidades y todas las pruebas de integración, excepto las más grandes, están diseñadas para completarse rápidamente y se ejecutan de forma incremental con un alto paralelismo en un entorno distribuido, lo que genera comentarios de desarrollo automatizados rápidos y continuos.
Fuzzing
Mientras que las pruebas de unidades y de integración nos ayudan a validar el comportamiento esperado con entradas y salidas predeterminadas, el fuzzing es una técnica que bombardea una aplicación con entradas aleatorias con el objetivo de exponer fallas o debilidades ocultas que podrían generar vulnerabilidades de seguridad o fallas. El fuzzing nos permite identificar y abordar de forma proactiva las posibles debilidades de nuestro software, lo que mejora la seguridad y la confiabilidad generales de nuestros productos antes de que los clientes interactúen con los cambios. La aleatoriedad de estas pruebas es particularmente útil porque, a veces, los usuarios interactúan con nuestros productos de formas interesantes que no esperamos, y la generación de fuzz nos ayuda a tener en cuenta situaciones que no consideramos de forma manual.
Análisis estático
Las herramientas de análisis estático desempeñan un papel fundamental en el mantenimiento de la calidad del código en nuestros flujos de trabajo de desarrollo. El análisis estático evolucionó significativamente desde sus primeros días de análisis con lint y expresiones regulares para identificar patrones de código C++ problemáticos. Actualmente, el análisis estático abarca todos los lenguajes de producción de Google Cloud y encuentra patrones de código erróneos, ineficientes o obsoletos.
Con LLM y frontends de compiladores avanzados, podemos proponer mejoras automáticamente mientras los ingenieros escriben código. Cada cambio de código propuesto se revisa con análisis estáticos. A medida que agregamos nuevas verificaciones estáticas con el tiempo, toda la base de código se analiza constantemente para verificar el cumplimiento, y las correcciones se generan y envían automáticamente para su revisión.
Análisis dinámico
Mientras que el análisis estático se enfoca en identificar patrones de código conocidos que pueden generar problemas, el análisis dinámico adopta un enfoque diferente. Implica compilar y ejecutar código para descubrir problemas que solo aparecen durante la ejecución, como violaciones de memoria y condiciones de carrera. Google tiene un amplio historial de uso del análisis dinámico y hasta compartió varias de sus herramientas con la comunidad más amplia de desarrolladores, incluidas las siguientes:
- AddressSanitizer: Detecta errores de memoria, como desbordamientos de búfer y uso después de liberación.
- ThreadSanitizer (C++, Go): Encuentra carreras de datos y otros errores de subprocesos
- MemorySanitizer: Descubre el uso de memoria no inicializada.
Estas herramientas y otras similares son esenciales para detectar errores complejos que no se pueden detectar solo a través del análisis estático. Con el uso de análisis estáticos y dinámicos, Google se esfuerza por garantizar que su código esté bien estructurado, no tenga problemas conocidos y se comporte como se espera en situaciones del mundo real.
Las revisiones de código manuales validan los cambios y los resultados de las pruebas.
Cuando un ingeniero alcanza un evento importante en su código y quiere integrarlo en el repositorio principal, inicia una revisión de código proponiendo una lista de cambios. Una solicitud de revisión de código consta de lo siguiente:
- Una descripción que capture el propósito de los cambios y cualquier contexto adicional
- El código modificado real
- Pruebas de unidades y de integración para el código modificado
- Resultados de la prueba previa al envío automatizada
En este punto del proceso de desarrollo, interviene otra persona. Uno o más revisores designados examinan cuidadosamente la lista de cambios para verificar su exactitud y claridad, y usan las pruebas adjuntas y los resultados previos al envío como guía. Cada directorio de código tiene un conjunto de revisores designados responsables de garantizar la calidad de ese subconjunto de la base de código, cuya aprobación es necesaria para realizar cambios en ese directorio. Los revisores y los ingenieros colaboran para detectar y abordar cualquier problema que pueda surgir con un cambio de código propuesto. Cuando la lista de cambios cumple con nuestros estándares, un revisor la aprueba ("LGTM", que significa "se ve bien para mí"). Sin embargo, si el ingeniero se está formando todavía para el lenguaje de programación que se usa, necesita la aprobación adicional de un experto que haya demostrado legibilidad en el lenguaje de programación.
Después de que una lista de cambios pasa las pruebas y verificaciones automatizadas y recibe un LGTM, el ingeniero que propuso el cambio solo puede realizar cambios mínimos en el código. Cualquier alteración sustancial invalida la aprobación y requiere otra ronda de revisión. Incluso los cambios pequeños se marcan automáticamente para los revisores originales. Una vez que el ingeniero envía el código finalizado, este pasa por otra ronda completa de pruebas previas al envío antes de que la lista de cambios se combine en el monorepo. Si alguna prueba falla, se rechaza el envío, y el desarrollador y los revisores reciben una alerta para que tomen medidas correctivas antes de volver a enviar los cambios.
Calificación de lanzamiento seguro
Si bien las pruebas previas al envío son exhaustivas, no son el final del proceso de pruebas en Google. A menudo, los equipos tienen pruebas adicionales, como pruebas de integración a gran escala, que no es posible ejecutar durante la revisión de código inicial (pueden tardar más tiempo en ejecutarse o requerir entornos de prueba de alta fidelidad). Además, los equipos deben estar al tanto de cualquier falla causada por factores fuera de su control, como cambios en las dependencias externas.
Por eso, Google requiere una fase de calificación después de la fase de desarrollo. En esta fase de calificación, se usa un proceso continuo de compilación y prueba, como se muestra en el siguiente diagrama:
Este proceso ejecuta pruebas de forma periódica para todo el código afectado por cambios directos o indirectos desde la última ejecución. Cualquier falla se deriva automáticamente al equipo de ingeniería responsable. En muchos casos, el sistema puede identificar automáticamente la lista de cambios que causó la falla y revertirla. Estas pruebas de integración a gran escala se ejecutan en un espectro de entornos de etapa de pruebas que van desde entornos parcialmente simulados hasta ubicaciones físicas completas.
Las pruebas tienen una variedad de objetivos de calificación que van desde la confiabilidad y la seguridad básicas hasta la lógica empresarial. Estas pruebas de calificación incluyen probar el código para lo siguiente:
- La capacidad de proporcionar la funcionalidad requerida, que se prueba con pruebas de integración a gran escala
- La capacidad de satisfacer los requisitos empresariales, que se prueba con representaciones sintéticas de las cargas de trabajo de los clientes
- La capacidad de soportar fallas de la infraestructura subyacente, que se prueba mediante la inserción de fallas en la pila
- La capacidad de mantener la capacidad de entrega, que se prueba con frameworks de pruebas de carga
- La capacidad de revertir de forma segura
Lanzamientos seguros
Incluso con los procesos de desarrollo, prueba y calificación más sólidos, a veces se infiltran defectos en los entornos de producción que afectan negativamente a nuestros usuarios. En esta sección, explicamos cómo el proceso de lanzamiento de Google Cloud limita el impacto de los cambios defectuosos y garantiza la detección rápida de cualquier regresión. Aplicamos este enfoque a todos los tipos de cambios que se implementan en producción, incluidos los objetos binarios, las configuraciones, las actualizaciones de esquemas, los cambios de capacidad y las listas de control de acceso.
Supervisión y propagación de cambios
Aplicamos un enfoque coherente para implementar cambios en Google Cloud con el fin de minimizar los impactos negativos para los clientes y aislar los problemas en dominios de fallas lógicos y físicos individuales. El proceso se basa en nuestras prácticas de confiabilidad de SRE de décadas y en nuestro sistema de supervisión a escala planetaria para detectar y mitigar los cambios incorrectos lo más rápido posible. La detección rápida nos permite notificar a los clientes más rápido y tomar medidas correctivas para evitar de forma sistemática que se vuelvan a producir fallas similares.
La mayoría de los productos de Google Cloud son regionales o zonales. Esto significa que un producto regional que se ejecuta en la región A es independiente del mismo producto que se ejecuta en la región B. Del mismo modo, un producto zonal que se ejecuta en la zona C dentro de la región A es independiente del mismo producto zonal que se ejecuta en la zona D dentro de la región A. Esta arquitectura minimiza el riesgo de una interrupción que afecte a otras regiones o a otras zonas dentro de una sola región. Algunos servicios, como IAM o la consola de Google Cloud, proporcionan una capa coherente a nivel global que abarca todas las regiones, por lo que los llamamos servicios globales. Los servicios globales se replican en todas las regiones para evitar puntos únicos de fallo y minimizar la latencia. La plataforma de lanzamiento compartida de Google Cloud sabe si un servicio es zonal, regional o global, y orquesta los cambios de producción de manera adecuada.
El proceso de lanzamiento de Google Cloud divide todas las réplicas de un servicio que se implementa en varias ubicaciones de destino en conjuntos. Los conjuntos iniciales incluyen una pequeña cantidad de réplicas, y las actualizaciones se realizan de forma serial. Los conjuntos iniciales equilibran la protección de la mayoría de las cargas de trabajo de los clientes con la maximización de la exposición a la diversidad de cargas de trabajo para detectar problemas lo antes posible y, además, incluyen cargas de trabajo sintéticas que imitan patrones comunes de cargas de trabajo de los clientes.
Si el lanzamiento sigue siendo exitoso a medida que se actualizan las réplicas del servicio en las ubicaciones de destino, los conjunto de lanzamiento posteriores aumentan de tamaño de forma progresiva y, además, ingresan más paralelismo. Si bien es necesario cierto paralelismo para tener en cuenta la cantidad de ubicaciones de Google Cloud, no permitimos actualizaciones simultáneas en ubicaciones que se encuentran en diferentes conjuntos. Si un conjunto se extiende hasta la noche o un fin de semana, puede completar su progresión, pero no se puede iniciar un conjunto nuevo hasta que comience el horario de atención del equipo que administra el lanzamiento.
El siguiente diagrama es un ejemplo de flujo de trabajo que ilustra la lógica de lanzamiento que usamos en Google Cloud para los productos y servicios regionales:
El proceso de lanzamiento de Google Cloud usa el servicio de análisis de versiones canary (CAS) para automatizar las pruebas A/B durante el lanzamiento. Algunas réplicas se convierten en canaries (es decir, una implementación parcial y por tiempo limitado de un cambio en un servicio), y las réplicas restantes conforman el grupo de control que no incluye el cambio. Cada paso del proceso de lanzamiento tiene un tiempo de preparación para detectar problemas de combustión lenta antes de pasar al siguiente paso y garantizar que todas las funciones de un servicio se ejecuten correctamente y que CAS detecte posibles anomalías. El tiempo de compilación se define con cuidado para equilibrar la detección de problemas de combustión lenta con la velocidad de desarrollo. Los lanzamientos de Google Cloud suelen tardar una semana.
En este diagrama, se proporciona una descripción general rápida de cómo se ve el flujo de trabajo de CAS:
El flujo de trabajo comienza con la herramienta de lanzamiento que implementa el cambio en la réplica de versión canary. Luego, la herramienta de lanzamiento solicita un veredicto a CAS. CAS evalúa la réplica de versión canary en función del grupo de control y muestra un veredicto de APROBACIÓN o RECHAZO. Si falla algún indicador de estado, se genera una alerta para los propietarios del servicio y se pone en pausa o se revierte el paso de ejecución del lanzamiento. Si el cambio causa una interrupción para los clientes externos, se declara un incidente externo y se notifica a los clientes afectados mediante el servicio de Personalized Service Health. Los incidentes también activan una revisión interna. La filosofía postmortem de Google se asegura de que se identifique y aplique el conjunto correcto de medidas correctivas para minimizar la probabilidad de que vuelvan a ocurrir fallas similares.
Indicadores de supervisión y seguridad posterior al lanzamiento
Los defectos de software no siempre se manifiestan de inmediato, y algunos pueden requerir circunstancias específicas para activarse. Por este motivo, seguimos supervisando los sistemas de producción después de que se completa un lanzamiento. A lo largo de los años, notamos que, incluso si un lanzamiento no activa ningún problema de inmediato, un lanzamiento incorrecto sigue siendo el culpable más probable de un incidente de producción. Por este motivo, nuestras guías de producción instruyen a los equipos de respuesta ante incidentes a correlacionar los lanzamientos recientes con los problemas observados y a revertir de forma predeterminada un lanzamiento reciente si los equipos de respuesta ante incidentes no pueden descartar los cambios recientes como causa raíz del incidente.
La supervisión posterior al lanzamiento se basa en el mismo conjunto de indicadores de supervisión que usamos para los análisis A/B automatizados durante un período de lanzamiento. La filosofía de supervisión y alertas de Google Cloud combina dos tipos de supervisión: introspectiva (también conocida como caja blanca) y sintética (también conocida como caja negra). La supervisión introspectiva usa métricas como el uso de CPU, el uso de memoria y otros datos internos del servicio. La supervisión sintética analiza el comportamiento del sistema desde la perspectiva de un cliente, realiza un seguimiento de los índices de error del servicio y las respuestas al tráfico sintético de los servicios de sondeo. La supervisión sintética se orienta a los síntomas y, además, identifica los problemas activos, mientras que la supervisión introspectiva nos permite diagnosticar problemas confirmados y, en algunos casos, identificar problemas inminentes.
Para ayudar a detectar incidentes que solo afectan a algunos clientes, agrupamos las cargas de trabajo de los clientes en cohortes de cargas de trabajo relacionadas. Las alertas se activan apenas el rendimiento de una cohorte se desvía de la norma. Estas alertas nos permiten detectar regresiones específicas del cliente, incluso si el rendimiento agregado parece ser normal.
Protección de la cadena de suministro de software
Cada vez que los equipos de Google Cloud implementan cambios, usamos una verificación de seguridad llamada Autorización binaria para Borg (BAB) para proteger nuestra cadena de suministro de software y a los clientes de Cloud contra el riesgo de tener usuarios con información privilegiada. BAB comienza en la etapa de revisión de código y crea un registro de auditoría del código y la configuración que se implementa en producción. Para garantizar la integridad de la producción, BAB solo admite cambios que cumplan con los siguientes criterios:
- Son a prueba de manipulaciones y están firmados
- Provienen de un grupo de compilación y una ubicación de origen identificados.
- Se hayan revisado y aprobado de forma explícita por una parte distinta del autor del código
Si te interesa aplicar algunos de los mismos conceptos en tu propio ciclo de vida de desarrollo de software, incluimos conceptos clave de BAB en una especificación abierta llamada Niveles de cadena de suministro para artefactos de software (SLSA). La SLSA actúa como un framework de seguridad para desarrollar y ejecutar código en entornos de producción.
Conclusión
Google Cloud se basa en las décadas de inversión de Google en la excelencia del desarrollo. El estado del código y el estado de producción son principios culturales inculcados en todos los equipos de ingeniería de Google. Nuestro proceso de revisión de diseño garantiza que se tengan en cuenta las implicaciones en el código y el estado de producción desde el principio. Nuestro proceso de desarrollo, basado en el principio de desplazamiento hacia la izquierda y en pruebas exhaustivas, garantiza que las ideas de diseño se implementen de forma segura y correcta. Nuestro proceso de calificación expande aún más las pruebas para abarcar integraciones a gran escala y dependencias externas. Por último, nuestra plataforma de lanzamiento nos permite generar confianza de forma progresiva en que un cambio determinado se comporta según lo esperado. Nuestro enfoque, que abarca desde la concepción hasta la producción, nos permite cumplir con las expectativas de los clientes de Google Cloud en cuanto a la velocidad de desarrollo y la confiabilidad.