Ik moet vaak een pipeline bouwen voor het bouwen van projecten in Java. Soms is dit open source, soms niet. Onlangs besloot ik een deel van mijn repositories van Travis-CI en TeamCity naar GitHub Actions te verplaatsen, en dit is wat eruit gekomen is.
Wat we gaan automatiseren
Als eerste hebben we een project nodig dat we gaan automatiseren, laten we een eenvoudige applicatie maken met Spring Boot / Java 11 / Maven. In dit artikel is de logica van de applicatie niet van belang, de infrastructuur rond de applicatie is wat telt, dus een simpele REST API-controller is voldoende.
De broncode is hier te bekijken: alle stappen in het bouwen van de pipeline zijn vastgelegd in de pull-requests van dit project.
JIRA en planning
Het is vermeldenswaard dat we meestal JIRA gebruiken als task tracker, laten we daarom een apart bord voor dit project aanmaken en de eerste taken daarop zetten:
Later zullen we nog terugkomen op wat de combinatie van JIRA en GitHub ons kan bieden.
Automatiseren van de projectbouw
Ons testproject wordt via Maven gebouwd, dus de bouw is vrij eenvoudig, alles wat we nodig hebben is mvn clean package.
Om dit te doen met behulp van GitHub Actions, moeten we een bestand in de repository maken met de beschrijving van onze workflow, dit kan met een standaard yml-bestand. Ik kan niet zeggen dat ik 'programmeren in yml' leuk vind, maar wat moet je doen? We maken in de map .github/workflow een bestand build.yml aan waarin we de acties voor de bouw van de masterbranch beschrijven:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: zet JDK 11 op
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven package
run: mvn -B clean package -DskipTests
on — dit is de beschrijving van de gebeurtenis waarop ons script zal worden uitgevoerd.
on: pull_request / push — geeft aan dat deze workflow moet worden uitgevoerd bij elke push naar de master en bij het aanmaken van pull-requests.
Daarna volgt de beschrijving van de taken (jobs) en de stappen voor elke taak (steps) om te worden uitgevoerd.
runs-on — hier kunnen we het doelsysteem kiezen, verrassend genoeg kunnen we zelfs Mac OS kiezen, maar bij privé-repositories is dat een vrij dure optie (in vergelijking met Linux).
uses maakt het mogelijk om andere acties opnieuw te gebruiken, bijvoorbeeld, met de actie actions/setup-java zetten we de omgeving voor Java 11 op.
Met behulp van met we kunnen de parameters opgeven waarmee we de actie starten, in wezen zijn dit de argumenten die naar de actie worden doorgegeven.
We hoeven alleen nog de Maven-build van het project te starten: run: mvn -B clean package vlag -B geeft aan dat we de non-interactive mode nodig hebben, zodat Maven ons niet iets vraagt.
Geweldig! Nu wordt er bij elke commit naar master een build van het project gestart.
Automatiseren van testuitvoering
Builden is goed, maar in de praktijk kan een project succesvol worden gebouwd maar niet functioneren. Daarom moeten we ons in de volgende stap bezighouden met het automatiseren van de uitvoering van tests. Het is ook best handig om de testresultaten te bekijken wanneer je een PR-review doet – je weet precies dat de tests slagen en dat niemand vergeten is om hun branch te testen voordat ze mergen.
We zorgen ervoor dat tests worden uitgevoerd bij het aanmaken van een pull request en het mergen naar master, en we voegen ook het opbouwen van een rapport over code-dekking toe.
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Verify
run: mvn -B clean verify
- name: Test Coverage
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
Voor testdekking gebruik ik Codecov in combinatie met de Jacoco-plugin. Codecov heeft zijn eigen actie, maar daarvoor heeft het een token nodig voor onze pull request:
${{ secrets.CODECOV_TOKEN }} — deze constructie zullen we vaker tegenkomen, secrets is een mechanisme voor het opslaan van geheimen op GitHub, waar we wachtwoorden/tokens/hosts/urls en andere gegevens kunnen opslaan die we niet in de codebase willen tonen.
Een variabele aan secrets toevoegen kan in de instellingen van de repository op GitHub:
Het token kan verkregen worden op na autorisatie via GitHub, om een publiek project toe te voegen, hoef je alleen maar de link te volgen zoals: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Voeg de Jacoco-plugin toe aan het POM-bestand:
org.jacoco
jacoco-maven-plugin
0.8.4
prepare-agent
report
test
report
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
plain
**/*Test*.java
**/*IT*.java
Nu zal de codecov-bot bij elke pull request binnenkomen en een grafiek van de wijziging in dekking toevoegen:
Laten we een statische analyzer toevoegen
In de meeste van mijn open-source projecten gebruik ik Sonar Cloud voor statische code-analyse; het is vrij eenvoudig te koppelen aan Travis CI. Daarom is het logisch om hetzelfde te doen bij de migratie naar GitHub Actions. Marketingacties zijn een geweldige functie, maar deze keer haalden ze me een beetje in de steek, omdat ik uit gewoonte de benodigde actie vond en deze in de workflow zette. Maar het bleek dat Sonar geen ondersteuning biedt voor projecten die met Maven of Gradle via een actie worden geanalyseerd. Dit staat natuurlijk in de documentatie, maar wie leest die nou?!
Via actie lukt het niet, dus we gaan het doen via de mvn-plugin:
name: SonarCloud
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Set up JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyze with SonarCloud
# set environment variables:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# run sonar maven plugin:
run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml
SONAR_TOKEN kan worden verkregen op en moet in secrets worden geconfigureerd. GITHUB_TOKEN is een ingebouwde token die door GitHub wordt gegenereerd, waarmee sonarcloud[bot] kan autoriseren in Git om ons berichten te laten achterlaten in pull requests.
Dsonar.projectKey is de projectnaam in Sonar, die je kunt vinden in de projectinstellingen.
Dsonar.organization is de organisatienaam op GitHub.
We maken een pull request en wachten op de komst van sonarcloud[bot] in de opmerkingen:
Release management
De build is ingesteld, de tests zijn uitgevoerd, laten we een release maken. Laten we bekijken hoe GitHub Actions het release management aanzienlijk vereenvoudigt.
Op mijn werk heb ik projecten waarvan de codebase in bitbucket ligt (zoals in het verhaal 'overdag schrijf ik naar bitbucket, 's nachts commit ik naar GitHub'). Helaas heeft bitbucket geen ingebouwde tools voor releasebeheer. Dit is problematisch, omdat ik voor elke release handmatig een pagina in confluence moet aanmaken, waarbij ik alle functies die in de release zijn opgenomen moet verzamelen, brainstormen, taken in jira moet doorlopen en commits in de repository moet nalopen. Er zijn veel kansen om fouten te maken, iets te vergeten of iets te noteren dat al in de vorige release zat; soms is het gewoon niet duidelijk tot welke categorie een pull request behoort — is het een functie, een bugfix, een testaanpassing of iets infrastructuurlijks?
Hoe kan GitHub actions ons helpen? Er is een geweldige actie — release drafter, die het mogelijk maakt om een sjabloon voor het release notes bestand in te stellen, zodat je de categorieën van pull requests kunt definiëren en deze automatisch in het release notes bestand kunt groeperen:
Voorbeeldsjabloon voor het instellen van het rapport (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Nieuwe Functies'
labels:
- 'type:features'
# in deze categorie verzamelen we alle PR's met het label type:features
- title: ' Bugfixes'
labels:
- 'type:fix'
# hetzelfde geldt voor het label type:fix, enzovoort.
- title: ' Documentatie'
labels:
- 'type:documentation'
- title: ' Configuratie'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Wijzigingen
$CHANGES
Voeg een script toe voor het genereren van een release-draft (.github/workflows/release-draft.yml):
name: "Maak conceptrelease aan"
on:
push:
branches:
- master
jobs:
update_draft_release:
runs-on: ubuntu-18.04
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Alle pull requests vanaf dit moment worden automatisch verzameld in release notes — magie!
Hier kan een vraag opkomen: wat als ontwikkelaars vergeten de labels in de PR te plaatsen? Dan is het onduidelijk in welke categorie deze moet worden ondergebracht en moet ik opnieuw handmatig met elke PR aan de slag. Om dit probleem op te lossen, kunnen we ook een andere actie gebruiken — label verifier — die controleert of er tags op de pull request aanwezig zijn. Als er geen verplichte tags zijn, zal de controle falen en zullen we daar een melding van zien in onze pull request.
name: "Verifieer type labels"
on:
pull_request:
types: [opened, labeled, unlabeled, synchronize]
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: zwaldowski/match-label-action@v2
with:
allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'
Nu moet elke pull request worden gemarkeerd met een van de tags: type:fix, type:features, type:documentation, type:tests, type:config.
Automatische annotatie van pull-verzoeken
Aangezien we het hebben gehad over een onderwerp zoals effectief werken met pull-verzoeken, is het goed om ook een actie te noemen, namelijk de labeler, die labels aan PR's toekent op basis van de gewijzigde bestanden. Bijvoorbeeld, we kunnen elke pull-request in de map als [build] labelen. .github/workflow.
Het is vrij eenvoudig om het aan te sluiten:
name: "Automatisch thema's toewijzen aan PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
We hebben ook een bestand nodig dat de mapping van projectmappen naar thema's van pull-verzoeken beschrijft:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Het lukte me niet om de actie die automatisch labels aan pull-verzoeken toewijst te combineren met de actie die controleert op verplichte labels; match-label wil de door de bot toegewezen labels niet herkennen. Het lijkt eenvoudiger om mijn eigen actie te schrijven die beide fasen combineert. Maar zelfs in deze vorm is het vrij handig, je moet een label uit de lijst kiezen bij het aanmaken van een pull-request.
Het is tijd om te deployen
Ik heb verschillende variant van deploying via GitHub Actions (via ssh, via scp, en met behulp van docker-hub) geprobeerd, en ik kan zeggen dat je waarschijnlijk een manier zult vinden om de binaire bestanden naar de server te uploaden, hoe ongebruikelijk je pipeline ook is.
Ik vond het fijn om alle infrastructuur op één plek te hebben, dus laten we bekijken hoe we kunnen deployen naar GitHub Packages (dit is een repository voor binaire inhoud, npm, jar, docker).
Script voor het bouwen van een docker-image en het publiceren ervan in GitHub Packages:
naam: Docker-afbeelding implementeren
op:
push:
takken:
- 'master'
banen:
build_docker_image:
draait-op: ubuntu-18.04
stappen:
# Bouw JAR:
- gebruikt: actions/checkout@v1
- naam: JDK 11 instellen
gebruikt: actions/setup-java@v1
met:
java-versie: 1.11
- naam: Maven Package
run: mvn -B clean compile package -DskipTests
# Stel globale omgevingsvariabelen in:
- naam: globale env instellen
id: global_env
run: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"
# Bouw Docker-afbeelding:
- naam: Afbeelding bouwen en taggen
run: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- naam: Docker-inloggen
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publiceer afbeelding naar GitHub-pakketrepository:
- naam: Afbeelding publiceren
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Om te beginnen moeten we het JAR-bestand van onze applicatie bouwen, waarna we het pad naar de GitHub Docker-registry en de naam van onze afbeelding berekenen. Hier zijn een paar trucs die we nog niet eerder zijn tegengekomen:
- Een constructie zoals: echo «::set-output name=NAME::VALUE» stelt ons in staat om de waarde van een variabele in de huidige stap in te stellen, zodat deze later in alle andere stappen kan worden gelezen.
- Om de waarde van de variabele die in de voorafgaande stap is ingesteld, te verkrijgen, kunnen we de identificatie van die stap gebruiken: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- In de standaardvariabele GITHUB_REPOSITORY staat de naam van de repository en de eigenaar (‘owner/repo-name’). Om alles behalve de naam van de repository uit deze string te halen, maken we gebruik van bash-syntaxis: ${GITHUB_REPOSITORY#*/}
Vervolgens moeten we de Docker-afbeelding bouwen:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Ja, inloggen bij de registry:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
En publiceer de afbeelding in de GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Om de versie van de afbeelding aan te geven, gebruiken we de eerste cijfers van de SHA-hash van de commit — GITHUB_SHA heeft hier ook zijn hoogtepunten, als je dergelijke builds niet alleen tijdens een merge in master uitvoert, maar ook bij het maken van een pull request, kan de SHA niet overeenkomen met de hash die we in de git-geschiedenis zien, omdat de actie actions/checkout zijn unieke hash maakt om wederzijdse blokkades van acties in PR te vermijden.
Als alles goed gaat, zie je een nieuwe Docker-afbeelding als je het gedeelte packages (https://github.com/antkorwin/github-actions/packages) in de repository opent:
Hier kun je ook de lijst met versies van de Docker-image bekijken.
We hoeven alleen ons server in te stellen om met deze registry te werken en de service opnieuw te starten. Hoe we dit via systemd doen, bespreek ik een andere keer.
Monitoring
Laten we kijken naar een eenvoudige manier om de health check van onze applicatie uit te voeren met behulp van GitHub Actions. In onze bootapplicatie is er een actuator, dus we hoeven zelfs geen API voor statuscontroles te schrijven; voor de luie mensen is alles al gedaan. We hoeven alleen maar te pingen: SERVER-URL:PORT/actuator/health
$ curl -v 127.0.0.1:8080/actuator/health
> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT
{"status":"UP"}
Alles wat we nodig hebben, is een taak voor servercontrole via cron te schrijven, en als hij ons niet antwoordt, sturen we een melding naar Telegram.
Laten we eerst eens kijken hoe we een workflow via cron kunnen starten:
on:
schedule:
- cron: '*\/5 * * * *'
Heel eenvoudig, je kunt bijna niet geloven dat je zulke evenementen in GitHub kunt maken die helemaal niet passen binnen de webhooks. Details zijn te vinden in de documentatie:
We controleren de status van de server handmatig via curl:
jobs:
ping:
runs-on: ubuntu-18.04
steps:
- name: curl actuator
id: ping
run: |
echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"
- name: health check
run: |
if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
echo "health check is mislukt"
exit 1
fi
echo "Het is OK"
Eerst slaan we op wat de server antwoordt op de aanvraag in een variabele, en in de volgende stap controleren we of de status UP is, en als dat niet zo is, stappen we uit met een foutmelding. Als we de actie handmatig willen 'verknallen', dan exit 1 — is een geschikt wapen.
- name: stuur waarschuwing in Telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check van de:
${{secrets.SERVER_HOST}}/api/actuator/health
is mislukt met het resultaat:
${{ steps.ping.outputs.status }}
We sturen een melding naar Telegram, maar alleen als de actie mislukt is in de vorige stap. Voor het verzenden van het bericht gebruiken we appleboy/telegram-action. Hoe je een bot-token en chat-id kunt krijgen, lees je in de documentatie:
Vergeet niet de server-URL en de tokens voor de Telegram-bot in de geheimen op GitHub in te voeren.
Bonus track: JIRA voor de lui
Ik heb beloofd dat we terug zouden komen op JIRA, en we zijn terug. Honderden keren heb ik tijdens de stand-ups situations gezien waarin ontwikkelaars een functie hadden gemaakt, de tak hadden samengevoegd, maar vergeten waren om de taak in JIRA te verplaatsen. Natuurlijk zou het gemakkelijker zijn als alles op één plek zou gebeuren, maar feitelijk schrijven we code in een IDE, voegen we takken samen in Bitbucket of GitHub, en verplaatsen we de taken naar JIRA, waarvoor we nieuwe vensters moeten openen, soms opnieuw moeten inloggen, enzovoort. Wanneer je precies weet wat je verder moet doen, is het geen zin om de board nog een keer te openen. Uiteindelijk moet er 's ochtends tijdens de stand-up tijd worden besteed aan het actualiseren van het takenbord.
GitHub zal ons ook helpen bij deze routinematige taak; in eerste instantie kunnen we taken automatisch verplaatsen naar de kolom code_review wanneer we een pull request indienen. Het enige wat nodig is, is om je aan de afspraken bij het noemen van takken te houden:
[project_name]-[task_number]-naam
bijvoorbeeld, als de project sleutel "GitHub Actions" GA is, dan GA-8-jira-bot kan een tak zijn voor de implementatie van de taak GA-8.
De integratie met JIRA werkt via acties van Atlassian, ze zijn niet perfect; ik moet zeggen dat sommige voor mij helemaal niet hebben gewerkt. Maar we zullen alleen die bespreken die zeker werken en actief worden gebruikt.
Om te beginnen moet er autorisatie in JIRA worden verkregen via de actie: atlassian/gajira-login
jobs:
build:
runs-on: ubuntu-latest
name: Jira Workflow
steps:
- name: Login
uses: atlassian/gajira-login@master
env:
JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
Hiervoor moet je een token in JIRA verkrijgen, hoe je dat doet, wordt hier beschreven:
We halen de taak-ID uit de naam van de tak:
- name: Find Issue
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo branch name: $GITHUB_HEAD_REF
echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Check Issue
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Geef je tak een naam overeenkomstig het JIRA-onderwerp: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succesvol gevonden JIRA-onderwerp: ${{steps.find_issue.outputs.ISSUE_ID}}
Als je in de GitHub marketplace zoekt, kun je een actie voor deze taak vinden, maar ik moest hetzelfde schrijven met grep op de naam van de tak, omdat deze actie van Atlassian op mijn project helemaal niet wilde werken; uitzoeken wat er aan de hand was, duurde langer dan het zelf ook handmatig te doen.
Verplaats de taak gewoon naar de kolom 'Code review' bij het aanmaken van een pull request:
- name: Taak overzetten
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Hiervoor is er een speciale actie op GitHub, alles wat je nodig hebt is de taak-ID die je in de vorige stap hebt verkregen en de authenticatie in JIRA die we eerder hebben gedaan.
Op dezelfde manier kun je taken verplaatsen tijdens een merge naar master en bij andere gebeurtenissen in de GitHub workflow. Kortom, alles hangt af van je creativiteit en de wens om routinetaken te automatiseren.
Conclusies
Als we kijken naar het klassieke DEVOPS-diagram, hebben we alle stappen behandeld, afgezien van operate. Ik denk dat we, als we ons best doen, een actie kunnen vinden in de marketplace voor integratie met een helpdesk-systeem, dus laten we aannemen dat de pipeline grondig is en op basis van het gebruik daarvan conclusies kunnen worden getrokken.
Voordelen:
- De marketplace met kant-en-klare acties voor elke situatie is echt geweldig. Bij de meeste kun je ook de broncode bekijken, zodat je kunt begrijpen hoe je een soortgelijke taak kunt oplossen of een feature request rechtstreeks aan de auteur in de GitHub-repository kunt plaatsen.
- De keuze van het doelplatform voor de build: Linux, macOS, Windows is een vrij interessante functie.
- Github Packages is geweldig, het is handig om alle infrastructuur op één plek te hebben, je hoeft niet door verschillende vensters te surfen, alles is binnen een of twee muisklikken en perfect geïntegreerd met GitHub Actions. Ondersteuning voor de Docker registry in de gratis versie is ook een mooi voordeel.
- GitHub verstopt geheimen in de buildlogs, dus het is niet zo eng om het te gebruiken voor het opslaan van wachtwoorden en tokens. Gedurende al mijn experimenten heb ik nog nooit een geheim in zijn geheel in de console gezien.
- Gratis voor Open Source-projecten
Nadelen:
- YML, ik hou er niet van. Tijdens het werken met zo'n flow is mijn meest voorkomende commit message 'fix yml format'; dan vergat je ergens een tab in te voegen, of schreef je het niet op de goede regel. Kortom, voor het scherm zitten met een passer en een liniaal is niet de meest aangename bezigheid.
- DEBUG, het debuggen van de flow met commits, het starten van een nieuwe build en het afdrukken in de console is niet altijd handig, maar dat valt meer onder de categorie 'je hebt het jezelf te gemakkelijk gemaakt', gewend aan het werken met handige IDE's waarin je alles kunt debuggen.
- Je kunt een actie op elk platform schrijven als je het in Docker verpakt, maar native wordt alleen JavaScript ondersteund. Natuurlijk is dit een kwestie van smaak, maar ik zou liever iets anders dan js kiezen.
Ter herinnering, de repository met alle scripts staat hier:
Volgende week zal ik een geven op de Heisenbug 2020 Piter conferentie. Ik zal niet alleen uitleggen hoe je fouten bij het voorbereiden van testgegevens kunt voorkomen, maar ook mijn geheimen delen over het werken met datasets in Java-toepassingen!
Bron: habr.com
