Planteamiento del problema:
Cuando TCS era solo un prototipo, agrupar su aplicación y compartirla con el equipo de prueba era bastante simple. Los codificadores podrían simplemente enviar por correo electrónico un enlace a la aplicación que se ejecuta en sus máquinas de desarrollo. Pero a medida que crecía la aplicación y su equipo de desarrollo, eso ya no era factible. La prueba manual y la implementación de cambios en el código base se convirtieron en un cuello de botella para el equipo. Sin tener un proceso confiable, en su mayoría automático, para crear pruebas y actualizar su aplicación basada en microservicios, TCS simplemente no podría escalar al nivel que soñaban. Entonces, implementaron una canalización de CI/CD mediante Cloud Build, la plataforma de CI/CD sin servidor de Google, y Spinnaker, una plataforma de entrega continua de código abierto.
TCS tuvo que resolver esta entrega empaquetada utilizando la canalización de CI/CD. Una vez que hicieran un cambio en el código, ¿cómo se implementaría para los usuarios de manera escalable?
Solución:
Entonces, TCS implementó una canalización de CI/CD basada en etiquetas y cerrada. Esto les permitió iterar y probar rápidamente el código base. Los pasos de alto nivel de esta canalización son los siguientes. Un desarrollador cambia el código y lo envía a un repositorio. Cloud Build detecta los cambios, crea una imagen de Docker, prueba la imagen y envía la imagen al registro de artefactos. Spinnaker detecta esa imagen, la implementa en un entorno de ensayo y prueba la implementación. Una vez superadas las pruebas, el administrador de versiones puede aprobar manualmente la compilación e implementar la imagen en producción.
Veamos cada uno de estos pasos. Primero, el equipo ya estaba usando Git para administrar su código fuente. Como es común en el desarrollo de juegos, almacenan activos binarios en otros lugares y los extraen cuando se produce una compilación.
El uso de Git permite a los desarrolladores verificar una nueva rama del código base para hacer su trabajo antes de volver a fusionarlo con la rama principal después de probarlo. Esto permite a los desarrolladores trabajar fácilmente con otros desarrolladores y les brinda mucha flexibilidad en el flujo de trabajo.
TCS aprovechó las etiquetas de Git para crear una canalización de CI/CD que se inicia cada vez que se inserta una nueva etiqueta en el repositorio de Git. Usan Cloud Build para producir el binario de la aplicación y configuran un activador para observar cualquier confirmación con una etiqueta de Git con el prefijo «v». Además, para confirmar con una etiqueta específica, los activadores pueden buscar confirmaciones en una rama o extraer solicitud. Luego, automáticamente comienza a crear y prueba una nueva imagen de Docker y la envía al registro de artefactos, que es un lugar único para que su organización administre imágenes de contenedores y paquetes de idioma.
Y el tramo final del reprocesamiento se inicia una vez que Spinnaker detecta la nueva imagen en el registro de artefactos. A partir de ahí, Spinnaker implementaría la imagen en un entorno de prueba reducido para las pruebas de integración. Estas pruebas preliminares permiten que TCS tenga la mejor oportunidad de minimizar las fallas.
Una vez que pasan esas pruebas, un ingeniero de construcción puede cambiar un poco y enviar la nueva imagen a producción donde la audiencia de TCS puede acceder a la nueva función.
Entre Git, Cloud Build, el registro de artefactos y Spinnaker, TCS pudo desarrollar una canalización de implementación y de integración continua, automática, cerrada, basada en etiquetas que permitió iteraciones más rápidas, más flexibilidad y confiabilidad para su entorno en contenedores. Esta tubería permitió a TCS escalar sin problemas y agregar rápidamente nuevas funciones a medida que su juego ganaba más audiencia y reconocimiento.
Publicación traducida automáticamente
Artículo escrito por ddeevviissaavviittaa y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA