{"id":55129,"date":"2023-08-21T15:11:12","date_gmt":"2023-08-21T13:11:12","guid":{"rendered":"https:\/\/kinsta.com\/nl\/?p=55129&preview=true&preview_id=55129"},"modified":"2023-08-30T10:32:59","modified_gmt":"2023-08-30T08:32:59","slug":"ci-cd-pipeline-maken","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/ci-cd-pipeline-maken\/","title":{"rendered":"Zo maak je een CI\/CD pipeline met GitHub Actions en Kinsta API"},"content":{"rendered":"

In de snelle wereld van webdevelopment<\/a> zijn continuous integration en continuous deployment (CI\/CD<\/a>) onmisbare praktijken geworden om effici\u00ebnt software van hoge kwaliteit te leveren. Met CI\/CD kunnen developers het proces van bouwen, testen en deployen van codewijzigingen automatiseren, het risico op menselijke fouten verkleinen en snellere iteraties mogelijk maken.<\/p>\n

Dit artikel legt het belang uit van CI\/CD, hoe je een CI pipeline maakt, en hoe je continuous deployment in je CI pipeline met de Kinsta API<\/a> programmatisch kunt instellen – allemaal met GitHub Actions in je GitHub<\/a> repository.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Waarom CI\/CD gebruiken?<\/h2>\n

Kinsta’s Applicatie Hosting<\/a> platform heeft altijd een optie geboden voor automatische deployment, die wordt geactiveerd zodra er een wijziging is op een specifieke branch op je gehoste Git repository. Dit is echter niet altijd ideaal voor grote projecten met meerdere teamleden. Veel developers<\/a> hebben de neiging om automatische deployment om verschillende redenen te vermijden.<\/p>\n

E\u00e9n reden is dat, in een samenwerkingsomgeving waar meerdere developers aan hetzelfde project werken, automatische deployments die worden geactiveerd door een wijziging van \u00e9\u00e9n developer aan het repository, kunnen leiden tot instabiliteit en onvoorziene problemen. Zonder goed testen en valideren kan zelfs een kleine codewijziging de live site verstoren, wat kan leiden tot downtime en negatieve gebruikerservaringen.<\/p>\n

Dit is waar een CI\/CD pipeline van pas kan komen. Door een zorgvuldig georkestreerde CI\/CD workflow te cre\u00ebren, kunnen developers ervoor zorgen dat codewijzigingen worden getest en gevalideerd voordat ze worden ingezet op de live site. Er zijn veel tools beschikbaar voor het implementeren van CI\/CD in softwareontwikkeling, we zullen GitHub Actions<\/a> gebruiken voor deze tutorial.<\/p>\n

Wat is GitHub Actions?<\/h2>\n

GitHub Actions is een krachtige automatiseringstool van GitHub. Het biedt developers de mogelijkheid om verschillende jobs, processen en workflows binnen hun softwareontwikkelingsprojecten te automatiseren. Het integreert met GitHub repositories, waardoor het gemakkelijk te gebruiken is.<\/p>\n

Met GitHub Actions en de Kinsta API<\/a> kun je aangepaste workflows defini\u00ebren die passen bij de eisen van je project. Je kunt een CI pipeline opzetten die je applicatie test en de deployment op Kinsta activeert.<\/p>\n

Aan de slag met GitHub Actions<\/h2>\n

GitHub Actions werkt op het concept van workflows, dat zijn sets van geautomatiseerde jobs die worden geactiveerd door specifieke gebeurtenissen of gepland op regelmatige tijdstippen. Deze gebeurtenissen kunnen code pushes, pull requests, issue creatie en meer zijn. Als een van deze gebeurtenissen plaatsvindt, voert GitHub Actions automatisch een bijbehorende workflow uit, waarbij een reeks vooraf gedefinieerde stappen wordt uitgevoerd.<\/p>\n

Elke stap in de workflow vertegenwoordigt een bepaalde actie, zoals het bouwen van de code, het uitvoeren van tests, het implementeren of het versturen van meldingen. Laten we een workflow met drie jobs maken:<\/p>\n

    \n
  1. Syntax controleren met ESLint<\/li>\n
  2. Testen uitvoeren<\/li>\n
  3. Je applicatie opnieuw deployen<\/li>\n<\/ol>\n

    Stap 1: Je GitHub repository instellen<\/h3>\n

    Om aan de slag te gaan met GitHub Actions, heb je een GitHub repository nodig.<\/p>\n

    Hier gebruiken we deze GitHub repository<\/a>, ontwikkeld voor de tutorial Zo bouw en deploy je een ChatGPT kloonapplicatie met React en OpenAI API<\/a>.<\/p>\n

    Voel je vrij om de repository zelf te gebruiken door ernaar te navigeren op GitHub en te kiezen voor: Use this template<\/strong> > Create a new repository<\/strong>.<\/p>\n

    In deze React applicatie zijn unit tests gemaakt om elk onderdeel te testen. ESLint wordt ook gebruikt om een perfecte syntaxis en codeopmaak af te dwingen. De CI pipeline blokkeert een deployment als een pull request of samengevoegde code die naar de repository is gepusht niet voldoet aan de workflowtests.<\/p>\n

    Stap 2: Een workflowbestand maken<\/h3>\n

    Definieer je workflow door een YAML bestand te maken in de .github\/workflows<\/strong> map van je repository. Deze map moet op het hoofdniveau van je archief staan. De naamgevingsconventie voor workflowbestanden is naam-van-de-workflow.yml<\/strong>.<\/p>\n

      \n
    1. Maak in je archief een .github<\/strong> map aan.<\/li>\n
    2. Maak in de .github<\/strong> map een nieuwe map genaamd workflows<\/strong>.<\/li>\n
    3. Maak in de map workflows een nieuw bestand aan met een naam als build-test-deploy.yml<\/strong>.<\/li>\n<\/ol>\n

      Stap 3: De CI\/CD workflow schrijven<\/h3>\n

      Nu je je workflowbestand hebt gemaakt, definieer je een workflow met de benodigde stappen om de syntax te controleren met ESLint, tests uit te voeren en de applicatie te deployen.<\/p>\n

      Cre\u00eber CI event<\/h4>\n

      Bij het maken van een CI pipeline is de eerste stap het geven van een naam aan de workflow en vervolgens het instellen van het event die de workflow activeert. In dit voorbeeld zijn de twee events een pull request en een push naar de main branch.<\/p>\n

      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"<\/code><\/pre>\n
      Als je periodieke jobs (CRON jobs) wilt plannen voor specifieke jobs, dan kun je die toevoegen aan de workflow. Je zou bijvoorbeeld bepaalde jobs willen uitvoeren zoals database backups, gegevens opschonen of andere periodieke onderhoudsjobs.<\/p>\n
      Hier is een voorbeeld van hoe je een CRON job aan de workflow kunt toevoegen:<\/p>\n
      on:\n  # Existing event triggers for push and pull_request\n\n  # Add a schedule for CRON jobs\n  schedule:\n    - cron: \"0 0 * * *\"<\/code><\/pre>\n
      Het bovenstaande voorbeeld zal de workflow elke dag om middernacht (UTC-tijd) triggeren, omdat het cron-schema is ingesteld op 0 0 * * *<\/code>. Je kunt het cron-schema aanpassen aan je specifieke behoeften.<\/p>\n
      Een ander voorbeeld: stel dat je de CI\/CD workflow wilt plannen om elke maandag om 8 uur ’s ochtends te starten. We kunnen een CRON job instellen met behulp van het schedule<\/code> event:<\/p>\n
      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"\n\n  # Schedule the workflow to run every Monday at 8 a.m. (UTC time)\n  schedule:\n    - cron: \"0 8 * * 1\"\n\njobs:\n # Add jobs<\/code><\/pre>\n
      De planning syntaxis die gebruikt wordt in het schedule<\/code> event voor GitHub Actions workflows is gebaseerd op de UNIX cron syntaxis. Hiermee kun je specifieke tijden of intervallen defini\u00ebren waarop je workflow automatisch moet worden uitgevoerd. De syntaxis bestaat uit vijf velden die verschillende aspecten van de planning vertegenwoordigen. Elk veld wordt gescheiden door een spatie. Het algemene formaat van de schema syntaxis is als volgt:<\/p>\n
      * * * * *\n\u252c \u252c \u252c \u252c \u252c\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of the week (0 - 7) (Sunday to Saturday, where both 0 and 7 represent Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1 - 12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of the month (1 - 31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0 - 23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0 - 59)<\/code><\/pre>\n
      Laten we nu elk veld even langsgaan:<\/p>\n