Cada año, miles de millones de usuarios interactúan con los productos y servicios de Google. Las ofertas clave, como la Búsqueda, Gmail, Maps, YouTube, Chrome y ahora tambiénGoogle Cloud, están tan integradas en la vida moderna que ayudan a definir la experiencia del siglo XXI. Este impacto a nivel mundial es el resultado de la calidad probada de nuestros productos y de la expectativa de que Google esté siempre disponible.
En Google Cloud, introducimos continuamente cambios en el código de nuestros productos y servicios para ofrecer la mejor experiencia de usuario posible, mejorar la seguridad y la fiabilidad, y cumplir los requisitos normativos. Sin embargo, cualquier cambio, por grande o pequeño que sea, puede provocar fallos. 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 Google Cloud los equipos aprovechan las décadas de inversión de Google en la excelencia del desarrollo para implementar las prácticas recomendadas de fiabilidad y los estándares de ingeniería que cumplen las expectativas de los clientes Google Cloud en cuanto a velocidad y fiabilidad del desarrollo.
El tiempo de vida de un cambio en Google Cloud
Google Cloud Los equipos de producto comparten gran parte del proceso de gestión y las herramientas con otros equipos de ingeniería de Google. Implementamos un enfoque de desarrollo de software estándar para la gestión de cambios que prioriza la integración continua (CI) y la entrega continua (CD). La integración continua incluye proponer, probar y enviar cambios con frecuencia, a menudo varias veces al día, para cualquier producto o servicio. El CD es una extensión de la CI en la que los ingenieros preparan continuamente versiones candidatas basadas en la última instantánea estable de una base de código.
Con esta estrategia, se prioriza la creación y la implementación de cambios por fases paraGoogle Cloud los clientes lo antes posible, pero también de la forma más segura posible. Tenemos en cuenta la seguridad de los cambios antes de escribir cualquier código y seguimos centrándonos en la seguridad incluso después de implementar los cambios en producción. Nuestro modelo de gestión de cambios consta de cuatro fases generales: diseño, desarrollo, cualificación y lanzamiento. Estas cuatro fases se muestran en el siguiente diagrama y se explican con más detalle a lo largo de este documento:
Seguridad desde el diseño
Somos conscientes de que, incluso los pequeños errores que se cometen al principio del proceso de desarrollo pueden provocar problemas graves más adelante que afecten significativamente a la experiencia de los clientes. Por este motivo, todos los cambios importantes deben empezar con un documento de diseño aprobado. Tenemos una plantilla de documento de diseño común 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 los productos deGoogle Cloud de forma coherente. En el siguiente diagrama se muestra cómo es 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 aborda los requisitos empresariales, técnicos, de costes y de mantenimiento. Después de enviar ese cambio, se inicia un proceso de revisión y aprobación exhaustivo con expertos séniores, incluidos expertos en fiabilidad y seguridad, y responsables técnicos. El trabajo para implementar el cambio solo puede llevarse a cabo después de que el ingeniero que propuso el diseño responda a 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 producto empiecen a trabajar en cambios que puedan afectar negativamente a los clientes en producción.Google Cloud
Seguro tal como se ha desarrollado
Nuestro proceso de desarrollo de código aumenta la calidad y la fiabilidad de nuestro código. Una vez que se aprueba un cambio propuesto, se inicia el proceso de desarrollo con una incorporación completa de los nuevos ingenieros, que incluye formación, tutoría 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 continuamente el código en cada fase del desarrollo. Cada cambio de código se revisa a fondo para asegurarse de que cumple los altos estándares de Google.
En el siguiente diagrama se muestra un flujo de trabajo que ilustra aproximadamente cómo es nuestro proceso de desarrollo:
La fase de desarrollo comienza cuando un ingeniero empieza a escribir código y las pruebas unitarias y de integración correspondientes. Durante esta fase, el ingeniero puede ejecutar las pruebas que ha escrito y un conjunto de pruebas previas al envío para asegurarse de que las adiciones y los cambios de código son válidos. Después de completar los cambios en el código y ejecutar las pruebas, el ingeniero solicita una revisión manual a otra persona que esté familiarizada con el código. Este proceso de revisión humana suele ser iterativo y puede dar lugar a 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 codificación aseguran que los cambios sean de alta calidad
La cultura, las prácticas y las herramientas de ingeniería de Google se han diseñado para asegurar que nuestro código sea correcto, claro, conciso y eficiente. El desarrollo de código en Google se lleva a cabo en nuestro monorepo, el repositorio de código integrado más grande del mundo. El monorrepositorio contiene millones de archivos de origen, miles de millones de líneas de código y un historial de cientos de millones de confirmaciones llamadas listas de cambios. Sigue creciendo rápidamente y se añaden decenas de miles de listas de cambios cada día laborable. Las principales ventajas del monorrepositorio son que facilita la reutilización del código, simplifica la gestión de dependencias y aplica flujos de trabajo de desarrollador coherentes en todos los productos y servicios.
La reutilización de código es útil porque ya tenemos una idea clara de cómo funciona el código reutilizado en producción. Al aprovechar el código de alta calidad que ya existe, los cambios son intrínsecamente 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 asegura que el estado general de la base de código siga siendo bueno, lo que da lugar a productos más fiables.
Google Cloud Los servicios que se basan en software libre de alta calidad pueden complementar el monorrepositorio con otro repositorio (normalmente Git) para usar ramificaciones y gestionar el software libre.
Nota sobre el entrenamiento
La inversión en la calidad del código empieza cuando un ingeniero se une a un equipo. Si el ingeniero es nuevo en Google o no está muy familiarizado con la infraestructura y la arquitectura del equipo, se somete a un proceso de incorporación exhaustivo. Como parte de este proceso de incorporación, estudian guías de estilo, prácticas recomendadas y guías de desarrollo, y realizan ejercicios prácticos manualmente. Además, los nuevos ingenieros requieren un nivel de aprobación adicional para cada envío de lista de cambios. Los ingenieros que han superado una serie de requisitos rigurosos basados en su experiencia y que han demostrado que pueden escribir código legible en un lenguaje de programación determinado son los que pueden aprobar los cambios en ese lenguaje. Cualquier ingeniero puede obtener legibilidad para un lenguaje de programación. La mayoría de los equipos tienen varios aprobadores para los lenguajes de programación en los que codifican.
La estrategia de "shift left" mejora la velocidad de forma segura
Shift left es un principio que traslada las pruebas y la validación a fases más tempranas del proceso de desarrollo. Este principio se basa en nuestra observación de que los costes aumentan considerablemente cuanto más tarde se detecta y se corrige un error en el proceso de lanzamiento. En un caso extremo, piensa en un error que un cliente detecta en producción. Este error podría afectar negativamente a las cargas de trabajo y las aplicaciones del cliente, y es posible que el cliente también tenga que seguir el proceso de Asistencia de Google Cloud para que el equipo de ingeniería correspondiente pueda mitigar el error. Si el ingeniero asignado para solucionar el problema es una persona diferente de la que introdujo el cambio que contenía el error, el nuevo ingeniero tendrá que familiarizarse con los cambios en el código, lo que probablemente aumentará el tiempo necesario para reproducir y, finalmente, corregir el error. Todo este proceso requiere mucho tiempo por parte de los clientes y del equipo de asistencia de Google Cloud, y exige que los ingenieros dejen de lado lo que estén haciendo para solucionar un problema.
Por el contrario, imagina que una prueba automatizada detecta un error mientras un ingeniero está trabajando en un cambio que se encuentra en fase de desarrollo. Cuando el ingeniero vea que la prueba ha fallado, podrá corregirlo inmediatamente. Debido a nuestros estándares de codificación, el ingeniero ni siquiera podría enviar el cambio con el error de la prueba. Esta detección temprana significa que el ingeniero puede corregir el error sin que afecte a los clientes y que no hay sobrecarga de cambio de contexto.
Esta última opción es infinitamente mejor para todos los implicados. Por eso, a lo largo de los años, Google Cloud ha invertido mucho en este principio de "shift left", trasladando las pruebas que tradicionalmente se realizaban durante las fases de cualificación y lanzamiento de los cambios directamente al bucle de desarrollo. Actualmente, todas las pruebas unitarias, 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 en el código.
Las pruebas previas automatizadas aplican los estándares de codificación
Las pruebas previas al envío son comprobaciones que se ejecutan antes de que se envíen los cambios en un directorio determinado. Las pruebas previas a la confirmación pueden ser pruebas unitarias y de integración específicas de un cambio o pruebas generales (por ejemplo, análisis estático y dinámico) que se ejecutan para cualquier cambio. Tradicionalmente, las pruebas previas al envío se realizaban como último paso antes de que alguien enviara un cambio a una base de código. Hoy en día, en parte debido al principio de "shift left" y a nuestra implementación de la integración continua, realizamos pruebas previas al envío de forma continua mientras un ingeniero hace cambios en el código en un entorno de desarrollo y antes de combinar los cambios en nuestro monorrepositorio. Un ingeniero también puede ejecutar manualmente un conjunto de pruebas previas con un solo clic en la interfaz de desarrollo, y cada prueba previa se ejecuta automáticamente para cada lista de cambios antes de que un revisor humano revise el código.
El conjunto de pruebas previas al envío suele incluir pruebas unitarias, pruebas de fuzzing, pruebas de integración herméticas y análisis de código estático y dinámico. Para cambiar bibliotecas principales o código que se usa en Google, los desarrolladores ejecutan una prueba previa global. Una prueba de envío previo global comprueba el cambio en toda la base de código de Google, lo que minimiza el riesgo de que un cambio propuesto afecte negativamente a otros proyectos o sistemas.
Pruebas unitarias y de integración
Las pruebas exhaustivas son una parte esencial del proceso de desarrollo de código. Todos los empleados deben escribir pruebas unitarias para los cambios en el código y hacemos un seguimiento continuo de la cobertura del código a nivel de proyecto para asegurarnos de que validamos el comportamiento esperado. Además, requerimos que cualquier recorrido de usuario crítico tenga pruebas de integración en las que validemos la funcionalidad de todos los componentes y dependencias necesarios.
Las pruebas unitarias 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 da como resultado comentarios de desarrollo automatizados rápidos y continuos.
Fuzzing
Mientras que las pruebas unitarias 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 para exponer fallos o vulnerabilidades ocultos que podrían provocar vulnerabilidades de seguridad o fallos. El fuzzing nos permite identificar y abordar de forma proactiva posibles vulnerabilidades en nuestro software, lo que mejora la seguridad y la fiabilidad generales de nuestros productos antes de que los clientes interactúen con los cambios. La aleatoriedad de estas pruebas es especialmente útil porque, a veces, los usuarios interactúan con nuestros productos de formas interesantes que no esperamos, y el fuzzing nos ayuda a tener en cuenta situaciones que no hemos considerado manualmente.
Análisis estático
Las herramientas de análisis estático desempeñan un papel fundamental a la hora de mantener la calidad del código en nuestros flujos de trabajo de desarrollo. El análisis estático ha evolucionado significativamente desde sus inicios, cuando se usaba para detectar patrones de código C++ problemáticos con expresiones regulares. Actualmente, el análisis estático abarca todos los lenguajes de producción de Google Cloud y detecta patrones de código erróneos, ineficientes u obsoletos.
Con los front-ends de compilador avanzados y los LLMs, podemos proponer mejoras automáticamente mientras los ingenieros escriben código. Cada cambio de código propuesto se verifica con análisis estáticos. A medida que añadimos nuevas comprobaciones estáticas, se analiza toda la base de código constantemente para comprobar que cumple los requisitos, y las correcciones se generan y se envían automáticamente para que se revisen.
Análisis dinámico
Mientras que el análisis estático se centra en identificar patrones de código conocidos que pueden provocar 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 infracciones de memoria y condiciones de carrera. Google tiene un amplio historial de uso del análisis dinámico e incluso ha compartido varias de sus herramientas con la comunidad de desarrolladores en general, entre las que se incluyen las siguientes:
- AddressSanitizer Detecta errores de memoria, como desbordamientos de búfer y errores de uso de memoria después de la liberación (use-after-free).
- ThreadSanitizer (C++, Go): busca condiciones de carrera 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 con el análisis estático. Mediante el uso de análisis estáticos y dinámicos, Google se esfuerza por asegurarse de que su código esté bien estructurado, no tenga problemas conocidos y se comporte como se espera en situaciones reales.
Las revisiones de código humanas validan los cambios y los resultados de las pruebas
Cuando un ingeniero alcanza un hito 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 refleje el propósito de los cambios y cualquier contexto adicional
- El código modificado real
- Pruebas unitarias y de integración del código modificado
- Resultados de pruebas previas automatizadas
Es en este punto del proceso de desarrollo cuando interviene otra persona. Uno o varios revisores designados examinan cuidadosamente la lista de cambios para comprobar que sea correcta y clara, y usan las pruebas adjuntas y los resultados de las comprobaciones previas como guía. Cada directorio de código tiene un conjunto de revisores designados responsables de asegurar la calidad de ese subconjunto de la base de código y cuya aprobación es necesaria para hacer cambios en ese directorio. Los revisores y los ingenieros colaboran para detectar y solucionar cualquier problema que pueda surgir con un cambio de código propuesto. Cuando la lista de cambios cumple nuestros estándares, un revisor da su aprobación ("LGTM", abreviatura de "looks good to me"). Sin embargo, si el ingeniero aún está formándose en el lenguaje de programación utilizado, necesitará la aprobación adicional de un experto que haya obtenido la legibilidad en ese lenguaje.
Una vez que una lista de cambios supera las pruebas y las comprobaciones automatizadas, y recibe un LGTM, el ingeniero que propuso el cambio solo puede hacer cambios mínimos en el código. Si se realizan cambios sustanciales, la aprobación deja de ser válida y se debe llevar a cabo 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, se somete a otra ronda completa de pruebas previas al envío antes de que la lista de cambios se combine en el monorrepositorio. Si no se supera alguna prueba, se rechaza el envío y el desarrollador y los revisores reciben una alerta para que tomen medidas correctoras antes de volver a enviar los cambios.
Cualificación de retirada segura
Aunque las pruebas previas al envío son exhaustivas, no son el final del proceso de pruebas en Google. Los equipos suelen hacer pruebas adicionales, como pruebas de integración a gran escala, que no se pueden realizar durante la revisión inicial del código (pueden tardar más en ejecutarse o requerir entornos de prueba de alta fidelidad). Además, los equipos deben ser conscientes de los fallos causados por factores ajenos a su control, como los cambios en las dependencias externas.
Por eso, Google requiere una fase de cualificación después de la fase de desarrollo. Esta fase de cualificación usa un proceso continuo de compilación y prueba, como se muestra en el siguiente diagrama:
Este proceso ejecuta periódicamente pruebas de todo el código afectado por cambios directos o indirectos desde la última ejecución. Los errores se derivan automáticamente al equipo de ingeniería responsable. En muchos casos, el sistema puede identificar automáticamente la lista de cambios que ha provocado el fallo y revertirla. Estas pruebas de integración a gran escala se ejecutan en un espectro de entornos de preproducción que van desde entornos parcialmente simulados hasta ubicaciones físicas completas.
Las pruebas tienen varios objetivos de cualificación que van desde la fiabilidad y la seguridad básicas hasta la lógica empresarial. Estas pruebas de cualificación incluyen la comprobación del código para lo siguiente:
- La capacidad de ofrecer las funciones necesarias, que se prueba mediante 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 resistir los fallos de la infraestructura subyacente, que se prueba mediante la inyección de fallos en toda la pila
- La capacidad de mantener la capacidad de servicio, que se prueba con frameworks de pruebas de carga
- La posibilidad de restaurar una versión anterior de forma segura
Lanzamientos seguros
Incluso con los procesos de desarrollo, prueba y cualificación más sólidos, a veces se cuelan defectos en los entornos de producción que afectan negativamente a nuestros usuarios. En esta sección, explicamos cómo el Google Cloud proceso de lanzamiento limita el impacto de los cambios defectuosos y asegura 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 binarios, las configuraciones, las actualizaciones de esquemas, los cambios de capacidad y las listas de control de acceso.
Propagación y supervisión de cambios
Aplicamos un enfoque coherente para implementar cambios en Google Cloud para minimizar los efectos negativos en los clientes y aislar los problemas en dominios de errores lógicos y físicos individuales. El proceso se basa en nuestras prácticas de fiabilidad de SRE, que llevamos décadas aplicando, y en nuestro sistema de monitorización a escala planetaria para detectar y mitigar los cambios incorrectos lo antes posible. La detección rápida nos permite avisar a los clientes antes y tomar medidas correctivas para evitar sistemáticamente que se produzcan fallos similares.
La mayoría de los Google Cloud productos son regionales o zonales. Esto significa que un producto regional que se ejecute en la región A es independiente del mismo producto que se ejecute en la región B. Del mismo modo, un producto zonal que se ejecuta en la zona C de la región A es independiente del mismo producto zonal que se ejecuta en la zona D de la región A. Esta arquitectura minimiza el riesgo de que se produzca una interrupción que afecte a otras regiones u otras zonas de una misma región. Algunos servicios, como IAM o laGoogle Cloud consola, proporcionan una capa coherente a nivel global que abarca todas las regiones, por lo que los denominamos servicios globales. Los servicios globales se replican en varias regiones para evitar puntos únicos de fallo y minimizar la latencia. La plataforma de lanzamiento compartido sabe si un servicio es zonal, regional o global, y coordina los cambios de producción de forma adecuada. Google Cloud
El proceso de lanzamiento Google Cloud divide todas las réplicas de un servicio implementado en varias ubicaciones de destino en fases. Las oleadas iniciales incluyen un pequeño número de réplicas, y las actualizaciones se realizan de forma secuencial. Las primeras oleadas 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 las cargas de trabajo para detectar problemas lo antes posible e incluyen cargas de trabajo sintéticas que imitan patrones de cargas de trabajo comunes de los clientes.
Si el lanzamiento sigue siendo correcto a medida que se actualizan las réplicas del servicio en las ubicaciones de destino, las siguientes fases de lanzamiento aumentarán progresivamente de tamaño e introducirán más paralelismo. Aunque es necesario cierto paralelismo para tener en cuenta el número de Google Cloud ubicaciones, no permitimos que se actualicen simultáneamente las ubicaciones que se encuentran en diferentes oleadas. Si una oleada se prolonga hasta la noche o el fin de semana, puede completar su progresión, pero no puede empezar ninguna oleada nueva hasta que empiece el horario de apertura del equipo que gestiona 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 productos y servicios regionales:
El Google Cloud proceso de lanzamiento utiliza el servicio de análisis Canary (CAS) para automatizar las pruebas A/B durante todo el lanzamiento. Algunas réplicas se convierten en canarios (es decir, una implementación parcial y limitada en el tiempo de un cambio en un servicio), y las réplicas restantes forman el grupo de control que no incluye el cambio. Cada paso del proceso de lanzamiento tiene un tiempo de espera para detectar problemas que se manifiestan lentamente antes de pasar al siguiente paso. De esta forma, nos aseguramos de que todas las funciones de un servicio se prueben correctamente y de que CAS detecte posibles anomalías. El tiempo de horneado se define cuidadosamente para equilibrar la detección de problemas de larga duración con la velocidad de desarrollo.Las implementaciones suelen tardar una semana. Google Cloud
En este diagrama se muestra un resumen del flujo de trabajo de CAS:
El flujo de trabajo empieza con la herramienta de lanzamiento, que implementa el cambio en la réplica canary. A continuación, la herramienta de lanzamiento solicita un veredicto a CAS. CAS evalúa la réplica canary con respecto al grupo de control y devuelve un veredicto de ÉXITO o FALLO. Si falla alguna señal de estado, se genera una alerta para los propietarios del servicio y se pausa o se revierte el paso en curso del lanzamiento. Si el cambio provoca interrupciones para los clientes externos, se declara un incidente externo y se notifica a los clientes afectados mediante el servicio Estado del servicio personalizado. Los incidentes también activan una revisión interna. La filosofía de post mortem de Google asegura que se identifiquen y se apliquen las medidas correctivas adecuadas para minimizar la probabilidad de que se produzcan fallos similares de nuevo.
Monitorización de señales y seguridad posterior al lanzamiento
Los defectos de software no siempre se manifiestan al instante y algunos pueden requerir circunstancias específicas para activarse. Por este motivo, seguimos monitorizando los sistemas de producción después de que se haya completado el lanzamiento. A lo largo de los años, hemos observado que, aunque un lanzamiento no provoque ningún problema de inmediato, sigue siendo el culpable más probable de un incidente de producción. Por este motivo, nuestros manuales de producción indican a los responsables de responder a incidentes que correlacionen los lanzamientos recientes con los problemas observados y que, de forma predeterminada, reviertan un lanzamiento reciente si no pueden descartar que los cambios recientes sean la causa principal del incidente.
La monitorización posterior al lanzamiento se basa en el mismo conjunto de señales de monitorización que usamos para los análisis A/B automatizados durante una ventana de lanzamiento. La filosofía de Google Cloud monitorización y alertas combina dos tipos de monitorización: introspectiva (también conocida como de caja blanca) y sintética (también conocida como de caja negra). La monitorización introspectiva usa métricas como el uso de la CPU, el uso de la memoria y otros datos de servicios internos. La monitorización sintética analiza el comportamiento del sistema desde la perspectiva del cliente, monitorizando las tasas de error del servicio y las respuestas al tráfico sintético de los servicios de sondeo. La monitorización sintética se centra en los síntomas e identifica los problemas activos, mientras que la monitorización introspectiva nos permite diagnosticar los problemas confirmados y, en algunos casos, identificar los 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 en cuanto el rendimiento de una cohorte se desvía de la norma. Estas alertas nos permiten detectar regresiones específicas de los clientes aunque el rendimiento agregado parezca normal.
Protección de la cadena de suministro de software
Cada vez que Google Cloud los equipos introducen cambios, usamos una comprobación de seguridad llamada Autorización binaria para Borg (BAB) para proteger nuestra cadena de suministro de software y a los clientes de Cloud frente a los riesgos internos. BAB empieza en la fase de revisión del código y crea un registro de auditoría del código y la configuración desplegados en producción. Para garantizar la integridad de la producción, BAB solo admite cambios que cumplan los siguientes criterios:
- Están firmados y a prueba de manipulaciones
- Proceder de un compilador y una ubicación de origen identificados
- Se han revisado y aprobado explícitamente 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, hemos incluido conceptos clave de BAB en una especificación abierta llamada Niveles de la cadena de suministro para artefactos de software (SLSA). 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. La salud del código y la salud de la producción son principios culturales que se inculcan a todos los equipos de ingeniería de Google. Nuestro proceso de revisión del 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 "shift left" y en pruebas exhaustivas, garantiza que las ideas de diseño se implementen de forma segura y correcta. Nuestro proceso de cualificación amplía aún más las pruebas para cubrir integraciones a gran escala y dependencias externas. Por último, nuestra plataforma de lanzamiento nos permite ir ganando confianza progresivamente en que un cambio determinado se comporta como se espera. Nuestro enfoque, que abarca desde la concepción hasta la producción, nos permite cumplir las expectativas de los clientes en cuanto a la velocidad de desarrollo y la fiabilidad.Google Cloud