come migliorare la stabilità della build in una squadra

3

Stiamo lavorando a un progetto software, un team di 5-10 sviluppatori. Il codice base è continuamente integrato usando Bamboo. Abbiamo un piano di costruzione che esegue anche test di unità e integrazione e quindi un piano di test funzionale. Riceviamo e-mail automatiche sui guasti, ma a volte i giorni passano prima che un piano fallito venga corretto.

Domanda: come possiamo migliorare i nostri processi / strumenti per far sì che le persone risolvano i guasti più velocemente? Quali strumenti / processi hai?

Modifica: stiamo lavorando con i rami di funzionalità, ma i lavori di Bamboo vengono eseguiti solo sul ramo principale. È presente un gancio Git che consente a una persona di disabilitare la spinta fino a quando Bamboo è verde. Può essere una soluzione per automatizzare questo, anche se abbiamo alcuni vincoli di sicurezza nella parte Ops e potrebbe non essere possibile.

Modifica: la build con unità e amp; i test di integrazione durano 20 minuti, il piano dei test funzionali è programmato due volte al giorno e dura circa 2h

    
posta GabiM 23.06.2017 - 14:41
fonte

2 risposte

7

Come hai già le notifiche di build falliti, correggerli è principalmente un problema di persone.

Dovresti ottenere un accordo tra i membri del team sul fatto che una build distrutta è un problema serio che deve essere risolto prima di ogni altra cosa.
Finché la build rimane rotta, dovresti accettare che

  • nessuna opera può essere contrassegnata come completata, a meno che non si possa dimostrare che tutti i commit sono stati inclusi nell'ultima build completata.
  • non è possibile creare nuove unioni al ramo principale a meno che non si risolva il problema che causa il fallimento della generazione.

Se la compilazione si interrompe spesso, è necessario indagare sul motivo per cui ciò accade e su quali contromisure è possibile adottare.
Una possibilità qui sarebbe di vedere se è possibile mettere un processo sul posto in cui il ramo della caratteristica viene costruito su Bamboo prima di essere unito al ramo principale. O ancora meglio, il risultato proiettato dall'unione dovrebbe essere costruito. Solo se questa build del branch / merge è verde dovrebbe essere eseguita l'unione effettiva.

    
risposta data 23.06.2017 - 15:16
fonte
4

Ci sono un paio di cose che cambierei nel processo di compilazione, perché prima si individuano i problemi più è facile correggerli:

  • Fai eseguire la build su ogni ramo e richiama . Ciò include i rami di funzionalità e tutti i test di unità dovrebbero essere eseguiti contro quella build.
  • Mantieni i test funzionali a lungo termine solo contro il ramo principale
  • Evita di unire una richiesta pull finché entrambi il ramo della funzione e la richiesta pull sono verdi.

L'ultimo bit è molto utile sia per evitare l'unione di codice non corretto che per forzare lo sviluppatore a gestire le interruzioni prima che vengano unite. La via da seguire sarebbe che lo sviluppatore estragga dal ramo principale, aggiusti le parti in cui sono fuori fase e quindi crea una nuova richiesta di pull.

La prima volta che ho avuto questo automatizzato era con Github e Appveyor CI. È utile sapere se la tua unione sta per interrompere i test prima che sia effettivamente unificata.

Se riscontri ancora problemi con frequenti interruzioni di build, puoi consultare quanto segue:

  • Il problema è uno sviluppo scadente o l'architettura del codice è fragile?
  • Forse introdurre una penalità. L'ultima società che ho lavorato per te ha pagato $ 1 se hai rotto la build. Quel denaro è andato per eventi di team building come happy hours o cose del genere.
  • Trova i modi per rendere il codice resiliente architettonicamente.
risposta data 23.06.2017 - 19:34
fonte

Leggi altre domande sui tag