Che cos'è uno strumento di costruzione?

Cosa sono gli strumenti di costruzione?

Gli strumenti di compilazione sono programmi che automatizzano la creazione di eseguibili applicazioni dal codice sorgente(ad es. .apk per Android app). Edificio incorpora la compilazione, il collegamento e il confezionamento del codice in un forma eseguibile.

Fondamentalmente build automation è l'atto di scripting o automatizzazione di un ampia varietà di attività che gli sviluppatori di software fanno nel loro giorno per giorno attività come:

1. Scaricamento dipendenza.
2. Compilazione del codice sorgente in codice binario.
3. Impacchettare quel codice binario.
4. Esecuzione di test.
5. Distribuzione nei sistemi di produzione.

Perché usiamo strumenti di compilazione o automazione di compilazione?

Nei piccoli progetti, gli sviluppatori spesso richiamano manualmente la build processo. 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. Utilizzo di un lo strumento di automazione consente al processo di compilazione di essere più coerente.

Vari strumenti di compilazione disponibili(Nominandone solo alcuni):

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

Per ulteriori approfondimenti è possibile fare riferimento ai seguenti link:

1.Crea automazione

2.Elenco di crea software di automazione

Grazie.

Gli strumenti di compilazione sono strumenti per gestire e organizzare le build e sono molto importanti in ambienti in cui ci sono molti progetti, specialmente se sono interconnessi. Servono per assicurarsi che dove varie persone stanno lavorando su vari progetti, non rompono nulla. E per fare in modo che quando si apportano le modifiche, non rompono nulla neanche.

Il motivo per cui non ne hai mai sentito parlare prima è che non hai mai lavorato in un ambiente commerciale prima. C'è un sacco di cose che probabilmente non avete incontrato che si sarà all'interno di un ambiente commerciale, soprattutto se si lavora in software house.

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

Gli strumenti di compilazione

Vengono solitamente eseguiti sulla riga di comando, all'interno di un IDE o completamente separati da esso.

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

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

Make era uno strumento di comando iniziale utilizzato in * ambienti nix per la costruzione 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 compilazione sono generalmente per 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, una documentazione generatrice.

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 compilazione sembra il famoso 'fare'.

Esistono sistemi di compilazione per diverse lingue:

1. C++: crea, cmake, premake
2. Java: ant + ivy, maven, gradle
3. C#: msbuild

Di solito, i sistemi di compilazione utilizzano un linguaggio specifico del dominio di proprietà (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 build, come lua per premake e groovy per gradle, il vantaggio di usare uno scripting è molto più flessibile e consente anche di creare un set di API standard (come build DSL).

Il processo di compilazione è un processo di compilazione del codice sorgente per eventuali errori utilizzando alcuni strumenti di compilazione e creando build(che sono versioni eseguibili del progetto). Noi (principalmente sviluppatori) facciamo alcune modifiche nel codice sorgente e registriamo quel codice affinché il processo di compilazione avvenga. Dopo il processo di compilazione dà due risultati : 1. O la build PASSA e ottieni una versione eseguibile del tuo progetto(la Build è pronta). 2. Fallisce e ottieni determinati errori e la build non lo è creare.

Esistono diversi tipi di processo di compilazione come : 1. Notte Costruire 2. costruzione chiusa 3. Costruzione di integrazione continua ecc.

Strumenti di compilazione aiutano e automatizzano il processo di creazione di build.

*Quindi, in breve, Build è una versione del Software in formato pre-release utilizzata dallo sviluppatore o dal team di sviluppo per acquisire sicurezza per il risultato finale del proprio Prodotto monitorando continuamente il proprio Prodotto e risolvendo eventuali problemi all'inizio durante lo sviluppo processo.*

Questi sono diversi tipi di processi con cui è possibile ottenere le build fatte.

1. Continuous Integration build: In questo principalmente gli sviluppatori controllano il loro codice e subito dopo il loro check-in una build inizia per la costruzione delle modifiche recenti, quindi dovremmo sapere se le modifiche apportate dallo sviluppatore hanno funzionato o meno subito dopo il check-in. Questo è preferito per i progetti più piccoli o componenti dei progetti. Nel caso in cui siano associati più team con il progetto o ci sono un grande no. di sviluppatori che lavorano sullo stesso progetto questo scenario diventa difficile da gestire come se ci fossero 'n' no. di check-in e la build fallisce in determinati punti diventa molto difficile rintracciare se tutta la rottura si è verificata a causa di un problema o con più problemi, quindi se i problemi più vecchi non vengono affrontati correttamente, diventa molto difficile rintracciare i difetti successivi che si sono verificati dopo quel cambiamento. Il principale vantaggio di questi costruisce è che si arriva a sapere se un particolare check-in è successo o no.

2. Build di check-in gated: In questo tipo di check-in una build viene avviata subito dopo il check-in mantenendo le modifiche in un set di shelve. In questo caso, se la build ha esito positivo rispetto al check-in shelve-set viene eseguito il commit, altrimenti non verrà eseguito il commit su Team Foundation Server. Questo dà un quadro leggermente migliore dalla costruzione di integrazione continua come solo il successo il check-in è consentito per ottenere impegnati.

3. Nightly builds: Questo è anche indicato come build pianificate. In questo caso pianifichiamo che le build vengano eseguite per un tempo specifico al fine di creare le modifiche. Tutte le modifiche non committed precedenti dall'ultima build vengono compilate 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 costruzione del codice registrato.

Maggiori dettagli su queste build possono essere trovati nella posizione seguente.

Gated-check in Build

L'integrazione continua costruisce

Costruzioni notturne

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

Le persone usano strumenti da riga di comando per cose come una build notturna - quindi al mattino con una sbornia il programmatore si è reso conto che il codice con cui ha armeggiato con le ultime build delle librerie non funziona!

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

"Ho sentito che sono usati 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 ho mai avuto bisogno di loro negli ultimi quattro anni". Probabilmente perché sei un programmatore esperto.

Pseudo, meta. Penso che gli strumenti di costruzione non forniscano alcun vantaggio reale. È solo lì 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 compilazione (per il test) nel tuo progetto. Fare test casuali con una mancanza di conoscenza del progetto software non dà alcun tipo di aiuto a tutto.

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

Cosa succede se 4-5 componenti vengono aggiunti al progetto. Si aggiunge un 6 ° componente. Insieme al primo componente aggiunto, potrebbe rovinare tutto. Nessun automatico aiuterebbe a rilevarlo.

Non esiste scorciatoia diverso da pensare pensare pensare.

Poi c'è il download automatico dai repository. Perche ' mai vorresti farlo? Devi sapere cosa scarichi, cosa aggiungi al progetto. Come si rilevano le modifiche nelle versioni dei repository? Devi saperlo. Non puoi "auto" niente.

E se provassimo biciclette e trasporti per bambini bendati con un bastone e colpissimo casualmente con esso? Questa sembra essere l'idea di costruire test degli strumenti.

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