De afgelopen 4 jaar programmeer ik met Eclipse (voor Java) en Visual Studio Express (voor C#). De genoemde IDE’s leken altijd alle faciliteiten te bieden waar een programmeur om zou kunnen vragen (uiteraard gerelateerd aan programmeren).
De laatste tijd heb ik gehoord over iets dat ‘tools bouwen’ wordt genoemd. Ik heb gehoord dat ze bijna worden gebruikt in allerlei real-world ontwikkeling. Wat zijn ze precies? Voor welke problemen zijn ze ontworpen om op te lossen? Hoe komt het dat ik ze de afgelopen vier jaar nooit nodig heb gehad? Zijn het een soort van command-line uitgeklede IDE’s?
Antwoord 1, autoriteit 100%
Wat zijn build-tools?
Build-tools zijn programma’s die het maken van uitvoerbare bestanden automatiseren
applicaties uit de broncode (bijv..apkvoor een Android-app). Gebouw
omvat het compileren, koppelen en verpakken van de code in een bruikbare of
uitvoerbare vorm.In principe is het bouwen van automatisering de handeling van het scripten of automatiseren van a
grote verscheidenheid aan taken die softwareontwikkelaars dagelijks uitvoeren
activiteiten zoals:
- Afhankelijkheden downloaden.
- Broncode compileren in binaire code.
- Die binaire code verpakken.
- Tests uitvoeren.
- Deployment naar productiesystemen.
Waarom gebruiken we build-tools of build-automatisering?
In kleine projecten zullen ontwikkelaars de build vaak handmatig aanroepen
Verwerken. Dit is niet praktisch voor grotere projecten, waar het erg
moeilijk om bij te houden wat er gebouwd moet worden, in welke volgorde en
welke afhankelijkheden er zijn in het bouwproces. Een gebruiken
automatiseringstool zorgt ervoor dat het bouwproces consistenter is.
Verschillende bouwtools beschikbaar (slechts enkele namen):
- Voor java – Ant,Maven,Gradle.
- voor .NET Framework – Nant
- c # – MSBUILD.
Voor verder lezen kunt u de volgende links verwijzen:
bedankt.
Antwoord 2, Autoriteit 14%
Build-tools zijn hulpmiddelen om uw builds te beheren en te organiseren, en zijn erg belangrijk in omgevingen waar veel projecten zijn, vooral als ze onderling verbonden zijn. Ze dienen om ervoor te zorgen dat waar verschillende mensen aan verschillende projecten werken, ze niet breken. En om ervoor te zorgen dat wanneer u uw wijzigingen aanbrengt, ze ook niets breken.
De reden waarom je nog niet van hen hebt gehoord, is dat je eerder niet in een commerciële omgeving hebt gewerkt. Er is heel veel dingen die je waarschijnlijk niet hebt aangetroffen dat je binnen een commerciële omgevingen zit, vooral als je in softwareprijzen werkt.
Zoals anderen hebben gezegd, heb je ze gebruikt, maar je hebt ze echter niet overwogen, omdat je waarschijnlijk op een andere manier hebt gewerkt op de gebruikelijke commerciële manier van werken.
Antwoord 3, Autoriteit 8%
Build-tools worden meestal uitgevoerd op de opdrachtregel, ofwel binnen een IDE of volledig gescheiden.
Het idee is om het werk van het samenstellen en verpakken van uw code te scheiden van creatie, foutopsporing, enz.
Een build-tool kan worden uitgevoerd op de opdracht of in een IDE, beide door u geactiveerd. Ze kunnen ook worden gebruikt door continue integratietools na het controleren van uw code uit een repository en op een schone bouwmachine.
maken was een vroege commando-tool die wordt gebruikt in * NIX-omgevingen voor het bouwen van C / C++.
Als Java-ontwikkelaar zijn Ant en Maven de populairste build-tools. Beide kunnen worden uitgevoerd in IDE’s zoals IntelliJ of Eclipse of NetBeans. Ze kunnen ook worden gebruikt door tools voor continue integratie, zoals Cruise Control of Hudson.
Antwoord 4, autoriteit 4%
Build-tools zijn over het algemeen bedoeld om broncode om te zetten in binaire bestanden – het organiseert de broncode, stelt compileervlaggen in, beheert afhankelijkheden… sommige integreren ook met het uitvoeren van unit-tests, het doen van statische analyse en het genereren van documentatie.
Eclipse of Visual Studio zijn ook build-systemen (maar meer een IDE), en voor visual studio is het de onderliggende msbuild om visual studio-projectbestanden onder de motorkap te ontleden.
De oorsprong van alle bouwsystemen lijkt het beroemde ‘merk’.
Er zijn bouwsystemen voor verschillende talen:
- C++: make, cmake, premake
- Java: mier+klimop, maven, gradle
- C#: msbuild
Gewoonlijk bouwt u systemen met behulp van een eigen domeinspecifieke taal (make, cmake), of xml (ant, maven, msbuild) om een build te specificeren. De huidige trend is het gebruik van een echte scripttaal om buildscript te schrijven, zoals lua voor premake en groovy voor gradle. Het voordeel van het gebruik van een scripting is dat het veel flexibeler is en je ook in staat stelt om een set standaard API’s (as build DSL).
Antwoord 5
Dit zijn verschillende soorten processen waarmee u uw builds kunt uitvoeren.
1. Continue integratie-build:hierin checken voornamelijk ontwikkelaars hun code in en direct na hun check-in wordt een build gestart voor het bouwen van de recente wijzigingen, zodat we moeten weten of de wijzigingen die door de ontwikkelaar zijn aangebracht, hebben gewerkt of niet direct daarna het inchecken is gedaan. Dit heeft de voorkeur voor kleinere projecten of onderdelen van de projecten. In het geval dat meerdere teams aan het project zijn gekoppeld of er een groot nee is. van ontwikkelaars die aan hetzelfde project werken, wordt dit scenario moeilijk te hanteren alsof er ‘n’ nee zijn. van check-in’s en de build mislukt op bepaalde punten, wordt het zeer moeilijk om te traceren of alle breuk is opgetreden vanwege één probleem of met meerdere problemen, dus als de oudere problemen niet goed worden aangepakt, wordt het erg moeilijk om de latere problemen op te sporen gebreken die na die wijziging zijn opgetreden. Het belangrijkste voordeel van deze builds is dat we te weten komen of een bepaalde check-in succesvol is of niet.
2. Gated check-in builds:Bij dit type check-in wordt een build gestart direct nadat de check-in is voltooid, waarbij de wijzigingen op een plank worden bewaard. In dit geval, als de build slaagt, wordt de check-in op de plank vastgelegd, anders wordt deze niet vastgelegd op de Team Foundation Server. Dit geeft een iets beter beeld van de continue integratie-build, omdat alleen de succesvolle check-in’s zich mogen committeren.
3. Nachtelijke builds:dit wordt ook wel geplande builds genoemd. In dit geval plannen we dat de builds gedurende een bepaalde tijd worden uitgevoerd om de wijzigingen te bouwen. Alle eerdere niet-vastgelegde wijzigingen van de laatste build worden gebouwd tijdens dit buildproces. Dit wordt toegepast wanneer we meerdere keren willen inchecken, maar niet elke keer dat we onze code inchecken een build willen, zodat we een vaste tijd of periode kunnen hebben waarin we de build voor het bouwen van de ingecheckte code kunnen starten.
Meer details over deze builds zijn te vinden op de onderstaande locatie.
Antwoord 6
Build-proces is een proces waarbij uw broncode wordt gecompileerd voor eventuele fouten met behulp van enkele build-tools en het maken van builds (uitvoerbare versies van het project). Wij (voornamelijk ontwikkelaars) doen enkele wijzigingen in de broncode en checken die code in om het bouwproces te laten plaatsvinden. Na het bouwproces geeft het twee resultaten:
1. Ofwel bouw PASSES en u krijgt een uitvoerbare versie van uw project (Build is klaar).
2. Het mislukt en je krijgt bepaalde fouten en de build wordt niet gemaakt.
Er zijn verschillende soorten bouwprocessen, zoals:
1. Nachtelijk bouwen
2. gated bouwen
3. Continue integratie bouwen enz.
Buildtools helpen en automatiseren het proces van het maken van builds.
* Dus in korte build is een versie van software in het fre-release-indeling dat wordt gebruikt door het ontwikkelaar- of ontwikkelingsteam om vertrouwen te krijgen voor het eindresultaat van hun product door hun product continu te volgen en eventuele problemen op te lossen en eventuele problemen op te lossen vroeg tijdens het ontwikkelingsproces. *
Antwoord 7
U gebruikt ze – IDE is een build-tool. Voor de opdrachtregel kunt u dingen gebruiken zoals make.
Mensen gebruiken opdrachtregelhulpmiddelen voor dingen als een nachtelijke build – dus in de ochtend met een kater heeft de programmeur gerealiseerd dat de code die hij heeft gehad met de nieuwste builds van de bibliotheken niet werkt!
Antwoord 8
“… het is erg moeilijk om bij te houden van wat er moet worden gebouwd” – Bouwgereedschap helpt niet bij dat allemaal. Je moet weten wat je wilt bouwen. (Geciteerd van het antwoord van Ritesh Gun)
“Ik hoorde dat ze bijna in allerlei real-world ontwikkeling worden gebruikt” – om de een of andere reden werken software-ontwikkelaars graag in grote bedrijven. Ze lijken meer onduidelijke werkrichtlijnen te hebben voor elk individu dat daar werkt.
“Hoe komt het dat ik ze nooit nodig had in de afgelopen vier jaar”. Waarschijnlijk omdat je een bekwame programmeur bent.
Pseudo, meta. Ik denk dat build-tools helemaal geen echt echt voordeel bieden. Het is er alleen om een gevoel van beveiliging toe te voegen dat voortkomt uit slechte bedrijfspraktijken, gebrek aan richting – Slechte software architecturale leiderschap leidt tot slechte werkelijke kennis van het project. Je hoeft nooit build-tools (voor testen) in je project te gebruiken. Om willekeurig testen met een gebrek aan kennis van het softwareproject te doen, geeft u helemaal geen hulp bij.
Je mag nooit iets aan een project toevoegen zonder te weten wat het doel is en hoe het zal werken met de andere componenten. Componenten kunnen functioneel gescheiden zijn, maar niet samenwerken. (Dit is de verantwoordelijkheid van de software-architect, neem ik aan).
Wat als er 4-5 componenten aan het project worden toegevoegd. Je voegt een 6e component toe. Samen met de eerste toegevoegde component kan het alles verpesten. Geen enkele automaat zou helpen om dat te detecteren.
Er is geen andere kortere weg dan denken, denken, denken.
Dan is er de automatische download van repositories. Waarom zou je dat ooit willen doen? U moet weten wat u downloadt, wat u toevoegt aan het project. Hoe detecteer je wijzigingen in versies van de repositories? Je moet weten. Je kunt niets “automatiseren”.
Wat als we fietsen en babytransporters geblinddoekt met een stok zouden testen en er willekeurig mee rond zouden slaan. Dat lijkt het idee te zijn van het testen van build-tools.
Het spijt me dat er geen snelkoppeling is
https://en.wikipedia.org/wiki/Scientific_method
en
https://en.wikipedia.org/wiki/Analysis