In che modo The Zebra è riuscita a realizzare pipeline sicure e prive di ambiguità

The Zebra è stata fondata per offrire ai clienti un modo più semplice per confrontare i fornitori di assicurazioni. Fondata nel 2012, The Zebra è un negozio di confronto di assicurazioni auto online che ricerca e offre le migliori tariffe disponibili. The Zebra si è recentemente ampliata offrendo il proprio servizio per proprietari di case e affittuari.

The Zebra usava GitHub come repository e Jenkins per i deployment. I team usano anche Terraform per il deployment su AWS. La quantità di plug-in Jenkins ha creato un'enorme mole di lavoro di gestione. Inoltre, la loro varietà ha causato varie vulnerabilità della sicurezza perché alcuni strumenti non erano più supportati o erano troppo fragili per essere aggiornati nell'ambiente di deployment.

"Il problema più grande era che stavamo usando Jenkins per eseguire i nostri deployment prima di GitLab. Abbiamo usato molti plug-in per questo. Il sistema era così fragile che nessuno voleva toccarlo", afferma Dan Bereczki, responsabile software senior. "Chiunque provasse a toccarlo lo danneggiava, e poi via di deployment per un'intera giornata per cercare di sistemare le cose o di mantenerle aggiornate."

I team volevano migliorare il processo di CI/CD esistente, ma ciò significava aggiungere plug-in a Jenkins, complicando ulteriormente il livello di manutenzione esistente. The Zebra aveva bisogno di una nuova soluzione che integrasse test e sicurezza, oltre a consentire il deployment su una varietà di piattaforme diverse.

The Zebra ha studiato varie piattaforme per sostituire i plug-in esistenti e diminuire lo stress della gestione. Hanno adottato GitLab perché fornisce un repository avanzato senza necessità di gestire i plug-in. Le funzionalità di CI/CD erano il punto di forza.

Inoltre, i team non vedevano l'ora di adottare GitLab perché offre funzionalità che altre soluzioni non forniscono, come ad esempio la sicurezza integrata. "Tutti si sono resi conto di quanto controllo in più avessero sui loro processi e di quanto fosse facile effettuare la transizione. Siamo riusciti a completare la migrazione in meno di tre mesi", dice Bereczki. Il 95% del codice Jenkins è stato migrato in quel periodo e da allora l'azienda si è del tutto allontanata da Jenkins e GitHub.

Tutti e sei i team di sviluppo delle applicazioni, e anche altri team al di fuori dello sviluppo, usano GitLab. "Ora, invece di avere solo una manciata di persone che comprendono le complessità di Jenkins e che possono risolvere i problemi, tutti sanno come lavorare con la pipeline di GitLab", dice Bereczki. I team sono passati dall'usare 3 strumenti (GitHub, Codeship CI e Jenkins Deploy) alla sola CI/CD di GitLab, completamente integrata e automatizzata.

Con GitLab, The Zebra può dedicarsi al deployment continuo, proprio perché i team possono eseguirlo a proprio piacimento senza intaccare la tabella di marcia. Così tutti i team di sviluppo ricoprono un ruolo più importante nel processo di deployment, perché capiscono come funziona la pipeline CI e possono lavorarci direttamente. Inoltre, l'infrastruttura non rappresenta più un collo di bottiglia per il deployment.

Il flusso di lavoro di solito inizia con una richiesta da parte del team di marketing. Da lì, diventa una descrizione tecnica che viene suddivisa in una serie di ticket JIRA assegnati poi al team appropriato. Dopo averci lavorato, il codice viene generato e inserito nel repository di GitLab. Dopodiché, il team userà la pipeline CI/CD di GitLab per eseguire il deployment nell'ambiente di sviluppo. Terraform viene usato per implementare l'Infrastructure as Code per garantire che le modifiche alla configurazione vengano mantenute durante tutto il processo di test e deployment.

I team usano Amazon EKS con RDS. Il routing del traffico viene inizialmente gestito da Cloudflare, poi dal bilanciamento del carico elastico interno. Quando gli sviluppatori devono connettere i servizi di The Zebra a servizi esterni di terze parti, usano Amazon Virtual Private Cloud. "Non vogliamo sistemi stile scatola nera, di cui nessuno conosce il funzionamento. Di quei sistemi ce ne stiamo lentamente sbarazzando", dice Bereczki.

GitLab ha consentito relazioni interfunzionali tra i team di sviluppo, proprio perché ora detengono la responsabilità del proprio codice fino alla fine della produzione. Gli sviluppatori possono comprendere ogni fase del deployment e possono risolvere eventuali problemi e apportare modifiche senza preoccuparsi di interrompere il flusso di lavoro.

SAST e DAST di GitLab semplificano la conformità per la certificazione SOC2 Type 1, tant'è che ora i team sono a un passo dalla certificazione SOC2 Type 2. Ha inoltre fornito ulteriori test e misure di sicurezza per ridurre il rischio. "L'impatto maggiore è che abbiamo un sacco di vulnerabilità che non sapevamo ci fossero, ed è proprio su queste che ci stiamo concentrando. Le stiamo sistemando", afferma Bereczki. Finora sono state sistemate tutte le criticità più importanti identificate su quattro progetti. "La cosa bella è che non dovremo più recuperare il tempo perso quando programmeremo un test di penetrazione o quando eseguiremo i test trimestrali o semestrali, perché ora fanno parte della pipeline", aggiunge Bereczki.