Adesea, trebuie să construiesc un pipeline pentru compilarea proiectelor în Java. Uneori este open-source, alteori nu. Recent, am decis să încerc să migrez o parte din repozitoarele mele de pe Travis-CI și TeamCity pe GitHub Actions, iar iată ce a ieșit.
Ce vom automatiza
Pentru început, avem nevoie de un proiect pe care să-l automatizăm, să facem o aplicație mică în Spring boot / Java 11 / Maven. În cadrul acestui articol, logica aplicației nu ne interesează deloc, ne interesează infrastructura din jurul aplicației, așa că ne va ajunge un simplu controler REST API.
Puteți vizualiza sursele aici: toate etapele construirii pipeline-ului sunt reflectate în pull request-urile acestui proiect.
JIRA și planificarea
Merită menționat că de obicei folosim JIRA ca tracker de sarcini, așa că să creăm un board separat pentru acest proiect și să adăugăm primele sarcini acolo:
Puțin mai târziu ne vom întoarce la ce informații interesante pot oferi JIRA și GitHub împreună.
Automatizăm compilarea proiectului
Proiectul nostru de testare se compilează prin maven, așa că compilarea acestuia este destul de simplă, tot ce avem nevoie este mvn clean package.
Pentru a face acest lucru cu ajutorul Github Actions, va trebui să creăm un fișier în repozitoriu care să descrie workflow-ul nostru, acest lucru se poate face cu un fișier yml obișnuit, nu pot spune că îmi place „programarea în yml”, dar ce să facem — creăm în directorul .github/workflow/ un fișier build.yml în care vom descrie acțiunile la compilarea ramurii master:
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 — aceasta este descrierea evenimentului care va lansa scriptul nostru.
on: pull_request / push — indică faptul că acest workflow trebuie să fie activat la fiecare push în ramura master și la crearea de pull request-uri.
Apoi urmează descrierea sarcinilor (tasks) și pașii de execuție (steps) pentru fiecare sarcină.
runs-on — aici putem alege sistemul de operare țintă, surprinzător, putem alege chiar și Mac OS, dar în cazul repozitoriilor private, aceasta este o plăcere destul de costisitoare (comparativ cu linux).
uses permite reutilizarea altor acțiuni, astfel încât, de exemplu, cu ajutorul acțiunii actions/setup-java instalăm mediul pentru Java 11.
Cu ajutorul with Putem specifica parametrii cu care lansăm acțiunea; de fapt, acestea sunt argumentele care vor fi transmise la acțiune.
Trebuie doar să lansăm construcția proiectului cu Maven: run: mvn -B clean package steag -B Asta înseamnă că avem nevoie de modul non-interactiv, pentru a nu fi întrebați de Maven în mod neașteptat.
Excelent! Acum, de fiecare dată când se face un commit în master, se lansează construcția proiectului.
Automatizăm lansarea testelor.
Construcția este importantă, dar în realitate, proiectul poate să fie construit cu succes și să nu funcționeze. Așadar, pasul următor este să ne ocupăm de automatizarea rulării testelor. De asemenea, este foarte convenabil să vezi rezultatul testelor când faci revizuirea PR-ului – știi cu siguranță că testele au trecut și nimeni nu a uitat să ruleze ramura înainte de a face merge.
Facem rularea testelor la crearea unei cereri de extragere și pentru merge în master, și în plus, vom adăuga generarea unui raport despre acoperirea codului.
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 }}
Pentru acoperirea testelor, folosesc Codecov împreună cu pluginul Jacoco. Codecov are propria sa acțiune, dar are nevoie de un token pentru a lucra cu cererea noastră de extragere:
${{ secrets.CODECOV_TOKEN }} — o astfel de construcție o vom întâlni nu o dată, secrets este un mecanism pentru stocarea secretelor în GitHub, putem acolo să specificăm parole/token-uri/găzduiri/URL-uri și alte date pe care nu ar trebui să le expunem în codul bazei de date a repository-ului.
Adăugarea unei variabile la secrets se poate face în setările repository-ului pe GitHub:
Tokenul poate fi obținut de pe după autorizarea prin GitHub, pentru a adăuga un proiect public, trebuie doar să accesezi un link de forma: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Adăugăm pluginul Jacoco în fișierul POM:
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
Acum, botul codecov va intra în fiecare pull request și va adăuga un grafic al modificărilor acoperirii:
Vom adăuga un analfizor static
În majoritatea proiectelor mele open source folosesc sonar cloud pentru analiza statică a codului, este destul de ușor de conectat la travis-ci. Așa că, este un pas logic în migrarea pe GitHub Actions, să facem același lucru. Marketplace-ul acțiunilor - este o chestie mișto, dar de această dată m-a cam lăsat pe gânduri, deoarece din obișnuință am găsit acțiunea dorită și am scris-o în workflow. Și s-a dovedit că sonar nu suportă analiza proiectelor maven sau gradle printr-o acțiune. Desigur, este scris în documentație, dar cine o citește?!
Prin acțiune nu se poate, așa că vom face prin plugin mvn:
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 — poate fi obținut în și trebuie să fie definit în secrets. GITHUB_TOKEN — este un token încorporat, generat de GitHub, cu ajutorul căruia sonarcloud[bot] se va putea autentifica în git pentru a ne lăsa mesaje în pull request-uri.
Dsonar.projectKey — este numele proiectului în sonar, poate fi găsit în setările proiectului.
Dsonar.organization — este numele organizației din GitHub.
Facem un pull request și așteptăm ca sonarcloud[bot] să vină cu comentarii:
Managementul versiunilor
Am configurat build-ul, am rulat testele, acum putem face un release. Să vedem cum GitHub Actions ajută semnificativ la simplificarea managementului release.
La locul de muncă am proiecte, codul sursă al căror este în Bitbucket (totul ca în povestea „în timpul zilei scriu în Bitbucket, noaptea comit în GitHub”). Din păcate, Bitbucket nu are instrumente integrate pentru gestionarea versiunilor. Aceasta este o problemă, deoarece pentru fiecare versiune trebuie să creez manual o pagină în Confluence și să adaug acolo toate caracteristicile incluse în versiune, să verific notițele minții, sarcinile în Jira, comit-urile în depozit. Există multe șanse de a greși, se poate uita ceva sau se poate scrie ceea ce deja a fost lansat anterior, uneori pur și simplu nu este clar cum să clasifici o anumită cerere de pull — este o caracteristică sau o corectare a defecțiunilor, sau o ajustare a testelor, sau ceva infrastructural.
Cum ne poate ajuta GitHub Actions? Există o acțiune excelentă — Release Drafter, care permite să definești un șablon pentru fișierul de note de lansare, pentru a configura categoriile cererilor de pull și a le grupa automat în fișierul de note de lansare:
Exemplu de șablon pentru configurarea raportului (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: 'Caracteristici noi'
labels:
- 'type:features'
# în această categorie adunăm toate PR-urile cu eticheta type:features
- title: 'Corectări de erori'
labels:
- 'type:fix'
# similar pentru eticheta type:fix etc.
- title: 'Documentație'
labels:
- 'type:documentation'
- title: 'Configurare'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Modificări
$CHANGES
Adăugăm un script pentru generarea schiței de lansare (.github/workflows/release-draft.yml):
name: "Creează schița de lansare"
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 }}
Toate cererile de pull de acum înainte vor fi adunate automat în notele de lansare — magie!
Aici poate apărea întrebarea: ce se întâmplă dacă dezvoltatorii uită să adauge etichetele la PR? Atunci nu va fi clar în ce categorie să-l clasifici, iar din nou va trebui să te ocupi manual cu fiecare PR în parte. Pentru a rezolva această problemă, putem utiliza o altă acțiune — Label Verifier — care verifică prezența etichetelor pe cererea de pull. Dacă nu există nicio etichetă obligatorie, atunci verificarea va fi eșuată și vom vedea un mesaj în cererea noastră de pull.
name: "Verifică etichetele de tip"
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'
Acum, fiecare cerere de pull trebuie marcată cu una dintre etichete: type:fix, type:features, type:documentation, type:tests, type:config.
Auto-anotarea cererilor de extragere
Deoarece am atins subiectul unei lucrări eficiente cu cererile de extragere, ar trebui să menționăm și o acțiune numită labeler, care adaugă etichete în PR pe baza fișierelor modificate. De exemplu, putem eticheta ca [build] orice cerere de extragere care conține modificări în catalogul .github/workflow.
Integrating it is quite simple:
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 }}
De asemenea, ne va trebui un fișier cu descrierea corespondenței dintre directoarele proiectului și temele cererilor de extragere:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nu am reușit să combin acțiunea care adaugă automat etichete în cererile de extragere cu acțiunea care verifică prezența etichetelor obligatorii; match-label nu recunoaște etichetele adăugate de bot. Se pare că ar fi mai simplu să scrii propria acțiune care să îmbine ambele etape. Dar chiar și așa, este destul de convenabil să alegi o etichetă din listă atunci când creezi o cerere de extragere.
Este timpul să facem deploy
Am încercat câteva metode de deploy prin GitHub Actions (prin ssh, prin scp și folosind docker-hub) și pot spune că, foarte probabil, veți găsi o modalitate de a încărca binarul pe server, indiferent cât de complicat ar fi pipeline-ul vostru.
Mi-a plăcut ideea de a păstra toată infrastructura într-un loc, așa că haideți să vedem cum putem face deploy în GitHub Packages (acesta este un repository pentru conținut binar, npm, jar, docker).
Scriptul pentru construirea imaginii docker și publicarea acesteia în GitHub Packages:
nume: Implementare imagine docker
pe:
împinge:
ramuri:
- 'master'
locuri de muncă:
build_docker_image:
rulează-pe: ubuntu-18.04
pași:
# Construiește JAR:
- folosește: actions/checkout@v1
- nume: configurare JDK 11
folosește: actions/setup-java@v1
cu:
java-version: 1.11
- nume: Pachet Maven
rulează: mvn -B clean compile package -DskipTests
# Setează variabile de mediu globale:
- nume: setează env global
id: global_env
rulează: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*\/}"
# Construiește imaginea Docker:
- nume: Construiește și etichetează imaginea
rulează: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- nume: Autentificare Docker
rulează: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publică imaginea în depozitul de pachete GitHub:
- nume: Publică imaginea
env:
IMAGE_NAME: $GITHUB_REPOSITORY
rulează: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Pentru început, trebuie să construim fișierul JAR pentru aplicația noastră, după care calculăm calea către registrul Docker GitHub și numele imaginii noastre. Aici sunt câteva trucuri cu care nu ne-am mai confruntat până acum:
- structura de tip: echo «::set-output name=NAME::VALUE» permite setarea valorii unei variabile în pasul curent, astfel încât să poată fi citită în toate celelalte pași.
- pentru a obține valoarea variabilei setate în pasul anterior se poate folosi identificatorul acestui pas: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- În variabila standard GITHUB_REPOSITORY este stocat numele și proprietarul repository-ului („owner/repo-name”). Pentru a extrage din acest șir tot ce nu este numele repository-ului, vom folosi sintaxa bash: ${GITHUB_REPOSITORY#*\/}
Apoi, trebuie să construim imaginea Docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Autentificare în registru:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Și publicarea imaginii în GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Pentru a specifica versiunea imaginii, folosim primele cifre din hash-ul SHA al commit-ului — GITHUB_SHA are, de asemenea, nuanțe, dacă veți face astfel de construcții nu doar la îmbinarea în master, ci și la evenimentul de creare a unei cereri de extragere, atunci SHA poate să nu corespundă hash-ului pe care îl vedem în istoria gitului, deoarece acțiunea actions/checkout generează un hash unic pentru a evita blocajele reciproce ale acțiunilor în PR.
Dacă totul a funcționat corect, deschizând secțiunea pachete (https://github.com/antkorwin/github-actions/packages) în repository, veți vedea o nouă imagine Docker:
Aici puteți vizualiza lista versiunilor imaginii Docker.
Trebuie doar să configurăm serverul nostru pentru a lucra cu acest registry și să repornim serviciul. Cum să facem asta prin systemd, cred că voi explica într-o altă ocazie.
Monitorizare
Hai să vedem o variantă simplă de a face health check pentru aplicația noastră folosind GitHub Actions. În aplicația noastră de boot avem actuator, așa că nu trebuie să scriem un API pentru verificarea stării; pentru cei lenți, totul este deja pregătit. Trebuie doar să accesăm hostul: 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"}
Tot ce avem nevoie este să scriem o sarcină de verificare a serverului prin cron, iar dacă acesta nu răspunde, vom trimite o notificare pe Telegram.
Mai întâi, să vedem cum să activăm workflow-ul prin cron:
on:
schedule:
- cron: '*\/5 * * * *'
E simplu, nici nu credeam că în GitHub se pot crea astfel de evenimente, care nu se încadrează deloc în webhook-uri. Detalii sunt în documentație:
Vom verifica starea serverului manual, folosind 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"
Mai întâi, salvăm într-o variabilă ce a răspuns serverul la cerere, iar în următorul pas verificăm că statusul este UP și, dacă nu este așa, ieșim cu o eroare. Dacă trebuie să suspendăm manual acțiunea, atunci exit 1 — este arma potrivită.
- 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 }}
Trimiterea pe Telegram se face doar dacă acțiunea a eșuat în pasul anterior. Pentru a trimite mesajul, folosim appleboy\/telegram-action; despre cum să obținem tokenul botului și ID-ul chat-ului se poate citi în documentație:
Nu uitați să completați în secretele de pe GitHub: URL-ul pentru server și tokenurile pentru botul Telegram.
Bonus track — JIRA pentru cei lenți
Am promis că ne vom întoarce la JIRA și ne-am întors. De sute de ori am observat în stand-upuri situația în care dezvoltatorii au realizat o funcție, au îmbinat ramura, dar au uitat să mute sarcina în JIRA. Desigur, dacă totul s-ar face într-un singur loc, ar fi mai simplu, dar, de fapt, scriem cod în IDE, îmbinăm ramurile în Bitbucket sau GitHub, iar sarcinile le mutăm apoi în Jira, pentru asta trebuie să deschidem feronțele noi, uneori să ne conectăm din nou etc. Când îți amintești perfect ce trebuie să faci în continuare, nu are sens să deschizi tabloul de sarcini încă o dată. În cele din urmă, dimineața la stand-up trebuie să pierzi timp cu actualizarea tabloului de sarcini.
GitHub ne va ajuta și în această activitate de rutină, mai întâi putem muta sarcinile automat în coloana code_review când am trimis pull requestul. Tot ce trebuie să facem este să respectăm convenția în denumirea ramurilor:
[numele proiectului]-[numărul sarcinii]-titlu
de exemplu, dacă cheia proiectului „GitHub Actions” va fi GA, atunci GA-8-jira-bot poate fi ramura pentru implementarea sarcinii GA-8.
Integrarea cu JIRA funcționează prin acțiunile de la Atlassian, nu sunt ideale, trebuie spus că unele dintre ele nu mi-au funcționat deloc. Dar vom discuta doar acelea care funcționează sigur și sunt folosite activ.
Mai întâi trebuie să te autentifici în JIRA prin acțiunea: 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 }}
Pentru aceasta, trebuie să obții un token în JIRA, cum să faci asta este descris aici:
Extragem identificatorul sarcinii din denumirea ramurii:
- 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 numele ramurii: $GITHUB_HEAD_REF
echo problema extrasă: ${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 "Te rog să denumești ramura în conformitate cu sarcina JIRA: [project_key]-[task_number]-branch_name"
exit 1
fi
echo problema JIRA găsită cu succes: ${{steps.find_issue.outputs.ISSUE_ID}}
Dacă cauți în GitHub marketplace, poți găsi o acțiune pentru această sarcină, dar a trebuit să scriu același lucru prin grep după denumirea ramurii, pentru că această acțiune de la Atlassian nu a vrut să funcționeze în proiectul meu, și să înțeleg ce nu este în regulă a durat mai mult decât să fac manual același lucru.
Trebuie doar să mutați sarcina în coloana „Code review” atunci când creați un pull request:
- name: Tranziție problemă
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Pentru aceasta există o acțiune specială pe GitHub, tot ce are nevoie este identificatorul sarcinii obținut în pasul anterior și autentificarea în JIRA, pe care am realizat-o mai sus.
În același mod, puteți trasa sarcini în timpul merge-ului în master și în alte evenimente din fluxul de lucru GitHub. În general, totul depinde de imaginația și dorința dvs. de a automatiza procesele de rutină.
Conclusions
Dacă ne uităm la diagrama clasică DEVOPS, am acoperit toate etapele, cu excepția operate, cred că, dacă ne străduim, putem găsi o acțiune în market pentru integrarea cu sistemul de help-desk, așa că putem considera că pipeline-ul este solid și pe baza utilizării sale se pot trasa concluzii.
Pro:
- Marketplace-ul cu acțiuni gata făcute pentru toate situațiile este foarte interesant. În majoritatea lor, puteți vedea și sursele, pentru a înțelege cum să rezolvați o sarcină similară sau să postati o cerere de caracteristici autorului direct în repository-ul GitHub.
- Alegerea platformei țintă pentru construire: Linux, macOS, Windows este o caracteristică destul de interesantă.
- GitHub Packages este o idee excelentă, a păstra toată infrastructura într-un singur loc este confortabil, nu trebuie să navighezi prin diferite feronerie, totul în raza a unu-două clicuri și perfect integrat cu GitHub Actions. Suportul pentru docker registry în versiunea gratuită este de asemenea un avantaj bun.
- GitHub ascunde secretele în jurnalele de construire, așa că a le folosi pentru stocarea parolelor și token-urilor nu este chiar atât de înfricoșător. În întreaga mea experiență, nu am reușit să văd niciodată un secret în formă clară în consolă.
- Este gratuit pentru proiectele Open Source
Dezavantaje:
- YML, nu-mi place. Atunci când lucrez cu acest flux cel mai frecvent mesaj de commit este „fix yml format”, uneori uiți să pui un tab, uneori scrii pe linia greșită. În general, să stai în fața ecranului cu un transportor și o riglă nu este cea mai plăcută activitate.
- DEBUG, a depana fluxul cu commit-uri, pornind o reîncărcare și afișând în consolă nu este întotdeauna convenabil, dar este mai mult din categoria „v-ați răsfățat”, v-ați obișnuit să lucrați cu IDE-uri confortabile, când puteți depana orice.
- Îți poți scrie acțiunea pe orice, dacă o împachetezi în Docker, dar nativ este susținut doar JavaScript. Desigur, este o chestiune de preferință, dar aș alege ceva diferit în loc de JS.
Îți reamintesc că repository-ul cu toate scripturile este aici:
Săptămâna viitoare voi susține o prezentare la conferința Heisenbug 2020 Piter. Voi vorbi nu doar despre cum să eviți greșelile în pregătirea datelor de testare, ci și voi împărtăși secretele mele despre lucrul cu seturile de date în aplicațiile Java!
Sursa: habr.com
