streamalism.org

1. Inleiding

In moderne softwareontwikkeling is de term pijpleiding wordt veel gebruikt. Maar wat is het?

In het algemeen, een build-pijplijn is een reeks geautomatiseerde stappen die code van ontwikkeling naar productie verplaatsen.

Build-pijplijnen zijn geweldig voor het implementeren van doorlopende integratieworkflows voor software. Ze laten ons toe bouw kleinere veranderingen met een grotere frequentie, met als doel bugs sneller te vinden en de impact ervan te verkleinen.

In deze zelfstudie kijken we naar het bouwen van een eenvoudige build-pijplijn met Travis CI.

2. Stappen in een build-pijplijn

Een build-pijplijn kan uit veel verschillende stappen bestaan, maar moet minimaal het volgende bevatten:

• Code compileren: in ons geval betekent dat het compileren van Java-broncode in klassebestanden
• Tests uitvoeren: zoals het uitvoeren van unit-tests en mogelijk integratietests
• Artefacten implementeren: verpakking voldoet aan code in artefacten, zeg maar in pot bestanden, en het implementeren ervan

Als een applicatie verschillende technologieën gebruikt, dan extra stappen kunnen worden opgenomen in de build-pijplijn. We hebben bijvoorbeeld een extra stap die JavaScript-bestanden verkleint of bijgewerkte API-documentatie publiceert.

3. Wat is Travis CI?

Voor onze pijplijn voor het bouwen van monsters gebruiken we Travis CI, een cloudgebaseerde tool voor continue integratie.

Dit heeft een aantal functies die het een uitstekende keuze maken om aan de slag te gaan met build-pijplijnen:

• Integreert snel met elke openbare GitHub-repository
• Ondersteunt elke belangrijke programmeertaal
• Implementeert op meerdere verschillende cloudplatforms
• Biedt een verscheidenheid aan berichten- en waarschuwingstools

Op een hoog niveau werkt het door een GitHub-repository te monitoren op nieuwe commits.

Wanneer een nieuwe commit wordt gemaakt, voert het de stappen van de build-pijplijn uit zoals gedefinieerd in een configuratiebestand (meer hierover hieronder). Als een stap mislukt, wordt de pijplijn beëindigd en wordt ons hiervan op de hoogte gesteld.

Travis CI vereist uit de doos zeer weinig configuratie. De enige vereiste configuratie is het specificeren van de programmeertaal.

We kunnen altijd meer configuratie bieden om onze pijplijn aan te passen, indien nodig. We kunnen bijvoorbeeld beperken welke branches builds triggeren, extra stappen aan de pijplijn toevoegen en nog veel meer.

3.1. Gratis en betaalde versies

Het is belangrijk om te weten dat Travis CI momenteel 2 aanbiedingen heeft: een gratis en een betaalde versie.

De gratis versie, aangeduid met de .org domeinnaam, biedt alle mogelijkheden voor elke openbare GitHub-repository. Er zijn geen limieten aan het aantal builds of repositories, hoewel er resourcelimieten worden opgelegd wanneer uw pijplijn actief is.

De betaalde versie, die de .com domeinnaam, is vereist voor privé GitHub-opslagplaatsen. Het biedt ook meer gelijktijdige builds en onbeperkte buildminuten in vergelijking met het gratis abonnement. Er is een gratis proefversie voor de eerste 100 builds om de betaalde versie te testen.

4. Creëren van een Build Pipeline met Travis CI

Voor deze tutorial gebruiken we de hierboven genoemde gratis versie. Elke openbare repository kan worden gebruikt om een ​​gratis pijplijn te maken.

Het enige wat we hoeven te doen is inloggen op Travis CI met ons GitHub-account en het autoriseren:

Nadat we machtigingen hebben verleend aan ons GitHub-account, zijn we klaar om te beginnen met het configureren van onze build-pijplijn.

4.1. De repository configureren

In eerste instantie worden al onze openbare opslagplaatsen als inactief beschouwd. Om dit op te lossen, we moeten onze repository inschakelen vanaf de pagina met accountinstellingen.

Hierin staan ​​al onze openbare opslagplaatsen, samen met een schakelknop. Door op de schakelknop te klikken, wordt Travis CI geconfigureerd om die repository te monitoren op nieuwe commits, met behulp van de standaardtak van meester:

Merk op dat elke repository ook een Instellingen knop. Dit is waar we verschillende pijplijngedragingen kunnen configureren:

• Bepaal welke gebeurtenissen de pijplijn activeren (pushes, pull-aanvragen, enzovoort)
• Stel omgevingsvariabelen in die aan de pijplijn worden doorgegeven
• Auto-annuleer builds wanneer nieuwe evenementen worden geactiveerd

Voor deze zelfstudie werken de standaardinstellingen prima. Later zullen we zien hoe een deel van het standaardgedrag kan worden opgeheven.

4.2. De Travis-configuratie maken

De volgende stap is het maken van een nieuw bestand met de naam .travis.yml in de hoofdmap van onze repository. Dit bestand bevat alle informatie die nodig is om een ​​pijplijn te configureren. Zonder dit bestand wordt de pijplijn niet uitgevoerd.

Voor deze tutorial hoeven we alleen de absolute minimumconfiguratie op te nemen, die de programmeertaal specificeert:

taal: java

Dat is het! Zonder meer informatie te verstrekken, zal Travis CI een eenvoudige pijplijn uitvoeren die:

• Compileert onze broncode
• Voert onze tests uit

Zodra we het .travis.yml bestand Travis begint met onze eerste build. Elke verdere committeert zich aan meester branch zal extra builds activeren. Het dashboard stelt ons ook in staat om de pijplijn op elk moment handmatig te activeren zonder een vastleg- of pull-verzoek te vereisen.

5. Aanvullende configuratie

In de vorige sectie hebben we gezien dat een enkele configuratielijn alles is wat we nodig hebben om onze build-pijplijn uit te voeren. Maar de meeste projecten hebben extra configuratie nodig om een ​​zinvolle pijplijn te implementeren.

In dit gedeelte worden enkele van de handigere configuraties beschreven die we mogelijk aan onze pijplijn willen toevoegen.

5.1. De standaard build-opdracht wijzigen

De standaardopdracht die wordt gebruikt om Maven-projecten te bouwen, is:

mvn-test -B

We kunnen dit in elk commando veranderen door de script richtlijn in .travis.yml:

script: mvn-pakket -DskipTests

Het is mogelijk om meerdere commando's in een enkele keten aan elkaar te koppelen script lijn met behulp van de && operator.

Sommige build-opdrachten zijn complex en kunnen meerdere regels beslaan of een complexe logica hebben. Ze kunnen bijvoorbeeld verschillende acties uitvoeren op basis van omgevingsvariabelen.

In deze gevallen wordt aanbevolen om de build-opdracht in een zelfstandig script te plaatsen, en roep dat script aan vanuit het configuratiebestand:

script: ./build.sh

5.2. Code implementeren

De standaard build-instellingen voor Java-projecten compileren eenvoudig de code en voeren tests uit. De resulterende artefacten (.jar-bestanden, etc.) worden aan het einde van de pijplijn verwijderd, tenzij we ze ergens implementeren.

Travis CI ondersteunt een groot aantal bekende services van derden. Artefacten kunnen naar veel populaire cloudopslagsystemen worden gekopieerd, zoals Amazon S3, Google Cloud Storage, Bintray en meer.

Het kan ook code rechtstreeks implementeren op de meest populaire cloud computing-platforms zoals AWS, Google App Engine, Heroku en nog veel meer.

Hieronder ziet u een voorbeeldconfiguratie die laat zien hoe we kunnen implementeren op Heroku. Om versleutelde eigenschappen te genereren, moeten we de Travis CLI-tool gebruiken.

deploy: provider: heroku api_key: secure: "ENCRYPTED_API_KEY"

Bovendien biedt het een generieke implementatieoptie waarmee we ons eigen implementatiescript kunnen schrijven. Dit is handig als we artefacten moeten implementeren op een systeem van derden dat niet standaard wordt ondersteund.

We kunnen bijvoorbeeld een shellscript schrijven dat de artefacten veilig naar een privé-FTP-server kopieert:

implementeren: provider: scriptscript: bash ./custom-deploy.sh

5.3. Beheren welke filialen de pijplijn activeren

Standaard wordt de pijplijn uitgevoerd voor elke commit op meester. De meeste grote projecten gebruiken echter een vorm van git branching om ontwikkelingscycli te beheren.

Travis CI ondersteunt zowel witte als zwarte lijst van git-branches om te bepalen welke commits de pijplijn moeten activeren.

Beschouw als voorbeeld de volgende configuratie:

branches: alleen: - release - stabiel behalve: - master - nightly

Dit zou commits op de meester en nachtelijk takken. Zet zich in voor het vrijlating en stal takken zouden de pijplijn activeren. Merk op dat de enkel en alleen richtlijn heeft altijd voorrang op de behalve richtlijn.

We kunnen ook reguliere expressies gebruiken om te bepalen welke vertakkingen de pijplijn activeren:

branches: alleen: - /^development.*$/

Dit zou de pijplijn alleen starten voor commits op branches die beginnen met ontwikkeling.

5.4. Specifieke vastleggingen overslaan

We kunnen het git commit-bericht gebruiken om individuele commits over te slaan. Travis CI zal het bericht onderzoeken op de volgende patronen:

• overspringen
• overspringen

Waar is een van de volgende waarden:

• ci
• travis
• travis ci
• travis-ci
• travisci

Als het vastleggingsbericht overeenkomt met een van deze patronen, zal de pijplijn niet worden uitgevoerd.

5.5. Verschillende buildomgevingen gebruiken

De standaard build-omgeving voor Java-projecten is Ubuntu Linux. Pijplijnen kunnen ook worden uitgevoerd op Mac OSX of Windows Server door de volgende configuratie toe te voegen aan .travis.yml:

os: osx # kan ook 'windows' zijn

Zelfs met Linux zijn er 3 verschillende distributies waaruit we kunnen kiezen:

os: linux dist: xenial # andere keuzes zijn 'betrouwbaar' of 'nauwkeurig'

De documentatie van het buildplatform omvat alle beschikbare omgevingen en hun verschillen.

Houd er rekening mee dat als we het platform wijzigen, we mogelijk ook een aangepaste versie moeten wijzigen bouwen of inzetten scripts om compatibiliteit te garanderen. Er zijn verschillende manieren om met meerdere besturingssystemen in de configuratie om te gaan.

5.6. Verschillende JDK-versies gebruiken

We kunnen ook testen tegen een specifieke versie van de JDK door de volgende configuratie in het .travis.yml het dossier:

jdk: oraclejdk8

Houd er rekening mee dat verschillende build-omgevingen, zelfs de verschillende Linux-distributies, verschillende JDK-versies beschikbaar kunnen hebben. Raadpleeg de documentatie voor elke omgeving om de volledige lijst met JDK-versies te zien.

6. Bouw matrices

Elke keer dat onze pijplijn wordt uitgevoerd, wordt deze standaard als één taak uitgevoerd. Dit betekent dat alle fasen van de pijplijn opeenvolgend worden uitgevoerd op een enkele virtuele machine met dezelfde instellingen.

Maar een van de geweldige functies van Travis CI is de mogelijkheid om een ​​build-matrix te maken. Hierdoor kunnen we meerdere jobs uitvoeren voor elke commit, waarbij we verschillende waarden gebruiken voor enkele van de instellingen die we eerder zagen.

We kunnen bijvoorbeeld een build-matrix gebruiken om onze pijplijn op zowel Linux als Mac OSX te laten draaien, of met zowel JDK 8 als 9.

Er zijn twee manieren om build-matrices te maken. Eerste, we kunnen een reeks waarden opgeven voor een of meer van de taal- en omgevingsconfiguraties die we eerder zagen. Bijvoorbeeld:

taal: java jdk: - openjdk8 - openjdk9 os: - linux - osx

Door deze aanpak te gebruiken, zal Travis CI automatisch elke combinatie van configuratie uitbreiden om meerdere taken te vormen. In het bovenstaande voorbeeld zou het resultaat in totaal vier taken zijn.

De tweede manier om een ​​build-matrix te maken, is door de matrix. omvatten richtlijn. Hierdoor kunnen we expliciet aangeven welke combinaties we willen uitvoeren:

taal: java matrix: include: - jdk: openjdk8 os: linux - jdk: openjdk9 os: osx

Het bovenstaande voorbeeld zou resulteren in twee banen.

Nogmaals, als we op meerdere besturingssystemen voortbouwen, moeten we ervoor zorgen dat onze bouwen en inzet scripts werken voor alle gevallen. Shell-scripts werken bijvoorbeeld niet op Windows. We moeten de juiste voorwaardelijke verklaringen gebruiken om met verschillende besturingssystemen om te gaan.

Er zijn meer opties die gedetailleerdere controle bieden over welke taken moeten worden gecreëerd en hoe fouten moeten worden afgehandeld.

7. Conclusie

In dit artikel hebben we een eenvoudige build-pijplijn gemaakt met behulp van Travis CI. Gebruikmakend van de meeste kant-en-klare configuratie, hebben we een pijplijn gemaakt die code bouwt en tests uitvoert.

We hebben ook een klein voorbeeld gezien van hoe configureerbaar Travis CI is. Het werkt met verschillende programmeertalen en cloudplatforms van derden. Het enige nadeel is dat het momenteel alleen werkt met GitHub-repositories.