Jeg skal ofte bygge en pipeline til byggeprojekter i Java. Nogle gange er det open source, nogle gange er det ikke. Jeg besluttede for nylig at prøve at flytte nogle af mine depoter fra Travis-CI og TeamCity til GitHub Actions, og det er det, der kom ud af det.
Hvad vil vi automatisere?
Først har vi brug for et projekt, som vi vil automatisere, lad os lave en lille applikation i Spring boot / Java 11 / Maven. I forbindelse med denne artikel vil vi overhovedet ikke være interesserede i applikationslogikken; infrastrukturen omkring applikationen er vigtig for os, så en simpel REST API-controller vil være tilstrækkelig for os.
Du kan se kilderne her: Alle stadier af opbygningen af en pipeline afspejles i pull-anmodningerne for dette projekt.
JIRA og planlægning
Det er værd at sige, at vi normalt bruger JIRA som en problemsporing, så lad os oprette en separat bestyrelse for dette projekt og tilføje de første problemer der:
Lidt senere vender vi tilbage til, hvilke interessante ting JIRA og GitHub kan tilbyde i kombination.
Vi automatiserer montagen af projektet
Vores testprojekt er bygget via maven, så det er ret simpelt at bygge det, alt hvad vi behøver er mvn clean-pakken.
For at gøre dette ved hjælp af Github Actions, skal vi oprette en fil i depotet, der beskriver vores arbejdsgang, dette kan gøres med en almindelig yml-fil, jeg kan ikke sige, at jeg kan lide "yml-programmering", men hvad kan vi gøre - vi gør det i .github/ directory workflow/ filen build.yml, hvori vi vil beskrive handlingerne, når vi bygger mastergrenen:
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 Package
run: mvn -B clean package -DskipTests
on — dette er en beskrivelse af begivenheden, hvor vores script vil blive lanceret.
på: pull_request/push — angiver, at denne arbejdsgang skal startes, hver gang der foretages et push til masteren, og der oprettes pull-anmodninger.
Det følgende er en beskrivelse af opgaverne (job) og udførelsestrin (trin) for hver opgave.
kører videre - her kan vi vælge mål-OS, overraskende nok kan du endda vælge Mac OS, men på private repositories er dette ret dyrt (sammenlignet med Linux).
bruger giver dig mulighed for at genbruge andre handlinger, for eksempel ved at bruge handlingen/setup-java-handlingen, vi installerer miljøet til Java 11.
Ved hjælp af med vi kan angive de parametre, som vi starter handlingen med, i det væsentlige er disse argumenter, der vil blive videregivet til handlingen.
Det eneste, der er tilbage, er at køre projektopbygningen med Maven: run: mvn -B clean package flag -B siger, at vi har brug for en ikke-interaktiv tilstand, så maven pludselig ikke vil spørge os om noget
Store! Nu, hver gang du forpligter dig til masteren, starter projektopbygningen.
Automatisering af testlanceringer
Montering er god, men i virkeligheden kan et projekt samles sikkert, men ikke fungere. Derfor er næste trin at automatisere testkørslerne. Derudover er det ganske praktisk at se på resultaterne af bestået testene, når du laver en PR-gennemgang - du ved med sikkerhed, at testene består, og ingen glemte at køre deres afdeling, før du lavede en sammenlægning.
Vi vil køre test, når vi opretter en pull request og flette ind i masteren, og samtidig tilføjer vi oprettelsen af en rapport om kodedækning.
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 }}
For at dække tests bruger jeg codecov sammen med jacoco plugin. codecov har sin egen handling, men den har brug for et token for at fungere med vores pull request:
${{ secrets.CODECOV_TOKEN }} — vi vil se denne konstruktion mere end én gang, hemmeligheder er en mekanisme til lagring af hemmeligheder i GitHub, vi kan skrive passwords/tokens/hosts/urls og andre data der ikke bør inkluderes i depotets kodebase.
Du kan tilføje en variabel til hemmeligheder i lagerindstillingerne på GitHub:
Du kan få et token kl Efter autorisation via GitHub, for at tilføje et offentligt projekt, skal du blot følge et link som dette: /[reponavn]. Et privat lager kan også tilføjes; for at gøre dette skal du give codecov-rettigheder til applikationen i Github.
Tilføj jacoco-pluginnet til POM-filen:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<!-- attached to Maven test phase -->
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<reportFormat>plain</reportFormat>
<includes>
<include>**/*Test*.java</include>
<include>**/*IT*.java</include>
</includes>
</configuration>
</plugin>
Nu vil codecov-botten indtaste hver af vores pull-anmodninger og tilføje en dækningsændringsgraf:
Lad os tilføje en statisk analysator
I de fleste af mine open source-projekter bruger jeg sonar cloud til statisk kodeanalyse, det er ret nemt at oprette forbindelse til travis-ci. Så det er et logisk skridt, når du migrerer til GitHub Actions, at gøre det samme. Actionmarkedet er en cool ting, men denne gang svigtede det mig lidt, fordi jeg af vane fandt den handling, jeg havde brug for, og tilføjede den til arbejdsgangen. Men det viste sig, at sonar ikke understøtter at arbejde gennem en aktion til analyse af projekter på Maven eller Gradle. Det står selvfølgelig i dokumentationen, men hvem læser det?!
Det er ikke muligt gennem en handling, så vi gør det gennem 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 fås på og du skal registrere det i hemmeligheder. GITHUB_TOKEN - dette er et indbygget token, som GitHub genererer, ved hjælp af hvilket sonarcloud[bot] vil være i stand til at logge ind på Git for at efterlade os beskeder i pull-anmodninger.
Dsonar.projectKey — navnet på projektet i ekkoloddet, du kan se det i projektindstillingerne.
Dsonar.organisation — navnet på organisationen fra GitHub.
Vi laver en pull-anmodning og venter på, at sonarcloud[bot] kommer i kommentarerne:
Frigivelse management
Bygningen er blevet konfigureret, testene er blevet kørt, og vi kan lave en udgivelse. Lad os se på, hvordan GitHub Actions kan gøre udgivelseshåndtering meget nemmere.
På arbejdet har jeg projekter, hvis kodebase er i bitbucket (alt er som i den historie "Jeg skriver til bitbucket om dagen, forpligter mig til GitHub om natten"). Desværre har bitbucket ikke indbyggede værktøjer til håndtering af udgivelser. Dette er et problem, fordi du for hver udgivelse manuelt skal oprette en side i sammenløb og smide alle de funktioner, der er inkluderet i udgivelsen der, søge gennem sindets paladser, opgaver i jira, commits i depotet. Der er mange chancer for at lave en fejl, du kan glemme noget eller indtaste noget, der allerede blev udgivet sidste gang, nogle gange er det simpelthen ikke klart, hvad en pull-anmodning skal klassificeres som - er det en funktion eller en fejlrettelse, eller redigeringstests, eller noget infrastrukturelt.
Hvordan kan GitHub-handlinger hjælpe os? Der er en fantastisk handling - release drafter, det giver dig mulighed for at indstille en release notes fil skabelon til at opsætte kategorier af pull anmodninger og automatisk gruppere dem i release notes filen:
Eksempelskabelon til opsætning af en rapport (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' New Features'
labels:
- 'type:features'
# в эту категорию собираем все PR с меткой type:features
- title: ' Bugs Fixes'
labels:
- 'type:fix'
# аналогично для метки type:fix и т.д.
- title: ' Documentation'
labels:
- 'type:documentation'
- title: ' Configuration'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Changes
$CHANGES
Tilføj et script for at generere en kladdeudgivelse (.github/workflows/release-draft.yml):
name: "Create draft release"
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-anmodninger fra nu af vil automatisk blive samlet i release notes - magi!
Her kan spørgsmålet opstå: hvad hvis udviklerne glemmer at sætte tags i PR'en? Så er det ikke klart, hvilken kategori den skal placeres i, og igen skal du håndtere det manuelt, med hver PR for sig. For at løse dette problem kan vi bruge en anden handling - labelverifier - den tjekker for tilstedeværelsen af tags på pull-anmodningen. Hvis der ikke er nogen påkrævede tags, vil kontrollen blive mislykket, og vi vil se en besked om dette i vores pull-anmodning.
name: "Verify 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 skal enhver pull-request markeres med et af tags: type:fix, type:features, type:documentation, type:tests, type:config.
Automatisk annotering af pull-anmodninger
Da vi berørte et sådant emne som effektivt arbejde med pull-anmodninger, er det værd at tale om sådan en handling som labeler, den sætter tags i PR baseret på hvilke filer der er blevet ændret. For eksempel kan vi markere som [build] enhver pull-anmodning, der indeholder ændringer til mappen .github/workflow.
Tilslutningen er ret enkel:
name: "Auto-assign themes to PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Vi har også brug for en fil, der beskriver korrespondancen mellem projektmapperne og pull request-emnerne:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Det lykkedes mig ikke at parre handlingen, der automatisk placerer etiketter i pull-anmodninger, med handlingen, der kontrollerer tilstedeværelsen af påkrævede etiketter; match-label ønsker ikke at se etiketterne tilføjet af botten. Det virker lettere at skrive din egen handling, der kombinerer begge stadier. Men selv i denne form er det ret praktisk at bruge; du skal vælge en etiket fra listen, når du opretter en pull-anmodning.
Det er tid til at implementere
Jeg prøvede flere implementeringsmuligheder via GitHub Actions (via ssh, via scp og ved hjælp af docker-hub), og jeg kan sige, at du højst sandsynligt vil finde en måde at uploade det binære til serveren, uanset hvor skæv din pipeline er. er.
Jeg kunne godt lide muligheden for at holde hele infrastrukturen på ét sted, så lad os se på, hvordan man implementerer til GitHub-pakker (dette er et lager for binært indhold, npm, jar, docker).
Script til at bygge et docker-billede og udgive det i GitHub-pakker:
name: Deploy docker image
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# Build JAR:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean compile package -DskipTests
# Set global environment variables:
- name: set global env
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#*/}"
# Build Docker image:
- name: Build and tag image
run: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- name: Docker login
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publish image to github package repository:
- name: Publish image
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Først skal vi bygge JAR-filen til vores applikation, hvorefter vi beregner stien til GitHub docker-registret og navnet på vores billede. Der er et par tricks her, som vi ikke er stødt på endnu:
- en konstruktion som: echo “::set-output navn=NAVN::VÆRDI” giver dig mulighed for at indstille værdien af en variabel i det aktuelle trin, så den derefter kan læses i alle andre trin.
- du kan få værdien af variablen sat i det foregående trin gennem identifikatoren for dette trin: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standardvariablen GITHUB_REPOSITORY gemmer navnet på depotet og dets ejer ("ejer/repo-navn"). For at klippe alt fra denne linje undtagen navnet på depotet, bruger vi bash-syntaks: ${GITHUB_REPOSITORY#*/}
Dernæst skal vi bygge docker-billedet:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Log ind i registreringsdatabasen:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Og udgiv billedet til GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
For at indikere versionen af billedet, bruger vi de første cifre fra SHA-hashen af forpligtelsen - GITHUB_SHA er der også nuancer her, hvis du laver sådanne builds ikke kun ved fletning til master, men også i henhold til oprettelsen af pull-anmodningen begivenhed, så matcher SHA muligvis ikke den hash, som vi ser i git-historikken, fordi handlingen/udbetalingshandlingen laver sin egen unikke hash for at undgå deadlocking-handlinger i PR.
Hvis alt fungerede godt, så åbner du pakkeafsnittet (https://github.com/antkorwin/github-actions/packages) i lageret, vil du se et nyt docker-billede:
Der kan du også se en liste over versioner af docker-billedet.
Det eneste, der er tilbage, er at konfigurere vores server til at arbejde med dette register og genstarte tjenesten. Jeg skal nok tale om hvordan man gør dette gennem systemd en anden gang.
overvågning
Lad os se på en simpel mulighed for, hvordan man laver et sundhedstjek for vores applikation ved hjælp af GitHub Actions. Vores boot-applikation har en aktuator, så vi behøver ikke engang at skrive en API for at kontrollere dens status; vi har allerede gjort alt for de dovne. Du skal bare trække værten: 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"}
Alt vi behøver er at skrive en opgave for at tjekke serveren ved hjælp af cron, og hvis den pludselig ikke svarer os, så sender vi en meddelelse via telegram.
Lad os først finde ud af, hvordan man kører et cron-workflow:
on:
schedule:
- cron: '*/5 * * * *'
Det er enkelt, jeg kan slet ikke tro på, at du i Github kan oprette begivenheder, der slet ikke passer ind i webhooks. Detaljer findes i dokumentationen:
Lad os kontrollere serverstatus manuelt 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 failed"
exit 1
fi
echo "It's OK"
Først gemmer vi i en variabel, hvad serveren svarede på anmodningen, i næste trin tjekker vi, at status er OP, og hvis dette ikke er tilfældet, afslutter vi med en fejl. Hvis du har brug for at "overvælde" en handling med dine hænder, så Afslut 1 - passende våben.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check of the:
${{secrets.SERVER_HOST}}/api/actuator/health
failed with the result:
${{ steps.ping.outputs.status }}
Vi sender kun til telegram, hvis handlingen mislykkedes i det foregående trin. For at sende en besked bruger vi appleboy/telegram-action; du kan læse om, hvordan du får et bot-token og chat-id i dokumentationen:
Glem ikke at skrive i hemmelighederne på Github: URL til serveren og tokens til telegrambot.
Bonustrack - JIRA for de dovne
Jeg lovede, at vi ville vende tilbage til JIRA, og vi er vendt tilbage. Hundredvis af gange har jeg observeret en situation ved stand-ups, når udviklere lavede en funktion, fusionerede en filial, men glemte at trække problemet ind i JIRA. Selvfølgelig, hvis alt dette blev gjort på ét sted, ville det være lettere, men faktisk skriver vi kode i IDE, flette grene ind i bitbucket eller GitHub og trækker derefter opgaverne ind i Jira, for dette skal vi åbne nye vinduer , nogle gange logge ind igen og osv. Når du helt husker, hvad du skal gøre næste gang, så nytter det ikke noget at åbne brættet igen. Som et resultat skal du om morgenen ved en standup bruge tid på at opdatere opgavetavlen.
GitHub vil også hjælpe os med denne rutineopgave; For det første kan vi trække problemer automatisk ind i kode_review-kolonnen, når vi sender en pull-anmodning. Alt du skal gøre er at følge grennavnekonventionen:
[имя проекта]-[номер таска]-название
for eksempel, hvis projektnøglen "GitHub Actions" er GA, så GA-8-jira-bot kunne være en gren til implementering af GA-8 opgaven.
Integration med JIRA fungerer gennem handlinger fra Atlassian, de er ikke perfekte, jeg må sige, at nogle af dem slet ikke virkede for mig. Men vi vil kun diskutere dem, der helt sikkert fungerer og bruges aktivt.
Først skal du logge ind på JIRA ved hjælp af handlingen: 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 }}
For at gøre dette skal du have et token i JIRA, hvordan du gør dette er beskrevet her:
Vi udtrækker opgave-id'et fra filialnavnet:
- 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 brach 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 "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
Hvis du søger på GitHub markedspladsen, kan du finde en handling til denne opgave, men jeg var nødt til at skrive det samme ved at bruge grep ved at bruge navnet på grenen, fordi denne handling fra Atlassian ikke ønskede at arbejde på mit projekt på nogen måde , for at finde ud af, hvad der var galt der - længere tid end at gøre det samme med hænderne.
Det eneste, der er tilbage, er at flytte opgaven til kolonnen "Kodegennemgang", når du opretter en pull-anmodning:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Der er en speciel handling for dette på GitHub, alt hvad den behøver er problem-id'et opnået i det forrige trin og godkendelsen i JIRA, som vi gjorde ovenfor.
På samme måde kan du trække opgaver, når du flettes ind i masteren, og andre begivenheder fra GitHub-arbejdsgangen. Generelt afhænger det hele af din fantasi og lyst til at automatisere rutineprocesser.
Fund
Hvis du ser på det klassiske DEVOPS-diagram, har vi dækket alle stadier, undtagen måske drift, jeg tror, at hvis du prøver, kan du finde noget action på markedet for integration med help-desk-systemet, så vi vil antage, at pipelinen vendte ud til at være grundig, og der kan drages konklusioner baseret på brugen.
Teknikere:
- Markedsplads med færdige handlinger til alle lejligheder, det her er meget fedt. I de fleste af dem kan du også se på kildekoden for at forstå, hvordan du løser et lignende problem eller sende en funktionsanmodning til forfatteren direkte i GitHub-lageret.
- Valg af målplatform til montering: Linux, mac os, windows er en ganske interessant funktion.
- Github-pakker er en fantastisk ting, det er praktisk at holde hele infrastrukturen på ét sted, du behøver ikke at surfe gennem forskellige vinduer, alt er inden for en radius af et eller to museklik og er perfekt integreret med GitHub Actions. Docker registry support i den gratis version er også en god fordel.
- GitHub skjuler hemmeligheder i byggelogfiler, så det er ikke så skræmmende at bruge det til at gemme adgangskoder og tokens. Under alle mine eksperimenter var jeg aldrig i stand til at se hemmeligheden i sin rene form i konsollen.
- Gratis til Open Source-projekter
Ulemper:
- YML, ja, jeg kan ikke lide ham. Når man arbejder med sådan et flow, er den mest almindelige commit besked jeg har "fix yml format", så glemmer man at sætte en fane et sted, eller man skriver den på den forkerte linje. Generelt er det ikke den mest behagelige oplevelse at sidde foran en skærm med vinkelmåler og lineal.
- DEBUG, fejlretning af flowet med commits, kørsel af en genopbygning og output til konsollen er ikke altid praktisk, men det er mere i kategorien "du er overdrevet"; du er vant til at arbejde med praktisk IDEA, når du kan fejlsøge hvad som helst .
- Du kan skrive din handling på hvad som helst, hvis du pakker den ind i Docker, men kun javascript er naturligt understøttet, selvfølgelig er dette en smagssag, men jeg ville foretrække noget andet i stedet for js.
Lad mig minde dig om, at depotet med alle scripts er her:
I næste uge optræder jeg med ved Heisenbug 2020 Piter-konferencen. Jeg fortæller dig ikke kun, hvordan du undgår fejl, når du forbereder testdata, men deler også mine hemmeligheder ved at arbejde med datasæt i Java-applikationer!
Kilde: www.habr.com