Build giornalieri con SVN per una piccola squadra

1

Ho una domanda generale riguardante le migliori pratiche. Ho un piccolo team che lavora su un progetto software di media scala, che prevede l'integrazione di codice da ambienti diversi, ecc. Il progetto è un pezzo autonomo di software desktop.

Sulla base delle lezioni apprese da un precedente progetto simile che è andato male, sto cercando di implementare alcune migliori pratiche di ingegneria del software.

Vorrei iniziare automatizzando le build giornaliere. Usiamo SVN per il controllo del codice sorgente e tutti gli sviluppatori stanno lavorando nel bagagliaio, incluso me. La mia domanda è piuttosto semplice:

Dove localmente facciamo le build giornaliere? Dovrei creare un'altra cartella sul mio computer locale che è la cartella "daily build"? Devo impostare una macchina virtuale? Dovrei succhiarlo e farlo nella mia cartella di sviluppo?

Comprendo abbastanza bene i paradigmi del controllo di revisione. Sto principalmente cercando come lo implementano in pratica .

    
posta Emily 22.07.2014 - 19:27
fonte

2 risposte

4

Una macchina da costruzione è la strada da percorrere, anche per piccoli progetti / team.

  1. Ottieni una macchina di riserva casuale (ad esempio una vecchia scatola di sviluppo).
  2. Installa alcuni software di integrazione continua su di esso come jenkins o TeamCity .
  3. Fatto

È passato un po 'di tempo da quando ho dovuto crearne uno o mantenere una macchina da compilare, ma a meno che non sia stato peggio da un anno o due fa, puoi avere build continui su ogni check-in e un build notturno che viene scaricato in una configurazione di condivisione di rete in circa un'ora con uno di questi prodotti.

    
risposta data 22.07.2014 - 19:48
fonte
0

Supponendo che la tua app possa essere compilata dalla riga di comando, dato un checkout pulito e pre-requisiti preinstallati, puoi farlo meccanicamente con qualcosa di semplice come un cron job o un'attività pianificata. Ma quello che vuoi veramente qui è noto come server di integrazione continua.

Questi server gestiscono un paio di cose:

  • facilitano l'orchestrazione di "vai a costruire questo ogni giorno a mezzanotte" o "vai a costruirlo ogni volta che qualcuno effettua il check-in" fornendo servizi di pianificazione.
  • estendono la build di base fornendo meccanismi di feedback, come inviare l'email all'intero team quando Bob interrompe la compilazione.
  • possono fornire rapporti a lungo termine sulle prestazioni di creazione e sul successo nel tempo.
  • può fornire l'impianto idraulico per automatizzare l'imballaggio e la pubblicazione di un'applicazione, ove appropriato.

Oppure, sono effettivamente il cervello di un moderno processo di sviluppo e distribuzione.

Ci sono due prodotti che sono buoni per iniziare in questo campo: Jenkins che è gratuito e open source e TeamCity che è gratuito per la tua scala ma non open source. Entrambi ti porteranno dove devi andare, quale scegliere è davvero una decisione tattica basata su cosa stai costruendo e quanta fatica potresti voler mettere nella configurazione della cosa - non che una configurazione di base con entrambi i prodotti è terribilmente coinvolto se hai mai alzato una e configurato un'applicazione web. Sono anatomicamente simili, quindi il resto di questa risposta si applicherà ad entrambi.

Questi prodotti hanno sia un server centrale che è ciò con cui interagisci sia un concetto di build agent o worker in cui avvengono le build. Questo sembra un po 'strano finché non ti rendi conto che potresti creare un prodotto multipiattaforma che ha bisogno di una finestra nativa, di OSX e di Linux.

In termini di dove installarlo è davvero una decisione tattica - entrambi sono prodotti java molto flessibili che funzionano praticamente su qualsiasi cosa. Si riduce davvero alla disponibilità di hardware / software / licenze e sicurezza - alcune persone vogliono davvero tenere tutto sulla LAN. Per quanto riguarda l'agente di costruzione è anche una decisione tattica. Non c'è motivo per cui l'agente non possa essere nella stessa casella del tuo server CI, ma potresti sicuramente lasciarlo in un posto diverso se necessario. Avere sulla stessa LAN aiuta a meno che tu non voglia fare alcune configurazioni di rete, dato che devono comunicare e in genere richiedono alcune perforazioni del firewall.

Probabilmente non lo installerei su una macchina che qualcuno stava usando attivamente solo per difendersi da qualcuno che spegne la macchina. O stai cercando di spegnere la macchina e interrompi il tuo processo di configurazione. Ma meccanicamente funzionerà un vecchio desktop - abbiamo appena ritirato un desktop HP di era del 2005 che era il principale server di sviluppo per ognuno dei nostri dozzina di siti di controllo qualità che sono stati costruiti abbastanza frequentemente. Il problema principale era che potevamo mettere solo 2 GB di RAM nella scatola, quindi non potevamo memorizzare molte cose nella ram e farebbe una pagina su un disco lento creato dal produttore più basso che funziona ben oltre la sua durata prevista.

tldr: ottieni Jenkins o TeamCity, installa su un desktop di riserva, conquista il mondo.

    
risposta data 22.07.2014 - 22:09
fonte

Leggi altre domande sui tag