Che cos'è uno strumento di costruzione?

Negli ultimi 4 anni, ho programmato con Eclipse (per Java) e Visual Studio Express (per C #). Gli IDE citati sembravano sempre fornire tutte le strutture che un programmatore potrebbe chiedere (legate alla programmazione, ovviamente).

Ultimamente ho sentito parlare di qualcosa chiamato "strumenti di costruzione". Ho sentito che sono usati quasi in tutti i tipi di sviluppo del mondo reale. Cosa sono esattamente? Quali problemi sono progettati per risolvere? Come mai non ne ho mai avuto bisogno negli ultimi quattro anni? Sono una specie di IDE eliminati dalla riga di comando?

Cosa sono gli strumenti di costruzione?

Gli strumenti di costruzione sono programmi che automatizzano la creazione di applicazioni eseguibili dal codice sorgente (ad es. .Apk per l'app Android). Building incorpora la compilazione, il collegamento e l'imballaggio del codice in una forma utilizzabile o eseguibile.

Fondamentalmente costruire l'automazione è l'atto di creare script o automatizzare una vasta gamma di attività che gli sviluppatori di software svolgono nelle loro attività quotidiane come:

1. Download delle dipendenze.
2. Compilare il codice sorgente in codice binario.
3. Impacchettare quel codice binario.
4. Esecuzione di test.
5. Distribuzione ai sistemi di produzione.

Perché utilizziamo strumenti di compilazione o automazione delle build?

Nei piccoli progetti, gli sviluppatori invocano spesso manualmente il processo di creazione. Questo non è pratico per progetti più grandi, dove è molto difficile tenere traccia di ciò che deve essere costruito, in quale sequenza e quali dipendenze ci sono nel processo di costruzione. L'uso di uno strumento di automazione consente al processo di compilazione di essere più coerente.

Vari strumenti di costruzione disponibili (solo pochi nomi):

1. Per java - Ant, Maven, Gradle.
2. Per .NET framework - NAnt
3. c # - MsBuild.

Per ulteriori letture è possibile consultare i seguenti collegamenti:

1. Costruisci automazione

2. Elenco dei software di automazione della build

Grazie.

Gli strumenti di compilazione sono strumenti per gestire e organizzare le build e sono molto importanti in ambienti in cui vi sono molti progetti, soprattutto se sono interconnessi. Servono per assicurarsi che dove varie persone stanno lavorando a vari progetti, non rompano nulla. E per assicurarti che quando apporti le tue modifiche, anche loro non rompano nulla.

Il motivo per cui non ne hai mai sentito parlare prima è che non hai mai lavorato in un ambiente commerciale prima. Ci sono molte cose che probabilmente non hai riscontrato in ambienti commerciali, specialmente se lavori in software house.

Come altri hanno già detto, li hai usati, tuttavia, non hai dovuto prenderli in considerazione, perché probabilmente hai lavorato in un modo diverso dal solito modo commerciale di lavorare.

Gli strumenti di compilazione di solito vengono eseguiti dalla riga di comando, all'interno di un IDE o completamente separati da esso.

L'idea è quella di separare il lavoro di compilazione e impacchettamento del codice dalla creazione, dal debug, ecc.

Uno strumento di compilazione può essere eseguito sul comando o all'interno di un IDE, entrambi attivati ​​da te. Possono anche essere utilizzati da strumenti di integrazione continua dopo aver verificato il codice da un repository e su una macchina pulita.

make era uno strumento di comando iniziale utilizzato negli ambienti * nix per la creazione di C / C ++.

Come sviluppatore Java, gli strumenti di compilazione più popolari sono Ant e Maven. Entrambi possono essere eseguiti in IDE come IntelliJ o Eclipse o NetBeans. Possono anche essere utilizzati da strumenti di integrazione continua come Cruise Control o Hudson.

Gli strumenti di costruzione servono generalmente a trasformare il codice sorgente in binari: organizzano il codice sorgente, impostano i flag di compilazione, gestiscono le dipendenze ... alcuni di essi si integrano anche con l'esecuzione di unit test, facendo analisi statiche, generando documentazione.

Eclipse o Visual Studio sono anche sistemi di compilazione (ma più di un IDE), e per Visual Studio è il msbuild sottostante per analizzare i file di progetto di Visual Studio sotto il cofano.

L'origine di tutti i sistemi di costruzione sembra il famoso "make".

Esistono sistemi di build per lingue diverse:

1. C ++: make, cmake, premake
2. Java: formica + edera, maven, gradle
3. C #: msbuild

Generalmente, compilare i sistemi usando un linguaggio specifico del dominio (make, cmake) o xml (ant, maven, msbuild) per specificare una build. La tendenza attuale sta usando un vero linguaggio di scripting per scrivere script di compilazione, come lua per premake e groovy per gradle, il vantaggio dell'uso di uno script è che è molto più flessibile e ti consente anche di inventare un set di standard API (come build DSL).

Il processo di compilazione è un processo di compilazione del codice sorgente per eventuali errori che utilizzano alcuni strumenti di creazione e creazione di build (che sono versioni eseguibili del progetto). Noi (principalmente sviluppatori) apportiamo alcune modifiche al codice sorgente e registriamo tale codice affinché avvenga il processo di compilazione. Dopo il processo di compilazione, si ottengono due risultati: 1. Costruire PASSES e si ottiene una versione eseguibile del progetto (Build è pronto). 2. Non riesce e si ottengono alcuni errori e la creazione non viene creata.

Esistono diversi tipi di processo di compilazione come: 1. Build notturno 2. Build con gate 3. Build con integrazione continua ecc.

Gli strumenti di costruzione aiutano e automatizzano il processo di creazione di build.

* Quindi in Short Build è una versione del software in formato pre-release utilizzata dal team di sviluppatori o di sviluppo per acquisire fiducia per il risultato finale del loro prodotto monitorando continuamente il loro prodotto e risolvendo eventuali problemi all'inizio del processo di sviluppo. *

Questi sono diversi tipi di processi attraverso i quali puoi realizzare le tue build.

1. Build di integrazione continua:In questo principalmente gli sviluppatori effettuano il check-in del loro codice e subito dopo il check-in inizia una build per la creazione delle modifiche recenti, quindi dovremmo sapere se le modifiche apportate dallo sviluppatore hanno funzionato o meno subito dopo il check-in. Questo è preferito per piccoli progetti o componenti dei progetti. Nel caso in cui più team siano associati al progetto o ci sia un grande no. degli sviluppatori che lavorano allo stesso progetto questo scenario diventa difficile da gestire come se ci fossero 'n' no. dei check-in e la compilazione fallisce in determinati punti diventa molto difficile rintracciare se si è verificata tutta la rottura a causa di un problema o con più problemi, quindi se i problemi più vecchi non vengono risolti correttamente, diventa molto difficile rintracciare il successivo difetti verificatisi dopo tale modifica.

2. Build di check-in con gate: in questo tipo di check-in, una build viene avviata subito dopo il check-in, mantenendo le modifiche in un set di scaffalature. In questo caso, se la build ha esito positivo rispetto al check-in impostato su shelve, viene eseguito il commit altrimenti non verrà eseguito il commit sul Team Foundation Server. Ciò fornisce un quadro leggermente migliore dalla build di integrazione continua poiché solo i check-in riusciti possono impegnarsi.

3. Build notturni: viene anche definito build pianificato. In questo caso pianifichiamo che le build vengano eseguite per un tempo specifico al fine di creare le modifiche. Tutte le precedenti modifiche non confermate dall'ultima build vengono create durante questo processo di compilazione. Questo viene praticato quando vogliamo effettuare il check-in più volte ma non vogliamo una build ogni volta che controlliamo il nostro codice in modo da poter avere un tempo o un periodo fisso in cui possiamo avviare la build per la creazione del codice di check-in.

Maggiori dettagli su queste build sono disponibili nella seguente posizione.

Check-gated in Build

Build di integrazione continua

Build notturni

Li stai usando - IDE è uno strumento di compilazione. Per la riga di comando puoi usare cose come make.

Le persone usano gli strumenti da riga di comando per cose come una build notturna - così al mattino con i postumi di una sbornia il programmatore si è reso conto che il codice con cui stava giocherellando con le ultime build delle librerie non funziona!

"... è molto difficile tenere traccia di ciò che deve essere costruito" - Strumenti di costruzione non aiuta a tutto questo. Devi sapere cosa vuoi costruire. (Citato dalla risposta di Ritesh Gun)

"Ho sentito che sono utilizzati quasi in tutti i tipi di sviluppo del mondo reale" - Per qualche ragione, agli sviluppatori di software piace lavorare in grandi aziende. Sembrano avere direttive di lavoro più poco chiare per ogni individuo che lavora lì.

"Come mai non ne ho mai avuto bisogno negli ultimi quattro anni". Probabilmente perché sei un programmatore esperto.

Pseudo, meta. Penso che gli strumenti di costruzione non offrano alcun vantaggio reale. È lì solo per aggiungere un senso di sicurezza derivante da cattive pratiche aziendali, mancanza di direzione - cattiva leadership architettonica del software che porta a una cattiva conoscenza effettiva del progetto. Non dovresti mai usare gli strumenti di costruzione (per i test) nel tuo progetto. Effettuare test casuali con una scarsa conoscenza del progetto software non fornisce alcun tipo di aiuto.

Non dovresti mai aggiungere qualcosa a un progetto senza conoscerne lo scopo e come funzionerà con gli altri componenti. I componenti possono essere funzionali separati, ma non possono lavorare insieme. (Questa è la responsabilità dell'architetto del software presumo).

Cosa succede se nel progetto vengono aggiunti 4-5 componenti. Aggiungi un sesto componente. Insieme al primo componente aggiunto, potrebbe rovinare tutto. Nessun automatico aiuterebbe a rilevarlo.

Non esiste altra scorciatoia se non pensare pensare pensare.

Quindi c'è il download automatico dai repository. Perché mai vorresti farlo? Devi sapere cosa scarichi, cosa aggiungi al progetto. Come rilevate le modifiche nelle versioni dei repository? Devi sapere. Non puoi "auto" nulla.

E se dovessimo testare le biciclette e i trasporti dei bambini con gli occhi bendati con un bastoncino e colpire casualmente con esso. Questa sembra essere l'idea del test degli strumenti di costruzione.

Mi dispiace non ci siano scorciatoie https://en.wikipedia.org/wiki/Scientific_method e https://en.wikipedia.org/wiki/Analysis