Cómo consiguió The Zebra pipelines seguros en blanco y negro

Zebra se creó para ofrecer a los clientes una forma simplificada de comparar proveedores de seguros. Fundado en 2012, The Zebra es un comparador de seguros en línea que investiga opciones de seguros de automóviles y ofrece las mejores tarifas disponibles. The Zebra se ha expandido recientemente a los seguros de propietarios e inquilinos.

The Zebra utilizaba GitHub como repositorio y Jenkins para las implementaciones. Los equipos también utilizaban Terraform para el implementar en AWS. La cantidad de plugins de Jenkins creaba una cantidad abrumadora de trabajo de gestión. Además, la variedad de plugins provocaba vulnerabilidades de seguridad porque algunas herramientas ya no eran compatibles o eran demasiado frágiles para actualizarlas en el entorno de implementación.

«El mayor problema que teníamos era que usábamos Jenkins para realizar las implementaciones antes de GitLab. Pusimos suficientes plugins en eso. Era tan frágil que nadie quería tocarlo», dijo Dan Bereczki, gerente de Software sénior. «Cualquiera que intentara tocarlo lo rompía, y entonces las implementaciones se interrumpían medio día o un día para intentar arreglar las cosas, o mantener todo actualizado».

Los equipos querían mejorar el proceso de CI/CD existente, pero eso significaba agregar plugins a Jenkins, lo que complicaba aún más el nivel de mantenimiento existente. The Zebra necesitaba una nueva solución que integrara pruebas y seguridad, además de permitir implementaciones en diversas plataformas.

The Zebra investigó una variedad de plataformas para reemplazar los plugins existentes y aliviar el estrés de la gestión. Adoptaron GitLab porque proporciona un repositorio mejorado sin tener que gestionar plugins. Además, las capacidades de CI/CD eran el argumento de venta.

Los equipos estaban ansiosos por adoptar GitLab porque ofrece funcionalidades que otras soluciones no ofrecen, como la seguridad integrada. «Las personas se dieron cuenta de cuánto más control tenían de sus procesos y de lo fácil que era hacer la transición. Hicimos la migración en menos de tres meses», señaló Bereczki. El noventa y cinco por ciento del código de Jenkins se migró en ese momento, y desde entonces han abandonado por completo Jenkins y GitHub.

Los seis equipos de desarrollo de aplicaciones e incluso algunos equipos ajenos al desarrollo utilizan GitLab. «Ahora, en lugar de una o dos personas que entienden las complejidades de Jenkins y pueden arreglar las cosas que son problemáticas, todos saben cómo trabajar con el pipeline de GitLab», afirmó Bereczki. Los equipos pasaron de usar tres herramientas (GitHub, Codeship CI y Jenkins Deploy) a usar solo la CI/CD de GitLab, totalmente integrada y automatizada.

Con GitLab, The Zebra ahora puede centrarse en avanzar hacia la implementación continua porque los equipos pueden implementar a voluntad, sin esperar otros calendarios. Todos los equipos de desarrollo desempeñan un papel más importante en el proceso de implementación porque entienden cómo funciona el pipeline de CI y pueden trabajar dentro de él. Además, la infraestructura ya no es un cuello de botella para la implementación.

El flujo de trabajo suele comenzar con una solicitud de marketing. A partir de ahí, se convierte en un resumen técnico que se divide en un conjunto de tickets de JIRA y luego se asigna al equipo correspondiente. Luego, se trabaja en él, se genera el código y se introduce en el repositorio de GitLab. A continuación, el equipo utilizará el pipeline de CI/CD de GitLab para implementarlo en el entorno de desarrollo. Terraform se utiliza para implementar infraestructura como código con el fin de garantizar que los cambios de configuración se mantengan durante todo el proceso de prueba e implementación.

Los equipos usan Amazon EKS con RDS. El enrutamiento del tráfico es gestionado inicialmente por Cloudflare, luego por Elastic Load Balancing interno. Cuando los desarrolladores necesitan conectar los servicios de Zebra a servicios externos de terceros, utilizan Amazon Virtual Private Cloud. «No queremos sistemas que sean una caja negra de la que nadie sabe cómo funciona. Poco a poco nos estamos deshaciendo de eso», dijo Bereczki.

GitLab ha permitido relaciones interfuncionales entre los equipos de desarrollo porque ahora son dueños de su propio código hasta el final de la producción. Los desarrolladores pueden comprender cada paso de la implementación y solucionar cualquier problema y realizar cambios sin preocuparse por interrumpir otras partes del flujo de trabajo.

SAST y DAST de GitLab facilitan el cumplimiento de la certificación SOC2 Tipo 1 y ahora los equipos están en medio de la certificación SOC2 Tipo 2. También ha proporcionado pruebas adicionales y medidas de seguridad que reducen su riesgo. «El mayor impacto es que tenemos un montón de vulnerabilidades que ni siquiera sabíamos que estaban ahí, con las que estamos lidiando ahora mismo. Las estamos corrigiendo», afirma Bereczki. Hasta ahora han eliminado todos los puntos críticos y e alta prioridad identificados en cuatro proyectos. «Lo bueno es que, como ya forma parte del pipeline, no tendremos que ponernos al día cuando programemos una prueba de penetración o cuando realicemos pruebas trimestrales o semestrales», agregó Bereczki.