Software deploy: addio alla fase di staging?

I server destinati alla fase di staging e non solo sono destinati a scomparire sul medio termine grazie alla rivoluzione DevOps 2.0

Addio alla fase di staging?

Edith Harbaugh ha spiegato sulle pagine del portale Readwrite perchè la fase di staging sia destinata a scomparire dal classico iter di sviluppo, elencando i vantaggi che tale scelta apporterebbe e la metodologia che ha iniziato a sostituire il passaggio di “pre-produzione”.

L’editorialista esordisce parlando di come la rivoluzione DevOps 1.0 abbia notevolmente agevolato la vita degli sviluppatori grazie a soluzioni come Puppet, Ansible, Chef: quel che in passato richiedeva ore di lavoro è divenuto una questione di minuti. A fronte dell’accelerazione subita dal workflow anche la stessa idea di “build software” ha iniziato a traballare, non essendo in sostanza più al passo con i tempi, aggiunge. Ed il mantenimento di sistemi separati per le fasi di QA (Quality Assurance), staging e production sarà ugualmente superato dall’avvento della rivoluzione DevOps 2.0 (viene menzionato l’agile deployment) perchè tale impostazione presenta le seguenti criticità:

  • dispendio di tempo. Per la correzione di un bug rilevato in fase di produzione possono trascorrere anche delle ore. Il fix va infatti verificato prima in QA e poi in staging. Solo dopo diverse sessioni di test potrà infine approdare in produzione;
  • difficoltà di coordinamento. Il mantenimento di tre server separati (QA, staging, production) porta ad una serie di problematiche quali impossibilità di replicare certi bug in QA (per via dei data set differenti rispetto a coloro che lavorano in staging e produzione) ed un’elevata probabilità di complicare il workflow stesso (confusione tra reparti e beta tester);
  • budget. La fase di staging, con la simulazione dei carichi di lavoro che si ipotizzano per la successiva fase di produzione, incide sul budget aziendale (dai 3000$ ai 30000$ nel caso dell’editorialista – CEO e cofondatore di LaunchDarkly;

Dallo sviluppo alla produzione, ma come?

Secondo Edith Harbaugh il futuro dell’iter di sviluppo è rapprensentato dai feature flags o feature toggles, alcune righe di codice che inserite nell’applicazione di turno consentono di attivare o disattivare certe funzionalità per un determinato gruppo di utenti.

I feature flags “trasportano” quindi le modifiche apportartate dallo sviluppo alla produzione eliminando la fase di staging. Vengono meno anche i tre ambienti separati perché l’approccio “on / off” consente di eseguire il “vecchio iter” di operazioni in un solo server: è bene sottolineare che non si parla di un futuro lontano ma del presente: varie compagnie  (es: Facebook), aggiunge, utilizzano già tale sistema.

I feature flags pongono rimedio alle criticità del vecchio modello offrendo diversi vantaggi come afferma l’editorialista – che riporta la dichiarazione di Sam Hatoum (founder Xolv.io): “con i feature flags siamo in grado di effettuare il deploy delle nuove funzionalità direttamente in produzione nascondendole [tuttavia] ai clienti fin quando non siamo effettivamente pronti. E poco prima del rilascio ufficiale, per effetturare i nostri consueti test possiamo affidarci agli utenti che hanno [aderito alla fase di beta testing]. [In questo modo] abbiamo non solo aumentato la qualità delle feature inserite [ma anche velocizzato l’iter generale di sviluppo]”.

 

 

 

Facci sapere cosa ne pensi!

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *