Velocità di rilascio senza incidenti: cosa offre il moderno outsourcing di QA e DevOps

Il compromesso che non dovrebbe esistere

La maggior parte delle organizzazioni di ingegneria vive la velocità di rilascio e l'affidabilità come forze contrapposte. Rilascia più velocemente e rilasci più bug. Rilascia con cura e rilasci lentamente. I team finiscono per rilasciare di rado, il che rende ogni rilascio più grande e più rischioso, il che li porta a rilasciare ancora meno spesso. È una trappola che si autoalimenta, e vincola la roadmap con la stessa certezza di qualsiasi carenza di risorse.

La trappola non è una legge di natura. È il sintomo di un'infrastruttura mancante: test inaffidabili e rilasci manuali, tutto o niente. Sistemate l'infrastruttura e il compromesso si dissolve. È questo che il moderno outsourcing di QA e DevOps, fatto bene, offre davvero.

La fiducia prima della copertura

L'istinto quando l'automazione dei test è debole è aggiungere più test. Di solito è la prima mossa sbagliata. Una suite di test di cui gli ingegneri non si fidano, una che fallisce in modo intermittente per ragioni non legate a difetti reali, è peggiore di una suite più piccola ma affidabile, perché gli ingegneri imparano a rieseguire i fallimenti anziché indagarli, e i fallimenti genuini vengono liquidati come instabilità.

La prima mossa giusta è rendere affidabile la suite esistente. Ridurre il tasso di instabilità finché una build rossa significhi in modo affidabile un problema reale. Solo allora ampliare la copertura, ed ampliarla dove il rischio risiede davvero, guidati dallo storico degli incidenti in produzione e dal turnover del codice anziché dall'inseguimento di una percentuale di copertura. Una suite affidabile con copertura moderata vi protegge meglio di una inaffidabile con copertura elevata.

Disaccoppiare i rilasci dal rischio

La seconda metà della risposta è la delivery progressiva. Feature flag, distribuzioni canary e rollback automatico separano l'atto di distribuire il codice dall'atto di rilasciare una funzionalità agli utenti. Una modifica può andare in produzione dietro un flag, essere esposta a una piccola porzione di traffico, essere osservata ed essere annullata immediatamente se qualcosa non va, il tutto senza un ciclo di rilascio completo.

È questo che permette alla frequenza di rilascio di salire senza che la gravità degli incidenti salga con essa. Quando un rilascio comporta il rischio dell'intera piattaforma, i team rilasciano di rado. Quando il rischio è disaccoppiato e reversibile, rilasciano costantemente e in sicurezza. Le organizzazioni passano da una manciata di rilasci al mese a un rilascio settimanale per team o migliore, mentre i difetti critici sfuggiti calano anziché salire.

Perché il nearshore si adatta a questo lavoro

QA e DevOps sono intensivi in collaborazione. Vivono all'interno delle cerimonie del team di ingegneria, della sua risposta agli incidenti e delle sue decisioni architetturali. È per questo che il fuso orario conta così tanto specificamente per queste funzioni. Un team nearshore in Colombia, sulla stessa giornata lavorativa di un'organizzazione di ingegneria nordamericana, partecipa anziché consegnare. E i migliori incarichi sono strutturati in modo che il cliente finisca per possedere la suite affidabile e la pipeline di delivery, gestite dai propri ingegneri, anziché noleggiarle a tempo indeterminato. Il compromesso tra velocità e affidabilità è reale solo finché manca l'infrastruttura. Costruitela, e potrete rilasciare più velocemente e rompere di meno allo stesso tempo.