Často musím vytvárať pipeline pre zostavenie projektov v Jave. Niekedy sú to open-source projekty, niekedy nie. Nedávno som sa rozhodol preniesť niektoré svoje repozitáre z Travis-CI a TeamCity na GitHub Actions a toto je výsledok.
Čo budeme automatizovať
Na začiatok potrebujeme projekt, ktorý budeme automatizovať, poďme si vytvoriť jednoduchú aplikáciu na Spring boot / Java 11 / Maven. V rámci tohto článku nás logika aplikácie vôbec nezaujíma, dôležitá je infraštruktúra okolo aplikácie, takže nám stačí jednoduchý REST API kontrolér.
Zdrojové kódy si môžete pozrieť tu: všetky etapy budovania pipelinu sú zaznamenané v pull requestoch tohto projektu.
JIRA a plánovanie
Je potrebné povedať, že zvyčajne používame JIRA ako tracker úloh, takže si vytvoríme samostatnú nástenku pre tento projekt a pridáme tam prvé úlohy:
Neskôr sa ešte vrátime k tomu, čo zaujímavého môžu dať spoločne JIRA a GitHub.
Automatizujeme zostavenie projektu
Náš testovací projekt sa zostavuje cez maven, takže jeho zostavenie je pomerne jednoduché, všetko, čo potrebujeme, je mvn clean package.
Aby sme to urobili pomocou GitHub Actions, musíme v repozitári vytvoriť súbor s popisom našich workflow, to sa dá urobiť bežným yml súborom, nemôžem povedať, že sa mi páči „programovanie v yml“, ale čo sa dá robiť - vytvoríme v adresári .github/workflow/ súbor build.yml, v ktorom budeme opisovať akcie pri zostavení master vetvy:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: nastaviť JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean package -DskipTests
on — toto je popis udalosti, na základe ktorej sa spustí náš skript.
on: pull_request / push — hovorí, že tento workflow sa má spúšťať pri každom push na master a vytváraní pull requestov.
Ďalej nasleduje popis úloh (jobs) a kroky vykonania (steps) pre každú úlohu.
runs-on — tu si môžeme vybrať cieľový operačný systém, na prekvapenie sa dá zvoliť aj Mac OS, ale pri súkromných repozitároch je to dosť drahá záležitosť (v porovnaní s linuxom).
uses umožňuje znovu použiť iné akcie, takže napríklad pomocou akcie actions/setup-java inštalujeme prostredie pre Java 11.
Pomocou s môžeme určiť parametre, s ktorými spúšťame akciu, v podstate sú to argumenty, ktoré budú prenášané do akcie.
Len treba spustiť maven zostavenie projektu: run: mvn -B clean package prapor -B hovorí, že potrebujeme non-interactive mode, aby sa maven náhodou neopýtal na niečo.
Výborne! Teraz sa pri každom commite do mainu spúšťa zostavenie projektu.
Automatizujeme spúšťanie testov
Zostavenie je dobré, ale v skutočnosti projekt môže byť úspešne zostavený, ale nemusí fungovať. Preto je ďalším krokom automatizácia behu testov. Navyše je veľmi praktické vidieť výsledky behu testov, keď robíš revíziu PR — presne vieš, že testy prechádzajú a nikto nezabudol, predtým než sa vykoná merge, prebehnúť svoju vetvu.
Spúšťame testy pri vytvorení pull-requestu a merge do mainu, a súčasne pridáme zostavovanie správy o code-coverage.
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'main'
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 }}
Na pokrytie testov používam codecov v kombinácii s jacoco pluginom. U codecov existuje svoj vlastný akčný príkaz, ale pre prácu s naším pull-requestom potrebujeme token:
${{ secrets.CODECOV_TOKEN }} — takúto konštrukciu sa stretneme ešte nie raz, secrets je mechanizmus na uchovávanie tajomstiev na GitHub-e, môžeme tam zapisovať heslá/tokeny/hosty/url a iné údaje, ktoré by nemali byť zverejnené v kódovej báze repozitára.
Pridať premennú do secrets, môžete v nastaveniach repozitára na GitHub-e:
Získať token môžete na po autorizácii cez GitHub, na pridanie verejného projektu stačí prejsť na linku typu: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Pridávame jacoco plugin do POM súboru:
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
Teraz sa do každého nášho pull requestu pripojí bot codecov a pridá graf zmien pokrytia:
Pridáme statický analyzátor
Vo väčšine svojich open source projektov používam SonarCloud na statickú analýzu kódu, je dosť jednoduché ho pripojiť k Travis CI. Takže je to logický krok pri migrácii na GitHub Actions, urobiť to isté. Market akcií je skvelá vec, ale tentoraz ma trochu sklamal, pretože som si zvyku našiel potrebnú akciu a napísal ju do workflow. A ukázalo sa, že Sonar nepodporuje funkciu cez akciu na analýzu projektov na Maven alebo Gradle. O tom je samozrejme napísané v dokumentácii, ale kto si ju číta?!
Cez akciu to nejde, takže to budeme robiť cez Maven 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: Nastaviť JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyzovať pomocou SonarCloud
# nastavte premenné prostredia:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# spustite 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 — možno získať na a treba ho uviesť v secrets. GITHUB_TOKEN — to je zabudovaný token, ktorý generuje GitHub, pomocou neho sonarcloud[bot] sa bude môcť autentifikovať v Gite, aby nám mohol zanechávať správy v pull requestoch.
Dsonar.projectKey — názov projektu v Sonare, pozrieť si ho môžete v nastaveniach projektu.
Dsonar.organization — názov organizácie z GitHubu.
Vytvárame pull request a čakáme, kým sonarcloud[bot] príde s komentárom:
Správa o vydaní
Build sme nastavili, testy behali, môžeme spraviť aj release. Pozrime sa, ako GitHub Actions môže zásadne zjednodušiť správu vydaní.
V práci mám projekty, ktorých kódová základňa je na bitbucket (všetko ako v tom príbehu „cez deň píšem do bitbucket, v noci commitujem do GitHub“). Bohužiaľ, v bitbucket nie sú žiadne vstavané nástroje na správu vydaní. To je problém, pretože pre každé vydanie musím ručne vytvoriť stránku v confluence a nahrať tam všetky funkcie zahrnuté vo vydaní, prehľadávať brány rozumu, úlohy v jira, commity v repozitári. Existuje veľa možností na chybu, niečo môžem zabudnúť alebo zapísať to, čo už bolo vydané minule, niekedy je jednoducho nejasné, do akej kategórie patrí nejaký pull-request — je to funkcia, alebo oprava chýb, alebo úprava testov, alebo niečo infraštruktúrne.
Ako nám môže pomôcť GitHub actions? Existuje vynikajúca akcia — release drafter, ktorá umožňuje nastaviť šablónu súboru release notes, aby sme kategorizovali pull-requesty a automaticky ich zoskupovali do súboru release notes:
Príklad šablóny na nastavenie správy (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Nové funkcie'
labels:
- 'type:features'
# do tejto kategórie zberáme všetky PR s označením type:features
- title: ' Opravy chýb'
labels:
- 'type:fix'
# analogicky pre označenie type:fix atď.
- title: ' Dokumentácia'
labels:
- 'type:documentation'
- title: ' Konfigurácia'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Zmeny
$CHANGES
Pridávame skript na generovanie konceptu vydania (.github/workflows/release-draft.yml):
name: "Vytvoriť koncept vydania"
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 }}
Všetky pull-requesty od tohto momentu budú automaticky zhromažďované do release notes — mágia!
Tu môže nastať otázka: a čo ak vývojári zabudnú priradiť označenia k PR? Potom nie je jasné, do akej kategórie ho zaradiť a opäť sa bude musieť riešiť ručne, s každým PR osobitne. Aby sme tento problém vyriešili, môžeme využiť ďalšiu akciu — label verifier — ktorý kontroluje prítomnosť štítkov na pull-requeste. Ak nie je prítomný ani jeden povinný štítok, kontrola zlyhá a túto informáciu uvidíme v našom pull-requeste.
name: "Overiť typové štítky"
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'
Teraz musí byť každý pull-request označený jedným z štítkov: type:fix, type:features, type:documentation, type:tests, type:config.
Automatické anotovanie pull requestov
Keďže sme sa dotkli témy efektívnej práce s pull requestami, mali by sme spomenúť aj akciu zvanú labeler, ktorá priraďuje štítky k PR na základe toho, aké súbory boli zmenené. Napríklad môžeme označiť ako [build] akýkoľvek pull request, v ktorom sú zmeny v adresári .github/workflow.
Jeho pripojenie je pomerne jednoduché:
name: "Automaticky priraďovať témy k PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Ešte potrebujeme súbor s popisom zodpovedajúcej štruktúry projektu a tém pull requestov:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nepodarilo sa mi spojiť akciu automatického priraďovania štítkov k pull requestom s akciou, ktorá kontroluje prítomnosť povinných štítkov; match-label nechce vedieť o štítkoch pridaných botom. Zdá sa, že bude jednoduchšie napísať vlastnú akciu, ktorá kombinuje oba kroky. Ale aj v tejto podobe je používanie celkom pohodlné, pri vytváraní pull requestu stačí vybrať štítok zo zoznamu.
Je čas na nasadenie
Skúsil som niekoľko variantov nasadenia cez GitHub Actions (cez ssh, cez scp a pomocou docker-hub) a môžem povedať, že pravdepodobne nájdete spôsob, ako nahrať binárku na server, akýkoľvek prekrútený bol váš pipeline.
Páčil sa mi variant udržať celú infraštruktúru na jednom mieste, a tak sa pozrime, ako urobiť nasadenie do GitHub Packages (to je úložisko pre binárny obsah, npm, jar, docker).
Skript na zostavenie docker obrazu a jeho publikovanie v GitHub Packages:
názov: Nasadiť docker obraz
na:
push:
vetvy:
- 'master'
úlohy:
build_docker_image:
beží na: ubuntu-18.04
kroky:
# Zostaviť JAR:
- používa: actions/checkout@v1
- názov: nastaviť JDK 11
používa: actions/setup-java@v1
s:
java-verzia: 1.11
- názov: Maven Balík
spustiť: mvn -B clean compile package -DskipTests
# Nastaviť globálne premenné prostredia:
- názov: nastaviť globálne env
id: global_env
spustiť: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com\/${GITHUB_REPOSITORY}\/${GITHUB_REPOSITORY#*\/}"
# Zostaviť Docker obraz:
- názov: Zostaviť a označiť obraz
spustiť: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- názov: Docker prihlásenie
spustiť: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publikovať obraz do github package repository:
- názov: Publikovať obraz
env:
IMAGE_NAME: $GITHUB_REPOSITORY
spustiť: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Na začiatku musíme zostaviť JAR súbor našej aplikácie, po čom vypočítame cestu k GitHub docker registry a názov nášho obrazu. Sú tu niektoré finty, s ktorými sme sa ešte nestretli:
- konštrukcia vo forme: echo «::set-output name=NAME::VALUE» umožňuje nastaviť hodnotu premennej v aktuálnom kroku tak, aby sa dala neskôr prečítať vo všetkých ostatných krokoch.
- Získať hodnotu premennej nastavené v predchádzajúcom kroku môžeme cez identifikátor tohto kroku: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- V štandardnej premennej GITHUB_REPOSITORY sa nachádza názov repozitára a jeho vlastník ("owner/repo-name"). Aby sme z tohto reťazca vytiahli iba názov repozitára, použijeme bash syntaktiku: ${GITHUB_REPOSITORY#*\/}
Ďalej potrebujeme zostaviť docker obraz:
docker build -t "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions:latest"
Prihlásiť sa do registry:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
A publikovať obraz v GitHub Packages Repository:
docker push "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions"
Aby sme určili verziu obrazu, používame prvé číslice z SHA hash kódu commitu — GITHUB_SHA má tu tiež svoje nuansy, ak sa chystáte robiť takéto zostavy nielen pri spojení do master, ale aj pri udalosti vytvorenia pull requestu, SHA sa nemusí zhodovať s hashom, ktorý vidíme v histórii gitu, pretože akcia actions/checkout vytvára svoj unikátne hash na vyhnutie sa vzájomnému blokovaniu akcií v PR.
Ak všetko prebehlo úspešne, otvorením sekcie packages (https://github.com/antkorwin/github-actions/packages) v repozitári uvidíte nový docker obraz:
Tam môžete tiež zobraziť zoznam verzií docker imidžu.
Zostáva len nastaviť našu server na prácu s týmto registriom a spustiť reštart služby. Ako to urobiť pomocou systemd, o tom sa zmienim inokedy.
Monitorovanie
Poďme sa pozrieť na jednoduchý spôsob, ako vykonať health check našej aplikácie pomocou GitHub Actions. V našej základnej aplikácii je actuator, takže API na kontrolu jej stavu nemusíme ani písať, pre lenivých už je všetko hotové. Stačí len zavolať host: 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"}
Všetko, čo potrebujeme — napísať úlohu na kontrolu servera prostredníctvom cronu, a ak náhodou neodpovie, pošleme oznámenie na Telegram.
Na začiatok si objasníme, ako spustiť workflow pomocou cronu:
on:
schedule:
- cron: '*/5 * * * *'
Je to jednoduché, ani by sa tomu neverilo, že v GitHub-e možno vytvoriť takéto udalosti, ktoré sa vôbec nezapadajú do webhook-ov. Podrobnosti sú v dokumentácii:
Kontrolu stavu servera vykonáme ručne pomocou 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"
Najprv uložíme do premennej to, čo server odpovedal na požiadavku, v ďalšom kroku skontrolujeme, že status je UP, a ak to tak nie je, tak vystúpime s chybou. Ak potrebujeme ručne „zhodiť“ akciu, tak exit 1 — vhodná zbraň.
- 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 }}
Odoslanie na Telegram robíme len v prípade, že akcia zlyhala v predchádzajúcom kroku. Na odoslanie správy používame appleboy/telegram-action, o tom, ako získať token bota a ID chatu, si môžete prečítať v dokumentácii:
Nezabudnite zapísať do tajomstiev na GitHub-e: URL pre server a tokeny pre Telegram bota.
Bonus track — JIRA pre lenivých
Sľúbil som, že sa vrátime k JIRA a vrátili sme sa. Stokrát som na standupe sledoval situáciu, keď vývojári spravili funkciu, zliali vetvu, ale zabudli presunúť úlohu do JIRA. Samozrejme, keby sa to všetko robilo na jednom mieste, bolo by to jednoduchšie, ale v skutočnosti píšeme kód v IDE, zlývame vetvy do Bitbucketu alebo GitHubu a úlohy potom presúvame do JIRA, na to musíme otvárať nové okná, niekedy sa znova prihlasovať atď. Keď si dokonale pamätáš, čo treba robiť ďalej, otvárať board sa neoplatí. Výsledkom je, že ráno na standupe musíme strácať čas na aktualizáciu boardu úloh.
GitHub nám pomôže aj pri tejto rutine, na začiatok môžeme presúvať úlohy automaticky do kolónky code_review, keď sme odoslali pull request. Všetko, čo potrebujeme, je dodržiavať dohodu o pomenovaní vetiev:
[názov projektu]-[číslo úlohy]-názov
napríklad, ak je kľúč projektu „GitHub Actions“ GA, tak GA-8-jira-bot môže byť vetvou na realizáciu úlohy GA-8.
Integrácia s JIRA funguje cez akcie od Atlassian, nie sú ideálne, musím povedať, že niektoré z nich mi vôbec nefungovali. Ale budeme sa zaoberať len tými, ktoré určite fungujú a sú aktívne používané.
Na začiatok je potrebné prejsť autentifikáciou v JIRA pomocou akcie: 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 }}
Na to je potrebné získať token v JIRA, ako to spraviť, je popísané tu:
Vytiahujeme identifikátor úlohy z názvu vetvy:
- 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 "Prosím, pomenúvajte svoju vetvu podľa úlohy JIRA: [project_key]-[task_number]-branch_name"
exit 1
fi
echo úspešne nájdeme JIRA úlohu: ${{steps.find_issue.outputs.ISSUE_ID}}
Ak hľadáš na GitHub marketplace, môžeš nájsť akciu na túto úlohu, ale musel som napísať to isté cez grep podľa názvu vetvy, pretože táto akcia od Atlassian nechcela fungovať na mojom projekte, zistiť, čo je tam zlé, trvá dlhšie, ako urobiť to ručne.
Stačí presunúť úlohu do stĺpca „Code review“ pri vytváraní pull requestu:
- name: Prechod úlohy
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Na to existuje špeciálne akcia na GitHub, všetko, čo potrebuje — to je identifikátor úlohy, získaný v predchádzajúcom kroku, a autorizácia v JIRA, ktorú sme nastavovali vyššie.
Podobne je možné premietať úlohy pri merge do masteru a pri iných udalostiach z GitHub workflow. V podstate, všetko závisí od vašej fantázie a túžby automatizovať rutinné procesy.
Zhrnutie
Ak sa pozrieme na klasickú diagram DEVOPS, pokryli sme všetky fázy, okrem operate, myslím, že ak sa snažíme, môžeme nájsť nejakú akciu na trhu pre integráciu so help-desk systémom, takže môžeme považovať pipeline za kvalitný a na jeho základe môžeme spraviť závery.
Výhody:
- Marketplace s hotovými akciami na každú situáciu, to je naozaj skvelé. Vo väčšine z nich je možné aj nahliadnuť do zdrojových kódov, aby ste pochopili, ako vyriešiť podobnú úlohu alebo priamo poslať feature request autorovi priamo v GitHub repozitári.
- Výber cieľovej platformy pre zostavenie: Linux, macOS, Windows je veľmi zaujímavá funkcia.
- GitHub Packages je skvelá vec, mať celú infraštruktúru na jednom mieste je pohodlné, netreba sa presúvať medzi rôznymi oknami, všetko je v dosahu jedného alebo dvoch kliknutí myšou a skvele integrované s GitHub Actions. Podpora docker registry v bezplatnej verzii — to je tiež dobrá výhoda.
- GitHub skrýva tajomstvá vo vybudovaných logoch, takže používať ho na uchovávanie hesiel a tokenov nie je také desivé. Počas všetkých experimentov sa mi ani raz nepodarilo vidieť tajomstvo v čistej podobe v konzole.
- Je bezplatné pre Open Source projekty
Nevýhody:
- YML, no nemám ho rád. Pri práci s takýmto tokom mám najčastejší commit message „fix yml format“, strácať sa v tabulátoroch, alebo písať na nesprávne riadky. V podstate, sedieť pred obrazovkou s transportérom a pravítkom nie je najpríjemnejšie zamestnanie.
- DEBUG, ladenie toku s commitmi, spustenie prekompilovania a výstup do konzoly nie je vždy pohodlné, ale to skôr patrí do kategórie „ste rozmaznaní“, ste zvyknutí pracovať s pohodlnými IDE, kde môžete ladiť čokoľvek.
- Vlastnú akciu možno napísať na čomkoľvek, ak to zabalíte do Dockeru, ale natívne je podporovaný iba JavaScript. Samozrejme, je to otázka vkusu, ale ja by som uprednostnil niečo iné namiesto js.
Pripomínam, že repozitár so všetkými skriptami je tu:
Na budúci týždeň budem vystupovať s na konferencii Heisenbug 2020 Piter. Povedzme si nielen o tom, ako sa vyhnúť chybám pri príprave testovacích údajov, ale aj o mojich tajomstvách práce s údajovými sadami v Java aplikáciách!
Zdroj: habr.com
