Continue integratie is cruciaal voor elke actieve repository die routinematig moet worden gebouwd en getest. Github ondersteunt CI-pipelines in de vorm van Github Actions-builds die automatisch in de cloud worden uitgevoerd, met slechts een beetje setup.
Wat is continue integratie?
Hoewel sommige codebases, zoals bepaalde web-apps, rechtstreeks vanuit hun bronbestanden kunnen worden geïmplementeerd, vereisen andere aanvullende verwerking, compilatie en, belangrijker nog, unit-testing. Deze builds kunnen ingewikkeld zijn en zelfs arbeidsintensief in het geval van talen als C++.
Continuous Integration is het proces van het automatiseren van testen en bouwen voor nieuwe commits aan je broncode. Gewoonlijk wordt dit gebruikt met software zoals Jenkins die draait op een "build-server" die de eigenlijke compilatie zal afhandelen.
Geautomatiseerde codecompilatie is zo'n nuttige service voor softwareteams dat het nu wordt aangeboden door cloudproviders, waaronder Github, waar het goed integreert met de rest van hun services.
Wat zijn Github-acties?
Github-acties zijn cloudgebaseerde taken die kunnen worden gebruikt om uw repository te automatiseren. Ze worden vaak gebruikt om geautomatiseerde builds uit te voeren voor nieuwe commits of releases, wat handig kan zijn voor continue softwaretests. Ze kunnen echter ook worden gebruikt voor niet-CI-gerelateerde automatisering, zoals het werken met problemen en pull-verzoeken, het uitvoeren van
cron-taken of het activeren van opdrachten op basis van acties in uw account.
Wat CI betreft, zijn Github-acties best handig. Voor de meeste CI-pipelines moet u ingewikkelde software zoals Jenkins instellen of een specifieke cloudservice gebruiken, zoals AWS CodePipeline. Github-acties zijn heel eenvoudig en u hoeft alleen maar een configuratiebestand te committen aan
github/workflows/ om een actie mogelijk te maken.
Bovendien is Github meestal in staat om op te pikken wat voor soort project je maakt en suggesties te doen voor actieconfiguraties uit de bibliotheek met voorbeelden. Dit Java-project was bijvoorbeeld binnen een paar minuten operationeel met geautomatiseerde builds met enkele kleine aanpassingen aan
U kunt meerdere acties in dezelfde repo hebben; bijvoorbeeld, misschien wil je geautomatiseerde builds instellen voor elke commit op de
dev
branch, maar je wilt alleen builds voor elke nieuwe getagde release op de
mastertak. U kunt twee afzonderlijke YAML-bestanden maken met verschillende criteria.
Hoewel Actions erg handig zijn voor het doen van builds en testen, kunnen ze ook opdrachten uitvoeren en verbinding maken met andere services, waardoor ze ook de leverings- en implementatieprocessen kunnen automatiseren. U kunt bijvoorbeeld een actie hebben op de
release branch, elke nieuwe getagde release nemen en deze uploaden naar uw servers voor implementatie.
Standaard publiceren Github Actions-builds build-artefacten (wat er ook is uitgevoerd door het bouwproces) naar een zip-bestand voor elke run. Dit werkt goed als je alleen tests uitvoert, maar als je geautomatiseerde levering wilt doen, kun je ze ook instellen om automatisch nieuwe releases te publiceren, of naar een pakket-/containerregister zoals NPM of de Docker-hub te pushen.
De exacte configuratie voor je repository zal variëren, afhankelijk van wat je bouwproces is, maar Github levert goed werk door solide voorbeelden te geven om mee te beginnen, en de algemene opzet is grotendeels hetzelfde. Als je meer wilt weten over aan de slag gaan met GH Actions, kun je onze handleiding over het instellen ervan lezen.
Github Acties Prijzen
Gelukkig heeft Github het geld om open-sourcesoftware te sponsoren, dus Actions zijn volledig gratis voor openbare repositories. Je kunt ze zoveel gebruiken als je wilt, of zoveel build-artefacten opslaan als je wilt - er is geen harde limiet tenzij je beledigend bent, net als de rest van Github.
Voor privérepositories heeft elk account automatisch 2000 minuten aan bouwtijd per maand, wat erg genereus is. Dat is bijna anderhalve dag continu bouwen, dus je zou een aantal serieus lange builds moeten doen - of tonnen commits - om dat aantal te halen. Je hebt meer kans om de opslaglimiet van 500 MB te bereiken voor gratis accounts. Als je echter voortbouwt op elke commit, met lange bouwtijden en vaak commit, kun je dat aantal opraken.
Github Pro-gebruikers ($4/maand) krijgen 3000 minuten en 1 GB opslagruimte, net als organisaties die het Github Team-abonnement gebruiken, dat is $4 per gebruiker, per maand.
Github Enterprise, dat $ 21 per gebruiker per maand kost, geeft 50.000 minuten aan buildminuten, dat zijn 35 opeenvolgende dagen aan builds, waardoor je 24/7 builds kunt draaien en nog wat.
Als je een abonnement overneemt, wordt je gewoon gefactureerd voor de extra gebruikte minuten. De tarieven zijn redelijk, met een extra 2000 minuten die $ 16 kost.
Moet je acties of je eigen build-server gebruiken?
CI/CD begint met het bijhouden van versiebeheer. Geautomatiseerde builds worden meestal uitgevoerd voor elke commit of major release, en de meeste standalone build-serversystemen, zoals Jenkins of TeamCity, zullen integreren met uw
git repository om deze functionaliteit te bieden.
Dit maakt de eigen CI-oplossing van Github behoorlijk nuttig in vergelijking - het is rechtstreeks geïntegreerd in de service die u al gebruikt en is uiterst eenvoudig om aan de slag te gaan. Het enige wat je hoeft te doen is het build-configuratiebestand te committen naar je
github map, en Github zal het oppakken en uitvoeren. Hoewel zelfstandige services nuttig kunnen zijn voor bedrijfsimplementaties, is de eenvoud van het gebruik van Github Actions voor de gemiddelde gebruiker eenvoudiger dan zelfs het installeren van een op maat gemaakte server.
Github-acties kunnen ook worden gebruikt voor meer dan alleen geautomatiseerde builds. Ze ondersteunen alle soorten repository-automatisering, inclusief het werken met problemen en pull-verzoeken.
Dat gezegd hebbende, Github-acties zijn niet zo volledig uitgerust als het runnen van je eigen server, en als je veel reguliere of gecompliceerde builds doet, moet je kijken naar het opzetten van een Jenkins-server. Als je veel CPU-intensieve builds doet, kan Jenkins daar ook goed voor zijn, maar Github Actions ondersteunt ook het gebruik van je eigen server om builds op uit te voeren.
