Perché si dovrebbe usare un sistema di compilazione su quello che è incluso come parte di un IDE?

Question

Ho sentito più di una persona dire che se il processo di compilazione fa clic sul pulsante di costruzione, il processo di creazione non funziona. Spesso questo è accompagnato da consigli per utilizzare cose come make, cmake, nmake, MSBuild, ecc. Che cosa offrono esattamente questi strumenti che giustificano il mantenimento manuale di un file di configurazione separato?

EDIT: Sono più interessato alle risposte applicabili a un singolo sviluppatore che lavora su un progetto C++ a ~ 20k line, ma sono interessato anche al caso generale.

EDIT2: Non sembra che ci sia una buona risposta a questa domanda, quindi sono andato avanti e l'ho fatto in CW. In risposta a coloro che parlano dell'integrazione continua, sì, capisco completamente quando si hanno molti sviluppatori su un progetto con CI che è bello. Tuttavia, questo è un vantaggio dell'IC, non del mantenimento di script di compilazione separati. Sono ortogonali: ad esempio, Team Foundation Build è una soluzione CI che utilizza i file di progetto di Visual Studio durante la sua configurazione.

Answer 1

Oltre alle continue esigenze di integrazione già affrontate da tutti, è possibile anche semplicemente automatizzare alcuni altri aspetti del processo di creazione.Forse è qualcosa di semplice come incrementare un numero di versione su una build di produzione, eseguire i test delle unità, o resettare e verificare l'ambiente di test, o eseguire FxCop o uno script personalizzato che automatizza una revisione del codice per la conformità agli standard aziendali. Uno script di compilazione è solo un modo per automatizzare qualcosa oltre alla semplice compilazione del codice. Tuttavia, la maggior parte di questo genere di cose può essere realizzata anche tramite azioni di pre-compilazione/post-compilazione che quasi tutti gli IDE moderni consentono di configurare.

Sinceramente, a meno che non ci siano molti sviluppatori che si affidano al sistema di controllo del codice sorgente o che hanno molti sistemi o applicazioni che si affidano alle librerie condivise e devono fare l'IC, l'uso di uno script di compilazione è probabilmente eccessivo rispetto alle alternative più semplici. Ma se ti trovi in ​​una di queste situazioni, un server di build dedicato che estrae dal controllo del codice sorgente e le build automatizzate dovrebbe essere una parte essenziale dell'arsenale del tuo team e il modo più semplice per crearne uno è utilizzare make, MSBuild, Ant , ecc.

Answer 2

Se si dispone di un processo di integrazione continua, sarà guidato da uno script Ant o di stile. Il processo CI verificherà il codice al di fuori del controllo della versione quando le modifiche vengono rilevate su una macchina di compilazione separata, compila, prova, impacchetta, distribuisce e crea un rapporto di riepilogo.

Answer 3

Diciamo che ci sono 5 persone che lavorano sullo stesso set di codice. Ognuna di queste 5 persone sta aggiornando lo stesso insieme di file. Ora puoi fare clic sul pulsante di costruzione e sai che il codice funziona, ma quando lo si integra con tutti gli altri. L'unica cosa che saprai è che se prendi tutti gli altri e provi. Questo è facile ogni tanto, ma diventa fastidioso farlo più e più volte.

Con un server di build che lo esegue automaticamente, controlla se il codice viene compilato per tutti in qualsiasi momento. Tutti sanno sempre se c'è qualcosa di sbagliato nella compilazione e qual è il problema, e nessuno deve fare alcun lavoro per capirlo. Piccole cose si sommano, potrebbe essere necessario un paio di minuti per tirare giù l'ultimo codice e provare a compilarlo, ma farlo 10-20 volte al giorno diventa rapidamente una perdita di tempo, soprattutto se si dispone di più persone. Certo, puoi farcela senza, ma è molto più facile lasciare che un processo automatizzato faccia la stessa cosa più e più volte, quindi farlo fare a una persona reale.

Ecco un'altra cosa interessante. Il nostro processo è configurato per testare anche tutti gli script sql. Non è possibile farlo premendo il pulsante di costruzione. Ricarica istantanee di tutti i database di cui ha bisogno per applicare le patch e le esegue per assicurarsi che funzionino tutte e vengano eseguite nell'ordine in cui dovrebbero. Il build server è anche abbastanza intelligente da eseguire tutti i test di unità/test di automazione e restituire i risultati. Assicurarsi che possa essere compilato va bene, ma con un server di automazione, può gestire molti passaggi automaticamente che richiederebbero a una persona forse un'ora di lavoro.

Facendo questo un ulteriore passo avanti, se si dispone di un processo di distribuzione automatizzato insieme al build server, la distribuzione è automatica. Chiunque possa premere un pulsante per eseguire il processo e distribuire può spostare il codice in qa o produzione. Ciò significa che un programmatore non deve sprecare tempo a farlo manualmente, che è soggetto a errori. Quando non abbiamo avuto il processo, è sempre stato un tiro di merda se tutto sarebbe stato installato correttamente, e in generale era un amministratore di rete o un programmatore che doveva farlo, perché dovevano sapere come configurare IIS e sposta i file. Ora anche il nostro qa più giovane può aggiornare il server, perché tutto quello che devono sapere è quale pulsante premere.

Answer 4

i sistemi di generazione IDE che ho utilizzato sono tutti utilizzabili da cose come strumenti di Build/CI automatizzati, quindi non è necessario avere uno script di compilazione separato in quanto tale.

Tuttavia, in aggiunta a tale sistema di generazione è necessario automatizzare test, controllo delle versioni, tagging del controllo del codice sorgente e distribuzione (e qualsiasi altra cosa necessaria per rilasciare il prodotto).

Così si creano script che estendono la build IDE e fanno gli extra.

Answer 5

Un motivo pratico per cui le descrizioni di build gestite da IDE non sono sempre ideali ha a che fare con il controllo di versione e la necessità di integrarsi con le modifiche apportate da altri sviluppatori (ad esempio unione).

Se l'IDE utilizza un singolo file flat, può essere molto difficile (se non impossibile) unire due file di progetto in uno solo. Potrebbe utilizzare un formato basato su testo, come XML, ma XML è notoriamente difficile con gli strumenti standard di diff/merge. Solo il fatto che le persone utilizzino una GUI per apportare modifiche rende più probabile che si finiscano con modifiche non necessarie nei file di progetto.

Con script di compilazione distribuiti di dimensioni ridotte (file CMake, Makefile, ecc.), Può essere più facile riconciliare le modifiche alla struttura del progetto proprio come si unirebbero due file di origine. Alcune persone preferiscono la generazione di progetti IDE (utilizzando CMake, per esempio) per questo motivo, anche se tutti lavorano con gli stessi strumenti sulla stessa piattaforma.

Answer 6

Una ragione per l'utilizzo di un sistema di generazione che mi sorprende che nessun altro ha menzionato è la flessibilità. In passato, ho anche utilizzato il sistema di build integrato del mio IDE per compilare il mio codice. Mi sono imbattuto in un grosso problema, tuttavia, quando l'IDE che stavo usando è stato interrotto. La mia capacità di compilare il mio codice era legata al mio IDE, quindi sono stato costretto a rifare il mio intero sistema di compilazione. La seconda volta, però, non ho commesso lo stesso errore. Ho implementato il mio sistema di compilazione tramite makefile in modo da poter passare compilatori e IDE a volontà senza dover nuovamente implementare nuovamente il sistema di compilazione.

Ho riscontrato un problema simile al lavoro. Avevamo un'utilità interna creata come progetto Visual Studio. È un'utilità abbastanza semplice e non ha bisogno di aggiornamenti per anni, ma di recente abbiamo trovato un bug raro che doveva essere corretto. Con nostro disappunto, abbiamo scoperto che l'utility è stata creata utilizzando una versione di Visual Studio che era 5-6 versioni più vecchia di quella attualmente disponibile. Il nuovo VS non avrebbe letto correttamente il file di progetto della vecchia versione e abbiamo dovuto ricreare il progetto da zero. Anche se stavamo ancora usando lo stesso IDE, le differenze di versione hanno rotto il nostro sistema di build.

Quando si utilizza un sistema di compilazione separato, è completamente in grado di controllarlo. Cambiando IDE o versioni di IDE non si romperà nulla.Se il tuo sistema di compilazione è basato su uno strumento open-source come make, non devi nemmeno preoccuparti che i tuoi strumenti di costruzione vengano interrotti o abbandonati perché puoi sempre ricostruirli dal sorgente (più bug di correzione) se necessario. Affidarsi al proprio sistema di build IDE introduce un singolo punto di errore (specialmente su piattaforme come Visual Studio che integrano anche il compilatore ) e nella mia mente è stato un motivo sufficiente per separare il mio sistema di build e IDE.

A un livello più filosofico, sono fermamente convinto che non sia una buona cosa automatizzare qualcosa che non capisci. È bello usare l'automazione per rendersi più produttivi, ma solo se si ha una chiara comprensione di ciò che accade sotto la cappa (in modo da non rimanere bloccati quando l'automazione si rompe, se non altro). Ho usato il sistema di build integrato del mio IDE quando ho iniziato a programmare perché era facile e automatico. In seguito ho iniziato a rendermi conto che non capivo cosa stesse succedendo quando ho cliccato sul pulsante "compila". Ho fatto un po 'di lettura e ho iniziato a mettere insieme un semplice script di compilazione, confrontando il mio output con quello del sistema di build dell'IDE. Dopo un po 'ho capito che ora avevo il potere di fare ogni sorta di cose che erano difficili o impossibili attraverso l'IDE. Personalizzando le opzioni della riga di comando del compilatore oltre a quelle fornite dall'IDE, sono riuscito a produrre un output più piccolo, leggermente più veloce. Ancora più importante, sono diventato un programmatore migliore avendo una conoscenza reale dell'intero processo di sviluppo, dalla scrittura del codice fino alla generazione del linguaggio macchina. Comprendere e controllare l'intero processo end-to-end mi consente di ottimizzarlo e personalizzarlo in base alle esigenze di qualsiasi progetto al momento sto lavorando.