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.