Costruisce di notte per i progetti di un solo uomo

5

Sto lavorando su un wrapper C ++ per libpcap e mi piacerebbe avere più controllo sulla versione perché non ho esperienza con questo (l'unica ragione per cui l'ho usato è stato il codice su GitHub:)).

Ha senso programmare le build notturne per un progetto one-man? Quali vantaggi ci sono nel fare questo?

    
posta rightfold 05.09.2011 - 23:18
fonte

5 risposte

12

Ce l'hai un po 'dall'angolo sbagliato.

L'idea importante è che hai bisogno di build riproducibili !

Data qualsiasi distribuzione è necessario essere in grado di riprodurre in seguito il processo di compilazione esatto che ha generato tale distribuzione, in modo da poter eseguire il debug e correggerlo. Qui è importante utilizzare il controllo del codice sorgente in modo da poter recuperare tali sorgenti. Per essere assolutamente certi che le fonti siano le stesse, dovresti usare un robot per controllare i sorgenti dal tuo controlo sorgente e poi costruire il tuo programma. Questo ha il vantaggio di catturare qualsiasi dipendenza non nel controllo del codice sorgente.

Se questo processo richiede molto tempo (ad es. perché ci sono molti test in corso), è bello avere l'ultima versione disponibile per tutti gli interessati al mattino, cioè fare una compilazione di notte. Se non hai questo bisogno, probabilmente non è necessario il nightly (ma tu vorrai il robot!).

Inoltre, apprendi bene il controllo del tuo codice sorgente, incluso il modo in cui viene solitamente utilizzato da altri. Questo ti darà trucchi e idee che ti faranno risparmiare molti problemi a lungo termine.

    
risposta data 06.09.2011 - 01:03
fonte
3

Probabilmente no.

I vantaggi delle build notturne automatiche iniziano solo a giocare quando il team diventa così grande che nessun membro del team individuale può mantenere l'intero progetto nella testa. Quando ciò accade, le build notturne ti assicurano di sapere sempre se sei in grado di spedire se necessario, in qualsiasi momento, ma se stai andando da solo, probabilmente lo sai comunque. È sempre una buona idea avere test automatici e uno script che esegua una compilazione completa (dal checkout pulito al pacchetto disponibile) ed eseguirlo di tanto in tanto: ogni volta che hai completato una funzione, refactored o riscritto un codice, o fatto qualcosa che potrebbe in qualche modo rompere le cose.

L'uso del controllo del codice sorgente, tuttavia, è assolutamente necessario. Inizia a usarlo e ti chiedi come mai sei riuscito a vivere senza.

    
risposta data 06.09.2011 - 00:16
fonte
3

Direi che le build automatiche sono, se possibile, più importanti in una squadra individuale. Puoi mentire a te stesso, ma il server CI è un master molto più severo. Lei non mente.

    
risposta data 06.09.2011 - 04:55
fonte
1

Se possibile, ti suggerisco di configurare un server di integrazione continuo come Hudson o Jenkins e lo fanno compilare ed eseguire i test dopo un check-in, anziché notturno. Questo ha il vantaggio di darti un feedback sullo stato attuale del progetto su base regolare mentre lavori su di esso, senza sprecare tempo e risorse quando non sono state apportate modifiche.

    
risposta data 06.09.2011 - 00:56
fonte
0

Vantaggi

  • Quanto prima hai impostato un processo di integrazione continua più è facile.
  • Espone gli errori in precedenza nel processo di sviluppo che è sempre più economico.
  • Fornisce un framework per altre buone abitudini come test automatici, packaging automatico, tagging e versioni automatiche, ecc.
  • Ti porta a progettare meglio (rilocabile, parametrizzato correttamente, guidato dalla configurazione)

Svantaggi

  • Tempo di installazione del sistema (dovrebbe essere di circa 1-2 giorni per una configurazione semplice)
  • Costo della manutenzione del server
  • Costo del mantenimento del servizio
  • Costo di un design migliore (rilocabile, parametrizzato correttamente, config driven, e tc)

Non hai il lusso di essere trascurato nel tuo codice con gli elementi della configurazione. Se si tracciano percorsi hard-code, utenti, ecc., È probabile che si verifichi un'interruzione della generazione di elementi della configurazione, in particolare se si dispone di una suite di test automatizzata.

    
risposta data 06.09.2011 - 06:45
fonte

Leggi altre domande sui tag