Spazio di sviluppo condiviso

Non sono sicuro che applicare un ambiente di sviluppo condiviso sia una buona idea, ma vorrei suggerire che ti stai concentrando sullo strumento sbagliato.

Mi sembra che quello di cui hai veramente bisogno sia un ambiente di sviluppo ben configurato con build notturne / integrazione continua e test automatici.

Non importa se sto codificando con vim in Ubuntu o con Eclipse in Windows se quando faccio un errore il sistema di test build / unit mi manda un'email arrabbiata che ho rotto qualcosa. Allo stesso modo, il suddetto sistema garantirebbe l'obiettivo di un software di migliore qualità molto meglio di quello di dettare un ambiente di sviluppo.

Mi sembra che qualunque sforzo tu voglia indirizzare verso un ambiente di sviluppo condiviso sarebbe meglio spendere per impostare ciò che ho descritto qui.

Se lo sviluppo debba o meno avvenire in un ambiente condiviso è una domanda sottile. La mia preferenza è di non farlo, semplicemente perché si adatta meglio. Ma sono anche un sostenitore di rendere il più semplice possibile l'aggiornamento dell'ambiente e mi piace vederlo accadere il più spesso possibile. Se tutti effettuano presto il check-in, effettuano spesso il check-in e si sincronizzano regolarmente, si dispone effettivamente di un ambiente condiviso, ad eccezione del conflitto di risorse o di una finestra per l'obiezione. Se le persone non lo fanno, un ambiente condiviso può essere d'aiuto.

Se gli sviluppatori non riescono a mantenere aggiornato il loro ambiente e quindi a fare affidamento sul comportamento deprecato, ciò potrebbe essere un sintomo di un problema più profondo. Vale a dire che gli sviluppatori stanno infrangendo il codice dell'altro. In tal caso, un problema di sviluppo condiviso potrebbe risolvere il problema immediato, ma potrebbe portare alla luce il problema sottostante. Siate consapevoli di ciò ed essere consapevoli che le persone possono incolpare l'ambiente condiviso perché è un obiettivo più semplice.

Ma il QA dovrebbe sicuramente svolgersi in un ambiente condiviso. Sembra che tu lo stia facendo. Per comprendere meglio i problemi di integrazione, ti consiglio vivamente di impostare il link per assicurarti che i test unitari in realtà accade in modo tempestivo, in un modo che può rintracciare i problemi per il commit che è in difetto. Assicurarti di avere una copertura di test unitaria sufficiente per vedere effettivamente i problemi è un secondo problema, ma ne vale la pena.

Ho visto accadere questo ... c'erano dei benefici, ma alcuni dei principali inconvenienti l'hanno reso una soluzione irrealistica a lungo termine quando l'ho visto.

• Coordinamento tra i tester
  • "Ciao a tutti, ho bisogno di fare un reset di IIS ..." e l'intero team aspetta
• Filiali di test di regressione (ovvero test su una build precedentemente rilasciata / supportata)
  • A meno che non sia possibile ospitare più versioni del software sullo stesso hardware, è necessario un nuovo ambiente.
• Test delle correzioni
  • Dev fa una correzione e la sottopone a test ... come si distribuiscono? Ridistribuire all'ambiente condiviso? Aspetta fino a domani per testarlo? Cosa succede se si tratta di una correzione ad alta priorità? È uno scenario più semplice e più sicuro per il QA da implementare in un ambiente privato ... e se quest'ultimo è lo scenario più comune, è banale da eseguire soprattutto con la distribuzione automatizzata.
• Test delle prestazioni
  • È necessario un hardware coerente e specifico con carichi coerenti e specifici (ovvero nessun altro tester su di esso, solo quelli simulati) per ottenere risultati prestazionali ripetibili e stabili

Detto questo, è stato un ottimo modo per battere 1 build specifica, usando tutti i tester testando manualmente le funzionalità. Ottenuto la squadra attraverso un paio di esercitazioni antincendio. A lungo termine però? È davvero disordinato.