Responsabilità dell'ambiente di distribuzione

Nello sviluppo moderno, il team dovrebbe essere responsabile dell'analisi del progetto, della progettazione (gli architetti possono allineare la progettazione imperfetta), dello sviluppo, dei test unitari, del test automatico QA / UAT / PERF, distribuirlo in tutti gli ambiti, operare e monitorare in produzione fino al il progetto viene dismesso da PROD o non utilizzato dai clienti.

Le moderne pratiche di sviluppo coinvolgono l'automazione di tutto in una singola generazione, test, implementazione di una pipeline.

L'idea è di fornire alla piattaforma del team servizi self-service, in modo che il team possa raggiungere tutti i compiti sopra citati con la più piccola interazione esterna possibile. Qualsiasi sistema di emissione di biglietti è un onere che dovrebbe essere modificato in modalità self-service.

Quindi in tale ambiente dovrebbero avere membri del team interfunzionali (SÌ a volte gli sviluppatori scrivono test non unitari e si svegliano di notte se l'applicazione non funziona). L'idea è di avere esperti di squadra in ciascuna area del processo di sviluppo e i membri del team di mentori non hanno familiarità con determinate abilità. Così puoi finire con quel tester o l'ingegnere delle operazioni ti terrà sotto controllo.

Sei fortunato se stai già lavorando in tale azienda, ma se non è almeno investendo e cercando di convertirsi verso la completa automazione Continuous Delivery / Deployment, è il momento di cambiare compagnia!

Diversi esempi mi sono imbattuto in:

1. Gli ambienti di produzione e test / dev hanno un diverso set di funzionalità. Ad esempio, un progetto su cui ho lavorato includeva aggiornamenti programmati di stato. Nell'ambiente di produzione, gli aggiornamenti venivano pianificati una volta alla settimana, ma negli ambienti di sviluppo e testing, avevamo bisogno che lo stato cambiasse più frequentemente o venisse attivato manualmente. Quindi avevamo un kill-switch per cambiare manualmente lo stato.
2. Evitare conflitti tra i test eseguiti da diversi team. Quando si cercano i difetti, essere in grado di riprodurre i difetti è estremamente importante. Avere più team che lavorano sullo stesso ambiente può renderlo difficile, poiché i passaggi che rivelano il difetto potrebbero essere il risultato delle azioni di più squadre (accidentali) che attraversano. JUnit, il famoso framework di test unitario, crea oggetti separati per ciascuno dei casi di test. Questo viene fatto in modo che ogni caso di test sia isolato e non influisca su altri casi di test. Lo stesso principio si applica qui. Invece di coordinare i piani di test di più team, ogni team lavora su un ambiente diverso.
3. Diverse piattaforme, che ospitano il prodotto. Se il prodotto supporta più piattaforme, dovrebbe essere testato su ciascuna di esse. Inoltre, dovrebbe essere testato su ciascuna versione di ciascuna piattaforma supportata (Windows XP, Windows 7, Windows 8, ecc.). Ciascuno richiede un ambiente separato. Gli scenari di aggiornamento sia del prodotto che della piattaforma aumentano anche il numero di ambienti necessari.
4. Test di stress, test di stabilità. Alcuni test richiedono che il prodotto abbia un carico di lavoro elevato. Altri testano la stabilità, in modo che l'ambiente debba essere attivo per un lungo periodo di tempo. Questi tipi di test richiedono ambienti dedicati.
5. Impostazioni in conflitto. Ad esempio, il team che verifica la localizzazione deve cambiare la lingua dell'ambiente più volte. Ciò può causare inconvenienti agli altri team, che non hanno familiarità con tutte le lingue supportate.

Nella mia esperienza, il team addetto al controllo qualità è responsabile della creazione e della manutenzione degli ambienti. Ma per fare ciò correttamente, il team addetto al controllo qualità deve avere un elenco chiaro dei punti precedenti, inclusi i tipi di distribuzione, le piattaforme, le impostazioni e le funzionalità supportate per poter creare un piano di test adeguato.