Soluzioni per prevenire la rottura del build

-1

Qualche contesto alla mia domanda: abbiamo un codice base C ++ tradizionalmente basato su Windows che stiamo eseguendo il porting su linux. Parti del sistema sono in esecuzione su Linux da molti anni, ma alcune parti non sono mai state costruite usando alcun compilatore diverso da Visual Studio. La maggior parte del codice è in Subversion e usiamo Jenkins per la costruzione automatica.

La mia domanda è: date le circostanze (Windows + Linux, C ++, Subversion, Jenkins), ci sono buone soluzioni per impedire agli sviluppatori di distruggere build su altre piattaforme ? Costringere gli sviluppatori a creare manualmente su ogni piattaforma supportata non è un metodo particolarmente efficace.

(So che ci sono soluzioni basate su git (ad es. Gerrit) che possono impedire a commit di renderlo nella linea principale, ma il passaggio a Git non è un'opzione al momento.)

    
posta JesperE 19.03.2018 - 13:47
fonte

2 risposte

6

Hai bisogno di una build prima di poterla infrangere. Stai già usando Jenkins? Grande! Ora aggiungi un box Linux come slave di build e crea una build per Linux che rispecchia le build di Windows.

Nota che i tuoi requisiti - la rottura deve essere impedita , ma non vuoi che i commit gated - siano un po 'contraddittori. Ma il test non deve essere tutto o niente. Invece, avvisare gli sviluppatori della rottura è ancora utile quando accade dopo il fatto. Possono quindi correggere la rottura.

Sfortunatamente, funziona solo se

  1. si inizia con una build che funziona su Linux e
  2. ogni volta che il build si rompe, è corretto prima vengono fatti altri commit.

Se gli sviluppatori possono impegnarsi in una build scadente, impareranno a ignorare il risultato della build di Linux, rendendolo quasi inutile.

È anche nel tuo interesse abilitare test facili su Linux prima di commetterli, in quanto ciò può evitare molte rotture. Per esempio. potrebbero essere macchine virtuali o accessi SSH preconfigurati con un ambiente di sviluppo o uno strumento per attivare processi personalizzati su Jenkins. Questo è diverso da forzare gli sviluppatori per costruire su Linux. Al contrario, possono soppesare i rischi se una modifica deve essere testata dalla build di Jenkins dopo il commit o se la modifica è più rischiosa e deve essere prima verificata manualmente. Se utilizzare l'ambiente Linux è sufficientemente conveniente, questo è un gioco da ragazzi.

Mentre stai ancora effettuando la transizione al supporto multipiattaforma, è meglio evitare gli avvisi automatici e lasciare che un team separato esegua il porting utilizzando il proprio flusso di lavoro. Ogni volta che raggiungono qualche sotto-obiettivo, è sensato aggiungere immediatamente questo come un lavoro di Jenkins per evitare regressioni future. Per esempio. i passaggi intermedi potrebbero essere che un componente può essere compilato su Linux o che la build funzioni utilizzando MinGW (vale a dire, ancora su Windows ma con un compilatore non MSVC) o che sia possibile attivare un avviso aggiuntivo.

Naturalmente, niente di tutto questo è una soluzione completamente tecnica. Gli strumenti da soli non possono risolvere i tuoi problemi, ma possono aiutare notificando gli sviluppatori sui problemi che si presentano. Più importante degli strumenti è che gli sviluppatori usano i loro strumenti (perché li trovano veramente utili), e che tu hai qualcuno che può costruire e configurare gli strumenti che gli sviluppatori in realtà hanno bisogno.

    
risposta data 19.03.2018 - 18:56
fonte
0

Con l'arrivo di Docker negli ultimi anni, ho scoperto che costruire su molte piattaforme diverse non è così doloroso come un tempo, anche manualmente. Con poco sforzo, puoi avere una serie di immagini Docker leggere per creare la build per te (ad esempio, Ubuntu x86 e x64, CentOS 6 e 7, diverse versioni di libc ...) Se stai solo testando che quelle versioni effettivamente costruiscono , è una soluzione molto fattibile. Ovviamente, se non è possibile automatizzarlo prima di impegnarsi effettivamente, deve esserci una strong volontà del team di applicare questa nuova politica di "costruire ovunque prima di impegnarsi".

Naturalmente, stiamo solo testando la "costruibilità" del software. I test di accettazione o integrazione sono bestie diverse (che probabilmente richiedono soluzioni più pesanti e costose). E anche in quel caso, ti incoraggio a farlo anche tu. È difficile vedere quanto sia bello farlo sistematicamente a lungo termine, specialmente durante la fase di manutenzione, ma posso dirti che porta molta calma alle tue notti.

    
risposta data 19.03.2018 - 21:13
fonte

Leggi altre domande sui tag