come rimanere efficienti quando una build è quasi sempre rotta

Lavoro in un team di medie dimensioni che condivide lo stesso codice sorgente e mentre ha una continua integrazione in atto, ma poiché tutti noi dobbiamo lavorare nello stesso ramo, la build è quasi sempre interrotta.

Poiché abbiamo anche una regola, che è stata introdotta di recente per alleviare le build rotte, che afferma che a nessuno è consentito effettuare il check-in mentre la build è rossa.

Detto questo, durante un giorno tutti hanno una manciata di finestre di 10-15 minuti in cui abbiamo permesso il check-in.

E mentre il team sta crescendo, le finestre delle opportunità di check-in si riducono ancora di più. Ciò costringe gli sviluppatori ad accumulare le loro modifiche localmente, il che si traduce in una serie di modifiche più ampia che rende ancora più difficile garantire che le modifiche non rompano nulla. Puoi vedere il circolo vizioso.

Cosa mi puoi consigliare per permettermi di rimanere efficace lavorando in un ambiente come questo. Inoltre, tieni presente che sono uno sviluppatore, non un manager, e non posso cambiare molto il processo o il comportamento di altre persone.

Per cominciare, questo commento:

... avere una filiale implica un'ulteriore complessità e quindi un lavoro extra ...

è totalmente falso. Lo sento spesso da persone che non sono abituate alla ramificazione, ma è ancora sbagliato.

Se molti sviluppatori accumulano modifiche localmente, le loro modifiche locali costituiscono di fatto un ramo del repository principale.

Quando finalmente spingono, questa è un'unione di fatto .

Il fatto che i rami e le fusioni siano impliciti non rimuove la complessità aggiuntiva di cui ti preoccupi, la nasconde e basta. La verità è che rendere esplicito questo processo potrebbe aiutarti (plurale = l'intero team) ad imparare a gestirlo.

Adesso dici

a nessuno è consentito effettuare il check-in mentre la compilazione è rossa

ma in questo caso la build non può mai essere riparata, quindi non può essere abbastanza precisa.

In generale, se è ragionevole costruire localmente (cioè la build non è troppo grande o lenta), gli sviluppatori dovrebbero farlo prima di spingere comunque.

Suppongo che questo non sia il caso, perché in primo luogo non avrebbero spinto build rotte, ma sarebbe bello se tu potessi chiarire questo punto.

In generale la risposta a

come rimanere efficienti quando una build è quasi sempre rotta

è: smettere di rompere la build .

gli sviluppatori ... accumulano le loro modifiche localmente ... Puoi vedere il circolo vizioso.

È davvero vizioso. Accumulare cambiamenti localmente è una grande bandiera rossa che indica che qualcosa è gravemente marcio nel processo di sviluppo. In un certo senso distrugge l'intero scopo di avere un sistema di controllo della versione .

Fintanto che vuoi stare lontano dal cambiare il processo o il comportamento di altre persone, la soluzione più naturale sarebbe quella di creare il tuo ramo e usarlo per "accumulare" le tue modifiche (per essere ulteriormente integrato con il ramo del team quando ottieni un opportunità).

In realtà, se ci sono più ragazzi come te, puoi persino collaborare e stabilire un ramo di sviluppo condiviso per scambiare liberamente i tuoi aggiornamenti senza essere interferito con idee di gestione incompetenti. Le ramificazioni consentono molti modi diversi per semplificare il lavoro di squadra.

• ^{Nota a margine, ogni volta che quel manager fa o dice qualcosa che ti costringe a evitare impegni, a mantenere il codice localmente, a tradurre le loro parole in grassetto e semplice "I am incompetent" .}

tieni presente che sono uno sviluppatore, non un manager e non posso cambiare molto il processo o il comportamento di altre persone ...

Per motivi di precisione, in realtà puoi , queste sono questioni di influenza e abilità comunicative e non c'è davvero bisogno di essere in grado di cambiare le cose a loro piacimento (cerca nel web qualcosa come "gestisci" se sei interessato a maggiori dettagli).

Comunque è piuttosto ingombrante e richiede molto sforzo e posso capire perfettamente se si preferisce semplicemente rimanere concentrati sulla programmazione, con scarso coinvolgimento in politica - quindi se non vuoi (anche se in teoria puoi ), è comprensibile. :)

Sono sensibile all'idea che ti senti impotente a cambiare l'ambiente, ma penso che questa situazione sia una seria sfida alla tua professionalità come programmatore.

Cosa accadrebbe se un chirurgo conservasse bisturi sporchi con quelli puliti? Cosa succederebbe se un idraulico non testasse i tubi che ha installato? Cosa accadrebbe se un violinista suonasse sempre stonato con l'orchestra?

Perché i programmatori dovrebbero essere esenti dal lavoro di squadra e dalla cortesia comune? Come membro di quella squadra, condividi la responsabilità per il risultato. È irresponsabile ignorare la squadra poiché sabota i propri sforzi.

Sono curioso di sapere da dove viene la regola che "nessuno è autorizzato a fare il check-in mentre si costruisce è rosso"? È una buona regola se ciò poi focalizza tutti sul correggere la build. Vorrei provare a dare l'esempio e aiutare a correggere la build ogni volta che è rotto. Ammettiamolo, non stai facendo nient'altro comunque. Se questo ti dà fastidio, suggerirei di esprimere quelle preoccupazioni. La voce di qualcuno che cerca attivamente di migliorare una situazione ha più influenza del tipo che brontola in un angolo.

Penso che fintanto che pensi di essere "solo uno sviluppatore" e quindi non puoi cambiare le cose che soffrirai di questo problema.

Quello che devi fare è che devi ripristinare ogni commit dal repository ogni volta che qualcuno rompe la build e poi dire a quel ragazzo che ha appena rotto la build e che deve fermarsi. Devi anche spiegare questa situazione al manager e dirgli che la produttività della tua squadra sta soffrendo a causa di questo problema.

Devi fare tutto il possibile per cambiare meglio il processo e piuttosto dire che ti dispiace più tardi invece di chiedere l'autorizzazione.

Penso che tu e il tuo team vi troviate in una situazione in cui il processo deve essere modificato e non potete lavorare in modo efficiente con quel modello rotto. Penso anche che sia tua responsabilità fare qualcosa al riguardo dopo averlo riconosciuto. Se nessun altro farà qualcosa per risolvere il problema, sei tu quello che deve farlo!

Posso relazionarmi con la tua condizione, ho affrontato una situazione simile con il mio progetto più recente al lavoro. Abbiamo finito per implementare una sorta di sistema di "patata bollente" in cui lo sviluppatore che ha recentemente rotto la build ha dovuto baby-sitter / baby sitter / monitorarlo fino a quando non è stato risolto e superato tutti i nostri test di verifica.

Questo ha avuto successo perché i test di build e verifica hanno richiesto circa 4 ore, quindi interrompere la build significava perdere mezza giornata a fare un vero lavoro. Inutile dire che ciò ha portato gli sviluppatori a utilizzare le filiali in modo più efficiente prima di unirle nel trunk. Per la maggior parte degli sviluppatori, la mentalità precedente era "Lascerò che il sistema di compilazione degli elementi della configurazione mi informi se il mio codice è rotto".

Una semplice modifica al sistema CI lo farebbe: qualsiasi modifica che interrompe la build viene automaticamente ripristinata. Ancora meglio, lascia che il repository CI diventi un'area di gestione temporanea, in cui le modifiche vengono trasferite al repository autorevole solo quando la build è verde. Strumenti come Gerrit possono aiutare qui.

Altre due cose potrebbero aiutare qui:

• il tuo team può testare il fumo di un CI costruito localmente? Se controlli di non infrangere la build - o almeno non di rompere la build in modi comuni senza dover impegnare e innescare la gestione e l'ira del team.
• ci sono molti modi per definire build rotte a seconda di come si progetta CI. Ciò include la definizione di rotture: in fase di forte sviluppo non consideriamo il fallimento dei test una pausa ma piuttosto un altro obiettivo a cui puntare.

Ma dovresti davvero guardare ai rami.