Integrazione continua e un rifattore massiccio

2

Attualmente sto rielaborando una parte della nostra applicazione al lavoro. Sto normalizzando una struttura dati da un semplice elenco di campi a una relazione genitore / figlio. Ciò ha un impatto su tutti i livelli nell'applicazione:

  • Il database
  • Modelli
  • Logica aziendale; e
  • L'interfaccia utente

Invece di creare alcuni commit massicci - in cui ogni commit si compila - ho deciso di scomporlo in un gran numero di piccoli commit (accettando che la build si interromperà). Perché? Quindi posso ripristinare / eliminare rapidamente le mie modifiche.

Il mio piano era di mantenere i commit locali fino a quando l'intera cosa veniva compilata e quindi sincronizzata con il server. Tuttavia, sono passati due giorni e non sono ancora a metà strada. Quindi penso che dovrei sincronizzare i miei commit nel caso in cui perdo il mio lavoro.

Il che mi porta alla domanda. Sarebbe stato meglio sincronizzare i commit il primo giorno? In tal caso, qual è il modo migliore per gestire il server CI? Accetto solo che ci sono un sacco di build rotti che mi stanno arrivando?

    
posta Mitkins 25.07.2016 - 04:07
fonte

2 risposte

3

Se stai usando git, dovresti fare il tuo lavoro in una filiale. Crea quanti più commit vuoi su questo ramo, ma non li controlli nel tuo server CI. La build CI deve essere mantenuta pulita. Non vuoi che altri sviluppatori accidentalmente ricevano il tuo codice rotto. Una volta che hai terminato il tuo lavoro (o almeno hai un pezzo di codice compilabile), puoi considerare di suddividere questo in un singolo commit, che poi puoi unire di nuovo al trunk e inviare al server.

Suggerirei di eseguire piccoli commit, anche di codice non compilabile. Non raccomanderei comunque di spingerli sul server. Mantieni la tua storia pulita e le tue intenzioni chiare. Se sei preoccupato della quantità di codice che devi inviare tutto in una volta, prova a creare blocchi di codice compilabile più piccoli.

Il tuo server CI è lì per un motivo. I test vengono eseguiti su di esso per un motivo. Non essere il tipo che rompe il tronco intenzionalmente. Non è giusto per nessun altro nella tua squadra e non è necessario per il lavoro che stai facendo.

    
risposta data 25.07.2016 - 06:16
fonte
2

Non lasciare mai il codice su una sola casella. I dischi rigidi falliscono. Le persone si ammalano Gli account vengono bloccati. Gli edifici prendono fuoco E a volte altre persone hanno solo bisogno di vedere cosa hai fatto.

Utilizza una filiale separata. Impegnati spesso. Tienilo sincronizzato.

Non commettere codice spezzato senza DIRE che è rotto e COME è rotto. È molto più facile eseguire il back-track se il punto in cui vuoi andare è chiaramente etichettato.

    
risposta data 25.07.2016 - 07:22
fonte

Leggi altre domande sui tag