Come posso organizzare un processo di distribuzione migliore? [chiuso]

Suggerirei integrazione continua di qualsiasi utile lavoro incrementale da qualsiasi sviluppatore in un unico ramo di integrazione, con QA automatizzato e manuale eseguito il più spesso possibile sul ramo dell'integrazione. Tutti sono sulla stessa pagina, non c'è spazio per "vagare" o sprecare sforzi e risorse per lucidare le modifiche (in singoli ambienti di sviluppo) che possono essere completamente invalidati quando si integrano con altri codici simili da altri ambienti di sviluppo individuali.

In tale ambiente puoi applicare in modo molto più efficace altre utili strategie di sviluppo del software come Agile , TDD , ecc.

Ad esempio, applicando Agile:

• i punti 1-4 si verificano tutti sullo stesso ramo / principale, simultaneamente. Le specifiche sono suddivise in molti piccoli pezzi che possono essere sviluppati, QA'd, UAT'd e consegnati in modo incrementale (in max alcuni giorni). Il cliente può vedere i risultati incrementali in anticipo, aggiustare in modo incrementale le specifiche minori e riordinarle in base alle esigenze. Lavorando più vicino con il cliente nei passaggi 1-4, il QA e l'UAT possono davvero diventare uno, il che è l'IMHO ideale. TDD può anche essere gettato nel mix qui.
• I passaggi 5-6 vengono eseguiti su versioni di breve durata (da 1 a 4 settimane, più sono brevi e migliori) (idealmente hanno appena selezionato etichette / tag CI / CD sul ramo principale), producendo principalmente nuove specifiche incrementali per successive versioni di questo tipo (invece di produrre richieste di supporto per versioni di vita più lunghe ciascuna nelle proprie filiali), fino a quando non si ottiene il prodotto finale soddisfacente per il cliente (molto più veloce che attraverso le iterazioni ripetute più lunghe che si hanno ora).
• I passaggi 5-6 per una versione vengono eseguiti in parallelo con i passaggi 1-4 per la versione successiva.

L'attenzione e le risorse del team sono principalmente indirizzate verso il raggiungimento della versione finale del prodotto che il cliente desidera invece di "vagare" supportando versioni non finali, che possono facilmente portare a costi di esplosione.

I test di accettazione dell'utente sono troppo tardi. Rischia di spendere molti sforzi per conformarsi esattamente ai requisiti che poi risultano non essere ciò di cui il cliente ha bisogno. Se possibile, coinvolgi gli utenti effettivi del software nel processo di controllo della qualità non appena c'è qualcosa da testare - non aspettare fino a dopo i tuoi tester pensano che sia perfetto.

Ci sono molte domande a cui è necessario dare una risposta qui:

• Stai utilizzando un vcs?
• Qual è la tua strategia di ramificazione?
• Puoi distribuire utilizzando un solo pulsante?
• Hai test automatici?
• Quando esegui i test?
• Hai un'integrazione continua?
• Cosa succede alla tua squadra mentre il lavoro è nell'area di Staging? Stai lavorando a qualcos'altro? O stai solo aspettando?
• Che succede con il team addetto al controllo qualità mentre la parte UAT sta succedendo?
• Quanto tempo impieghi per la distribuzione?
• La distribuzione significa che l'utente non può lavorare sul sistema?
• Hai un database? Puoi annullare una distribuzione sul tuo database?

Le basi di ciò che stai facendo va bene, soprattutto a causa di quel tratto lussuoso di avere una specifica completamente chiusa (mai successo a me). Ma le basi non ti semplificano la vita, né forniscono il miglior valore per la tua azienda.

Suppongo tu abbia un vcs. Quale strategia di ramificazione stai usando? Quelle strategie cambieranno in base al vcs. Vorrei scegliere una diversa strategia di ramificazione se sto usando Subversion / TFS Source Control o se sto usando quelli distribuiti come git o hg.

Esegui test (unità, integrazione, requisiti) e assicurati di poterli eseguire automaticamente. I test devono essere eseguiti su un ambiente CI che va tra l'ambiente di sviluppo e gli ambienti di gestione temporanea. Qualsiasi bug riscontrato dal team addetto al controllo qualità dovrebbe diventare un test automatico ove possibile (a seconda della tecnologia dell'interfaccia utente che non potrebbe essere sempre possibile). Queste azioni consentiranno di: ridurre il tempo speso in "Staging", ridurre il numero di bug visualizzati, ridurre il numero di errori di regressione che verranno visualizzati.

L'ambiente CI dovrebbe compilare ed eseguire automaticamente tutti i test (potrebbe essere ben possibile che tu voglia eseguire test unitari tutto il tempo, ma test di integrazione solo in un punto specifico del giorno). Questa azione fornirà alla tua squadra la certezza che non stai rompendo nulla o che lo saprai praticamente subito. Strumenti per CI? Jenkins, Team City, TFS, ...

A un certo punto stavo lavorando a un team in cui una distribuzione della nostra applicazione significava in genere un processo manuale di due ore che richiedeva la disconnessione di tutti gli utenti. Siamo riusciti a migliorarlo, anche se ancora manuale, a meno di 5 minuti con solo un riavvio per gli utenti se non ci fosse stato alcun cambio di database. Se c'era una modifica del database, richiedeva ancora mezz'ora di uscita degli utenti. Ma quando ho lasciato l'azienda, stavamo cercando di utilizzare strumenti (Octopus in questo caso) per renderlo ancora più semplice e una strategia verde / blu sul nostro database per eliminare completamente i tempi di inattività (tranne il riavvio dei terminali client).

Separerei completamente l'ambiente di staging per il QA interno dall'ambiente di staging per UAT. La mia precedente esperienza è molto confusa per averli insieme.

Avrei un ambiente di prelettura solo per testare la distribuzione nelle stesse identiche condizioni in cui ci sono in diretta. Ho avuto delle sorprese prima perché il nostro sistema dipendeva da qualche libreria o patch del sistema operativo presente in tutte le fasi, ma dal vivo.

Che quindi vorrà dire che c'è un'altra domanda, il tuo team IT può replicare l'installazione di live? Se non possono, dovrebbero lavorarci sopra. Il provisioning di una macchina / ambiente dovrebbe essere completamente automatico una volta che hai l'hardware.

Puoi sempre migliorare il tuo processo. All'inizio di solito puoi fare dei passi da gigante, più tardi, è più preciso. Dovresti chiedere a te stesso (e al tuo team) la domanda che hai postato ogni mese.

Quando qualcuno fa una domanda sul modulo "C'è un modo migliore per x ," la risposta è sempre sì. ^ _ ^

In generale, tuttavia, se la tua squadra raggiunge gli obiettivi e generalmente è soddisfatta del processo corrente, il costo di far oscillare quella barca spesso non vale la pena.