Më ndodh shpesh të ndërtoj një pipeline për ndërtimin e projekteve në Java. Ndonjëherë janë open-source, ndonjëherë jo. Së fundmi, vendosa të provoj të transferoj disa nga depot e mia nga Travis-CI dhe TeamCity në GitHub Actions, dhe kjo është ajo që arrita.
Çfarë do të automatizojmë
Për të filluar, na nevojitet një projekt që do të automatizojmë, le të krijojmë një aplikacion të vogël në Spring Boot / Java 11 / Maven. Në këtë artikull, logjika e aplikacionit nuk na intereson fare, na intereson infrastruktura përreth aplikacionit, kështu që na mjafton një kontrollues i thjeshtë REST API.
Mund ta shihni kodin burimor këtu: të gjitha etapet e ndërtimit të pipeline-it janë pasqyruar në pull requests të këtij projekti.
JIRA dhe planifikimi
Duhet thënë se zakonisht përdorim JIRA si një ndjekës të detyrave, kështu që le të krijojmë një bord të veçantë për këtë projekt dhe të hedhim aty detyrat e para:
Pak më vonë do të kthehemi te ajo që mund të ofrojë në lidhje JIRA dhe GitHub.
Automatizojmë ndërtimin e projektit
Projekti ynë testues ndërttohet përmes maven, kështu që ndërtimi i tij është mjaft i thjeshtë, e gjithë çfarë na nevojitet është mvn clean package.
Për ta bërë këtë me ndihmën e GitHub Actions, na nevojitet të krijojmë në repository një skedë me përshkrimin e workflow-t tonë, kjo mund të bëhet me një skedë të zakonshme yml, nuk mund të them se më pëlqen «programimi në yml», por çfarë të bëjmë — krijojmë në direktorinë .github/workflow/ skedën build.yml në të cilën do të përshkruajmë veprimet gjatë ndërtimit të degës 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
në — kjo është përshkrimi i ngjarjes që do të aktivizojë skriptin tonë.
on: pull_request / push — tregon se ky workflow duhet të aktivizohet në çdo push në master dhe krijimin e pull requests.
Më pas shkon përshkrimi i detyrave (jobs) dhe hapat e ekzekutimit (steps) për secilën detyrë.
runs-on — këtu mund të zgjedhim sistemin operativ të destinacionit, me befasinë mund të zgjidhni edhe Mac OS, por në repository private, kjo është një kënaqësi mjaft e kushtueshme (në krahasim me linux).
uses lejon ri-përdorimin e veprimeve të tjera, kështu që, për shembull, me anë të veprimit actions/setup-java ne instalojmë ambientin për Java 11.
With the help of with Ne mund të përcaktojmë parametrat me të cilat aktivizojmë veprimin, në thelb, këto janë argumentet që do të kalohen në aksion.
Tani mbetet vetëm të përfundojmë ndërtimin e projektit me Maven: run: mvn -B clean package --all -B tregon që na nevojitet modu i mos-interaksionit, për të mos lejuar që Maven të kërkojë ndonjëherë diçka prej nesh
Fantastike! Tani, me çdo commit në master, ndërtohet projekti.
Automatizojmë nisjen e testeve
Ndërtimi është i mirë, por në realitet projekti mund të ndërtohet pa problem, por të mos funksionojë. Prandaj, hapi vijues është automatizimi i ekzekutimit të testeve. Për më tepër, është shumë e dobishme të shikosh rezultatin e kalimit të testeve kur bën rishikimin e PR — e di me siguri që testet kalojnë dhe askush nuk ka harruar të ekzekutojë degën e tij para se të bëjë merge.
Bëjmë nisjen e testeve gjatë krijimit të pull-request-it dhe merge në master, dhe po ashtu do të shtojmë ndërtimin e raportit mbi mbulimin e kodit.
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 }}
Për mbulimin e testeve përdor codecov në kombinim me plugjin jacoco. Codecov ka veprimin e tij, por për të punuar me pull-request-in tonë, i nevojitet një token:
${{ secrets.CODECOV_TOKEN }} — një konstrukt të tillë do ta takojmë edhe disa herë, secrets është mekanizmi i ruajtjes së sekreteve në GitHub, ku mund të përshkruajmë fjalëkalime/tokenë/hoste/URL dhe të dhëna të tjera që nuk duhet të shfaqen në kodin burim.
Të shtosh një variabël në secrets, mund të bëhet në cilësimet e depozitës në GitHub:
Mund të marrësh tokenin në pas autorizimit përmes GitHub, për të shtuar një projekt publik, thjesht duhet të ndjekësh një lidhje të këtij lloji: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Shtojmë plugjin jacoco në skedarin 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
Tani tani çdo pull request do të hyjë boti codecov dhe do të shtojë grafikun e ndryshimit të mbulimit:
Të shtojmë një analizues statik
Në shumicën e projekteve të mia open source unë përdor sonar cloud për analizën statike të kodit, është mjaft e lehtë të lidhet me travis-ci. Pra, ky është një hap logjik gjatë migrimit në GitHub Actions, të bëjmë të njëjtën gjë. Marketingu i veprimeve është një gjë e shkëlqyer, por këtë herë ai më ka lënë pak në baltë, sepse për zakon kam gjetur veprimin e nevojshëm dhe e kam shkruar atë në workflow. Doli se sonar nuk mbështet funksionimin përmes veprimit për analizimin e projekteve në maven ose gradle. Kjo është shpjeguar natyrisht në dokumentacion, por kush e lexon atë?!
Përmes veprimit nuk është e mundur, kështu që do ta bëjmë përmes 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 — mund të merret në dhe duhet të shkruhet në secrets. GITHUB_TOKEN — është një token i integruar, i cili gjenerohet nga GitHub, me të cilin sonarcloud[bot] do të mund të autentikohet në git, për të lënë komente në pull requestet.
Dsonar.projectKey — emri i projektit në sonar, mund të shikohet në cilësimet e projektit.
Dsonar.organization — emri i organizatës nga GitHub.
Bëmë një pull request dhe presim, kur sonarcloud[bot] të vijë me komente:
Menaxhimi i lëshimeve
Ndërtimin e kemi konfiguruar, testet i kemi kryer, tani mund të bëjmë një lëshim. Le të shohim se si GitHub Actions ndihmon shumë në thjeshtimin e menaxhimit të lëshimeve.
Në punë kam projekte, baza e kodit të cilëve ndodhet në bitbucket (siç thotë historia «në ditë shkruaj në bitbucket, në natë komitoj në GitHub»). Fatkeqësisht, bitbucket nuk ka mjete të ndërtuara për menaxhimin e lëshimeve. Kjo është një problem, sepse për çdo lëshim duhet të krijohet manualisht një faqe në confluence dhe të derdhen atje të gjitha karakteristikat që janë përfshirë në lëshim, të rishikohet tërë mendja, detyrat në jira, komitet në depo. Ka shumë shanse për gabime, mund të harrohet diçka ose të shkruhet ajo që është lëshuar më herët, ndonjëherë është thjesht e paqartë se çfarë duhet t'i atribuohesh një pull-request-i — është një karakteristikë apo një rregullim gabimesh, ose një rregullim testesh, ose diçka infrastrukturore.
Si mund të na ndihmojë GitHub actions? Ka një ekzekutues të shkëlqyer — release drafter, ai lejon të përcaktohet një shabllon i skedarit release notes, në mënyrë që të konfigurohen kategoritë e pull-request-eve dhe t'i grupojë automatikisht ato në skedarin release notes:
Shembuj i shabllonit për konfigurimin e raportit (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Karakteristika të Reja'
labels:
- 'type:features'
# në këtë kategori mbledhim të gjitha PR me etiketën type:features
- title: ' Rregullime Gabimesh'
labels:
- 'type:fix'
# njësoj për etiketën type:fix etj.
- title: ' Dokumentacion'
labels:
- 'type:documentation'
- title: ' Konfigurim'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Ndryshimet
$CHANGES
Shtojmë skriptin për gjenerimin e një skice të lëshimit (.github/workflows/release-draft.yml):
name: "Krijo skicën e lëshimit"
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 }}
Të gjitha pull-request-et nga ky moment do të grumbullohen automatikisht në release notes — magji!
Këtu mund të lindë pyetja: çfarë nëse zhvilluesit harrojnë të vendosin etiketat në PR? Atëherë është e paqartë, në cilën kategori i përket, dhe përsëri do të duhet të merremi me secilin PR veç e veç. Për të zgjidhur këtë problem, mund të përdorim një tjetër ekzekutues — label verifier — ai kontrollon prani e etiketimeve në pull-request. Nëse nuk ka asnjë etiketë të detyrueshme, atëherë verifikimi do të dështojë dhe ne do ta shohim këtë mesazh në pull-request-in tonë.
name: "Verifiko etiketat e tipit"
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'
Tani çdo pull-request duhet të etiketohet me një nga etiketat: type:fix, type:features, type:documentation, type:tests, type:config.
Auto-anotimi i kërkesave për tërheqje
Pasi që përmendëm një temë si puna efektive me kërkesat për tërheqje, duhet të flasim edhe për një veprim si labeler, i cili vendos etiketa në PR në bazë të dosjeve që janë ndryshuar. Për shembull, mund ta marksim si [build] çdo kërkesë për tërheqje që ka ndryshime në katalogun .github/workflow.
Të lidhësh këtë është mjaft e thjeshtë:
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 }}
Na nevojitet gjithashtu një file për përshkrimin e përputhshmërisë së katalogjeve të projektit me temat e kërkesave për tërheqje:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nuk arrita të bashkoj veprimin që automatikisht vendos etiketa në kërkesat për tërheqje me veprimin që kontrollon praninë e etiketeve obligative, match-label nuk do të pranojë etiketat e vendosura nga boti. Duket se është më e lehtë të shkruash veprimin tënd, që bashkon të dy fazat. Por edhe në këtë formë, është mjaft e lehtë të përdoret, duhet të zgjidhni një etiketë nga lista kur krijoni kërkesën për tërheqje.
Është koha për të bërë deploy
Kam provuar disa variante për deploy përmes GitHub Actions (nëpërmjet ssh, nëpërmjet scp, dhe me docker-hub), dhe mund të them se, me sa duket, do të gjeni një mënyrë për të ngarkuar binarin në server, pavarësisht se sa i komplikuar është pipeline juaj.
Më pëlqeu varianti që mbante gjithë infrastrukturën në një vend, prandaj le të shohim se si të bëjmë deploy në GitHub Packages (ky është një depo për përmbajtje binare, npm, jar, docker).
Skirp tim i ndërtimit të imazhit docker dhe publikimit të tij në GitHub Packages:
emri: Nxjerr imazhin docker
në:
shtyp:
degët:
- 'master'
punët:
ndërtim_imazhi_docker:
funksionon në: ubuntu-18.04
hapa:
# Ndërto JAR:
- përdor: actions/checkout@v1
- emri: caktoni JDK 11
përdor: actions/setup-java@v1
me:
java-version: 1.11
- emri: Paketa Maven
ekzekuto: mvn -B clean compile package -DskipTests
# Caktoni variabla globale mjedisi:
- emri: caktoni env global
id: global_env
ekzekuto: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com\/${GITHUB_REPOSITORY}\/${GITHUB_REPOSITORY#*\/}"
# Ndërtoni imazhin Docker:
- emri: Ndërto dhe etiketoni imazhin
ekzekuto: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- emri: Konektimi në Docker
ekzekuto: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publikoni imazhin në repositorin e paketave në github:
- emri: Publiko imazhin
env:
IMAGE_NAME: $GITHUB_REPOSITORY
ekzekuto: docker push "docker.pkg.github.com\/$GITHUB_REPOSITORY\/${{ steps.global_env.outputs.IMAGE_NAME }}"
Për të filluar, na duhet të ndërtojmë skedarin JAR të aplikacionit tonë, pas së cilës llogaritëm rrugën për regjistrin Docker të GitHub dhe emrin e imazhit tonë. Këtu ka disa figura që nuk i kemi hasur më parë:
- Struktura e formatit: echo «::set-output name=NAME::VALUE» lejon caktimin e një vlerë varianti në hapin aktual, në mënyrë që të mund të lexohet më vonë në të gjithë hapat e tjerë.
- Për të marrë vlerën e variantit të caktuar në hapin e mëparshëm mund të përdorim identifikuesin e këtij hapi: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Në ndryshoren standarde GITHUB_REPOSITORY ruhen emri i repositorit dhe pronari («owner/repo-name»). Për të nxjerrë nga kjo varg gjithçka përveç emrit të repositorit, do të përdorim sintaksën bash: ${GITHUB_REPOSITORY#*\/}
Më pas, duhet të ndërtojmë imazhin docker:
docker build -t "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions:latest"
Identifikohuni në regjistër:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Dhe publikoni imazhin në Repositorin e Paketave në GitHub:
docker push "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions"
Për të caktuar versionin e imazhit, ne përdorim shifrat e para nga SHA-hashi i commit-it — GITHUB_SHA këtu gjithashtu ka nuanca, nëse do të bëni këto ndërtime jo vetëm gjatë bashkimit në master, por edhe për ngjarjen e krijimit të një kërkese për bashkim, atëherë SHA mund të mos përputhet me hash-in që ne shohim në historinë e git-it, sepse veprimi actions/checkout krijon një hash unik, për të shmangur bllokimin e ndërsjellë të veprimeve në PR.
Nëse gjithçka ka shkuar për mrekulli, atëherë duke hapur seksionin e paketave (https://github.com/antkorwin/github-actions/packages) në repositor, do të shihni një imazh të ri docker:
At the same place, you can view the list of Docker image versions.
All that's left is to configure our server to work with this registry and restart the service. I'll probably explain how to do this with systemd another time.
Monitorimi
Let's look at a simple way to perform a health check of our application using GitHub Actions. Our boot application has an actuator, so there's no need to write an API for checking its status; everything is already done for the lazy ones. You just need to hit the 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"}
All we need to do is to write a cron task to check the server, and if it doesn't respond, we will send a notification to Telegram.
First, let's figure out how to run the workflow on a cron schedule:
on:
schedule:
- cron: '*/5 * * * *'
It's simple, I can't believe that such events can be created in GitHub, which don't fit into webhooks at all. The details are in the documentation:
We'll check the server status manually using 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 failed"
exit 1
fi
echo "It's OK"
First, we save the response from the server to a variable, then in the next step, we check that the status is UP and, if not, we exit with an error. If you need to manually 'fail' the action, then exit 1 — is a suitable instrument.
- 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 }}
We send the notification to Telegram only if the action failed in the previous step. To send a message, we use appleboy/telegram-action; you can read in the documentation how to obtain the bot token and chat ID:
Do not forget to specify in the GitHub secrets: the server URL and the tokens for the Telegram bot.
Bonus track — JIRA for the lazy
I promised that we would return to JIRA, and we did. I have seen hundreds of times in stand-ups the situation where developers have implemented a feature, merged a branch, but forgot to move the task in JIRA. Of course, if all this were done in one place, it would be easier, but in fact, we write code in an IDE, merge branches in Bitbucket or GitHub, and then move tasks in Jira, which requires opening new windows, sometimes logging in again, etc. When you clearly remember what needs to be done next, there’s no point in opening the board again. As a result, in the morning during the stand-up, we need to spend time updating the task board.
GitHub will help us with this routine task as well; to start, we can automatically move tasks to the code_review column when we submit a pull request. All that is needed is to adhere to the branch naming convention:
[project_name]-[task_number]-title
for example, if the project key "GitHub Actions" is GA, then GA-8-jira-bot could be a branch for implementing task GA-8.
The integration with JIRA works through actions from Atlassian; they are not perfect, and I must say that some of them have not worked for me at all. But we will discuss only those that definitely work and are actively used.
To begin with, you need to authorize in JIRA using the action: 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 this, you need to obtain a token in JIRA; how to do this is described here:
We extract the task identifier from the branch name:
- 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 "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo successfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
If you search in the GitHub marketplace, you can find an action for this task, but I had to write the same thing using grep on the branch name because that action from Atlassian did not want to work on my project; figuring out what was wrong took longer than doing the same manually.
Nuk duhet vetëm të transferoni detyrën në kolonën "Code review" kur krijoni pull request-in:
- emri: Kalimi i detyrës
nëse: ${{ sukses() }}
përdor: atlassian/gajira-transition@master
me:
detyra: ${{ hapat.gjej_detyrën.daljet.ISSUE_ID }}
kalimi: "Code review"
Për këtë ka një veprim të veçantë në GitHub, gjithçka që i nevojitet është identifikuesi i detyrës, i marrë në hapin e mëparshëm, dhe autorizimi në JIRA, që e bëmë më lart.
Po ashtu, mund të tërhiqni detyrat gjatë merge në master dhe ngjarjeve të tjera nga GitHub workflow. Në përgjithësi, gjithçka varet nga imagjinata juaj dhe dëshira për të automatizuar proceset e zakonshme.
Përfundimet
Nëse shikoni diagramin klasik të DEVOPS, duhet ta kemi mbuluar të gjitha fazat, përveç operate, mendoj se nëse përpiqemi, mund të gjejmë ndonjë aksion në treg për integrimin me sistemin e ndihmës, kështu që le të mendojmë se pipeline doli mjaft i mirë dhe në bazë të përdorimit të tij mund të nxirren përfundime.
Avantazhet:
- Marketplace me veprimet e gatshme për çdo rast është shumë e shkëlqyer. Në shumicën e tyre, madje mund të shihni burimin, për të kuptuar se si të zgjidhni një detyrë të ngjashme ose të postoni një kërkesë për veçori tek autori direkt në depozitën e GitHub.
- Zgjedhja e platformës së synuar për ndërtim: Linux, macOS, Windows është një veçori mjaft interesante.
- GitHub Packages është një gjë e shkëlqyer, mbajtja e të gjithë infrastrukturës në një vend është e përshtatshme, nuk është nevoja të shfletosh nëpër okë të ndryshme, gjithçka është brenda një apo dy klikimeve dhe është perfekt e integruar me GitHub Actions. Mbështetje për docker registry në versionin falas — kjo është një avantazh i mirë.
- GitHub fsheh sekrety në log-ët e ndërtimit, prandaj përdorimi i tij për mbajtjen e fjalëkalimeve dhe tokenëve nuk është aq i frikshëm. Gjatë të gjithë eksperimenteve të mia nuk kam arritur asnjëherë të shoh sekretin në mënyrë të pastër në konsolë.
- Falë për projektet Open Source
Disavantazhet:
- YML, nuk e pëlqej. Kur punoj me një flow të tillë, mesazhi im më i shpeshtë i commit-it është "riparo formatin yml", atëherë harrohet të vendosësh ndonjë tab, atëherë shkruhet në rreshtin e gabuar. Në përgjithësi, të qëndrosh përpara ekranit me tjetër ndihmues dhe linjën nuk është një aktivitet i këndshëm.
- DEBUG, debugimi i flow me commit-e, nisjen e ri ndërtimit dhe output-in në konsolë nuk është gjithmonë i përshtatshëm, por kjo është më shumë në kategorinë "ju jeni tepruar", jeni mësuar të punoni me IDEA të përshtatshme, kur mund të debugoni gjithçka.
- Mund ta shkruash një aksion mbi çfarëdo nëse e mbështjell në Docker, por natyrshëm mbështetet vetëm JavaScript; sigurisht, është një çështje shije, por do të preferoja diçka tjetër në vend të JS.
Më kujto, se depoja me të gjithë skriptet është këtu:
Javën e ardhshme do të flas në konferencën Heisenbug 2020 Piter. Do të flas jo vetëm për mënyrën se si të shmangim gabimet gjatë përgatitjes së të dhënave testuese, por gjithashtu do të ndaj sekretet e mia për punën me grupe të dhënash në aplikacionet Java!
Burimi: habr.com
