Ma pean sageli koostama pipeline'i Java projektide koosolekuks. Mõnikord on need avatud lähtekoodiga ja mõnikord mitte. Hiljuti otsustasin proovida viia osa oma repository'sid Travis-CI ja TeamCity GitHub Actions'i ning siin on, mis sellest välja tuli.
Mida hakkame automatiseerima
Esiteks vajame projekti, mida automatiseerida, teeme lihtsa rakenduse Spring Boot / Java 11 / Maven. Käesolevas artiklis ei ενδιαhoolinud me rakenduse loogikat, me ei ole ümbritseva infrastratuuri suhtes vaid oluline, seega piisab meile lihtsast REST API kontrollerist.
Algallikaid saab vaadata siit: kõik pipeline'i tootmisetapid on kajastatud selle projekti pull-requestides.
JIRA ja planeerimine
Tuleb märkida, et me kasutame tavaliselt JIRA'd ülesannete jälgimiseks, seega loome selle projekti jaoks eraldi tahvli ja lisame sinna esimesed ülesanded:
Veidi hiljem pöördume veel tagasi, et vaadata, mida huvitavat võivad anda JIRA ja GitHub koos.
Automatiseerime projekti koostamise
Meie testprojekt koosneb maven'i kaudu, seega on selle koostamine üsna lihtne. Kõik, mida me vajame, on mvn clean package.
Selleks, et kasutada Github Actions, peame me oma repos looma faili, mis kirjeldab meie töövoogu. Seda saab teha tavalise yml-failiga. Ma ei saa öelda, et mulle meeldib «programmeeri yml-is», aga mis seal ikka — loome kaustas .github/workflow faili build.yml, milles kirjeldame tegevusi master haru koostamisel:
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 — see on sündmuse kirjeldus, mille põhjal meie skript käivitatakse.
on: pull_request / push — ütleb, et see töövoog tuleb käivitada iga korraga, kui sooritatakse push masterisse ja luuakse pull-request.
Edasi tuleb ülesannete kirjeldus (töödeks.) ja iga ülesande täitmise samme (steps) cada ülesande jaoks.
runs-on — siin saame valida siht-OS-i, üllatavalt saab valida isegi Mac OS-i, kuid privaatsetes repodes on see üsna kallis lõbu (võrreldes linuxiga).
uses võimaldab taaskasutada teisi tegevusi, näiteks tegevuse actions/setup-java abil seadistame Java 11 keskkonna.
Kasutades with saame määrata parameetrid, millega me tegevust buvatsime, põhimõtteliselt on see argumentides, mis edastatakse tegevusele.
Jäi vaid käivitada Maveniga projekti koostamine: run: mvn -B clean package lipuke -B ütleb, et vajame non-interactive moodi, et Maven ei küsiks meilt äkki midagi.
Suurepärane! Nüüd, iga kord, kui teeme commit'i masterisse, käivitatakse projekti koostamine.
Automatiseerime testide käivitamise.
Koostamine on hea, kuid tegelikkuses võib projekt edukalt koostada, kuid mitte töötada. Seetõttu tuleb järgmise sammuna tegeleda testide automaatse käivitamisega. Lisaks on üsna mugav näha testide läbimise tulemusi PR-i ülevaatamisel — sa tead täpselt, et testid läbisid ja keegi ei unustanud oma haru läbida, enne kui märgis tuleb.
Käivitame testid pull-request'i loomisel ja merge'imisel masterisse ning lisame ka koodi katvuse raporti koostamise.
nimi: Build
kui:
pull_request:
harud:
- '*'
push:
harud:
- 'master'
töökohad:
ehita:
töötab: ubuntu-18.04
sammud:
- kasutab: actions/checkout@v1
- nimi: seadista JDK 11
kasutab: actions/setup-java@v1
koos:
java-versioon: 1.11
- nimi: Maven Verify
jookseb: mvn -B clean verify
- nimi: Test Coverage
kasutab: codecov/codecov-action@v1
koos:
token: ${{ secrets.CODECOV_TOKEN }}
Testide katmiseks kasutan codecov'i koos jacoco pluginiga. Codecovi jaoks on olemas oma tegevus, kuid selle tööks meie pull-request'iga on vajalik token:
${{ secrets.CODECOV_TOKEN }} — sellise konstruktsiooniga kohtame veel korduvalt, secrets on mehhanism saladuste hoidmiseks GitHubis, saame sinna salvestada paroole/tokene/hoste/URL-e ja muid andmeid, mida ei tohiks koodivoos avalikustada.
Muuda varianti secrets, seda saab teha repositooriumi seadetest GitHubis:
Toku saab saada aadressilt pärast sisselogimist GitHubi kaudu, et lisada avalikku projekti, tuleb lihtsalt käia lingil kujul: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Lisame jacoco plagiini POM-faili:
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
Nüüd pääseb meie iga pull request'i juurde codecov bot ja lisab katvuse muutumise graafiku:
Lisame staatilise analüsaatori
Enamikes zijn lihtne kasutada sonar cloud'i koodianalüüsi jaoks enamikus avatud koodiga projektides. See on üsna lihtne ühendada travis-ci-iga. Seega on loogiline samm migreerida GitHub Actions-i, et teha sama. Arendustegevuse turg on äge asjaolu, kuid seekord pettis natuke, kuna leidisin harjumuse järgi vajaliku tegevuse ja kirjutasin selle töövoogu. Selgus, et sonar ei toeta analüüsi läbiviimist tegevuse kaudu projektide uurimiseks maven või gradle-il. Selle kohta on muidugi dokumentatsioonis kirjutatud, aga kes seda ikka loeb?!
Tegevuse kaudu ei toimi, seega teeme mvn plugina kaudu:
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 — saab saada aadressilt ja tuleb lisada see secrets-i. GITHUB_TOKEN — see on selle otstarbeks genereeritud GitHub'i token, mille abil sonarcloud[bot] saab autoriseerida end Git'is, et jätta meile kommentaare pull-request'ides.
Dsonar.projectKey — projekti nimi Sonaris, selle leiad projekti seadetes.
Dsonar.organization — organisatsiooni nimi GitHub'is.
Teeme pull-request'i ja ootame, kuni sonarcloud[bot] tuleb kommentaaridesse:
Release management
Ehitame, testime ja oleme valmis riliseerima. Vaatame, kuidas GitHub Actions aitab oluliselt lihtsustada release management'i.
Tööl on mul projekte, mille koodibaas asub bitbucket'is (just nagu loos „päeval kirjutan bitbucket'i, öösel kommiitan GitHub'i”). Kahjuks ei ole bitbucket'is sisseehitatud vahendeid releaside haldamiseks. See on probleem, kuna iga releasi jaoks tuleb käsitsi luua leht confluence'is ja lisada sinna kõik funktsioonid, mis releasi sisse kuuluvad, läbi kirjutada, vaadata ülesandeid jira's, commit'e repos. Palju on eksimisi, võib midagi unustada või kirjutada midagi, mida oleme juba eelmine kord asetanud. Aeg-ajalt on lihtsalt raske mõista, kuhu mingi pull-request kuulub — kas see on funktsioon, veaparandus, testide parandamine või midagi infrastruktuurset.
Kuidas saavad GitHubi toimingud meid aidata? On suurepärane toiming — release drafter, mis võimaldab määrata release notes'i faili шаблон, et seadistada pull-requestide kategooriad ja automaatselt rühmitada neid release notes faili:
Näidis шаблон aruande seadistamiseks (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: 'Uued funktsioonid'
labels:
- 'type:features'
# sellesse kategooriasse kogume kõik PR-id, millel on silt type:features
- title: 'Veaparandused'
labels:
- 'type:fix'
# samamoodi sildi type:fix jaoks jne.
- title: 'Dokumentatsioon'
labels:
- 'type:documentation'
- title: 'Seadistamine'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Muudatused
$CHANGES
Lisame skripti release'i mustandi genereerimiseks (.github/workflows/release-draft.yml):
name: "Loo mustand releas"
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 }}
Kõik pull-requestid kogutakse alates sellest hetkest automaatselt release notes'i — maagia!
Siin võib tekkida küsimus: mis siis, kui arendajad unustavad PR-idesse märgid lisada? Siis ei ole selge, millisesse kategooriasse see kuulub, ja tuleb jälle iga PR-i eraldi käsitsi läbi vaadata. Selle probleemi lahendamiseks saame kasutada veel üht tegevust — label verifier — mis kontrollib, kas pull-request'is on olemas vajalikud sildid. Kui ühtegi nõutav ära sildi ei ole, siis kontroll läheb läbi ja selle kohta saame teate oma pull-requestis.
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'
Nüüd peab iga pull-request olema varustatud ühe sildiga: type:fix, type:features, type:documentation, type:tests, type:config.
Automaatselt annotatsioon pull-request'idele
Kuna me puudutasime teemat, kuidas efektiivselt töötada pull-request'idega, tasub rääkida ka tegevusest, nagu labeler, mis lisab PR-idele silte vastavalt muudetud failidele. Näiteks võime märgistada [build] pull-request'i, millel on muudatused kataloogis .github/workflow.
Selle aktiveerimine on üsna lihtne:
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 }}
Meil on ka vaja faili, mis kirjeldaks projekti kataloogide sobivust pull-requestide temaatikatega:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Mul ei õnnestunud automatiseeritud märgendamise tegevust pull-requestides ühendada tegevusega, mis kontrollib kohustuslikke märke; match-label ei tunne botiga pandud silte. Tundub, et lihtsam on kirjutada oma tegevus, mis ühendaks mõlemad sammud. Kuid isegi sellisel viisil on kasutamine üsna mugav, peate lihtsalt valima silti loendist pull-requesti loomisel.
On aeg deployida
Olen proovinud mitmeid versioone deploy'ist GitHub Actions'i kaudu (ssh, scp ja docker-hub'i abil) ja võin öelda, et tõenäoliselt leiate viisi binaari serverisse laadimiseks, olenemata sellest, kui veider teie pipeline on.
Mulle meeldis mõte hoida kogu infrastruktuur ühes kohas, seega vaatame, kuidas teha juurutust GitHub Packages'is (see on binaarsisuga registri, npm, jar, docker jaoks).
Docker-pildi ehitamise ja selle avaldamise skript GitHub Packages'is:
name: Juuruta docker pilt
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# Ehita JAR:
- uses: actions/check-out@v1
- name: seadista JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven paket
run: mvn -B clean compile package -DskipTests
# Seadista globaalsete keskkonna muutujaid:
- name: seadista globaalne 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#*/}"
# Ehita Docker pilt:
- name: Ehita ja märgi pilt
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 sisselogimine
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Avalda pilt GitHubi paketiregistrisse:
- name: Avalda pilt
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Alustuseks peame koguma meie rakenduse JAR-faili, seejärel arvutame GitHubi docker registry tee ja meie pildi nime. Siin on mõned nipid, millega me veel ei ole kokku puutunud:
- struktuur nagu: echo «::set-output name=NAME::VALUE» võimaldab määrata muutuja väärtuse praeguses etapis, et seda saaks hiljem lugeda kõikides teistes etappides.
- Muudatava etapi määratud muutuja väärtuse saame tänu selle etapi identifikaatorile: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standardne muutuja GITHUB_REPOSITORY sisaldab repo nime ja selle omanikku («owner/repo-name»). Et välja lõigata kõik peale repo nime, kasutame bash süntaksit: ${GITHUB_REPOSITORY#*/}
Järgmiseks peame koguma docker-pildi:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Registreeruma registry's:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Ja avaldama pildi GitHub Packages Repository's:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Pildi versiooni näitamiseks kasutame SHA-koodi kommi esimesi numbreid — GITHUB_SHA osas on ka nüansse. Kui teete selliseid koguseid mitte ainult masteris ühildumisega, vaid ka pull-request'i loomise sündmuse põhjal, siis SHA ei pruugi kattuda git'i ajaloos nähtava hashiga, kuna actions/checkout tekitab oma ainulaadse hash'i, et vältida vastastikusest blokeerimist PR-is.
Kui kõik läks hästi, näete, avades pakettide jaotise (https://github.com/antkorwin/github-actions/packages) oma hoidlas, uut Docker'i pilti:
Seal on võimalik vaadata ka Docker'i pildi versioonide nimekirja.
Käib ainult serveri seadistamine selle registriga töötamiseks ja teenuse taaskäivitamine. Kuidas seda teha läbi systemd, räägin tõenäoliselt järgmine kord.
Jälgimine
Vaatame lihtsat varianti, kuidas teha meie rakenduse tervisekontrolli GitHub Actionsi abil. Meie alustavas rakenduses on actuator, nii et API selle oleku kontrollimiseks ei pea isegi kirjutama, kõik on laisade jaoks juba valmis. Peab lihtsalt hosti tõukama: 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"}
Kõik, mida me vajame, on kirjutada serveri kontrollimise ülesanne croni, ja kui ta meile vastata ei taha, siis saadame teate Telegrami.
Alustame sellest, kuidas käivitada töövoog croni kaudu:
on:
schedule:
- cron: '*/5 * * * *'
Kõik on lihtne, isegi ei usuks, et GitHubis on võimalik luua selliseid sündmusi, mis ei mahu üldse webhookide raamidesse. Üksikasjad on dokumentatsioonis:
Serveri oleku kontrolli teeme käsitsi läbi curl'i:
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"
Esiteks salvestame muutuja, mille server vastas päringule, ning järgmises etapis kontrollime, et staatuseks oleks UP, ja kui see pole nii, väljumisime vea korral. Kui on vaja käsitsi "tappida" tegevus, siis exit 1 on sobiv relv.
- nimi: saada teavitus telegramis
kui: ${{ failure() }}
kasutab: appleboy/telegram-action@master
koos:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Tervise kontroll:
${{secrets.SERVER_HOST}}/api/actuator/health
ebaõnnestus tulemusega:
${{ steps.ping.outputs.status }}
Telegrami saatmise teeme ainult siis, kui eelmine toiming ebaõnnestus. Sõnumi saatmiseks kasutame appleboy/telegram-action, kuidas saada boti token ja chati ID, saab lugeda dokumentatsioonist:
Ärge unustage lisada GitHubi saladustesse: serveri URL ja telegrammi boti tokenid.
Boonusraja — JIRA laiskadele
Lubasin, et tuleme tagasi JIRA juurde, ja me tulimegi. Sadu kordi olen seisanud seistes näinud olukorda, kus arendajad tegid funktsiooni, ühendasid haru, kuid unustasid JIRA ülesande edasi viia. Loomulikult oleks kõik see lihtsam, kui kõik toimuks ühes kohas, kuid tegelikult kirjutame me koodi IDEs, ühendame haru bitbucketis või GitHubis ning ülesandeid vedame JIRA-sse, selleks tuleb avada uusi aknaid, mõnikord registreeruda uuesti jne. Kui sa mäletad, mida edasi teha, pole mõtet bordi liigselt avada. Lõppkokkuvõttes tuleb hommikul seistes kulutada aega ülesannete aktuaalsuse kontrollimiseks.
GitHub aitab meil ka selle rutiinse ülesande juures. Esialgu saame automaatselt lohistada ülesandeid koodi ülevaate kolumni, kui oleme pull-requesti esitanud. Kõik, mis on vajalik — on järgida harude nimetamise kokkulepet:
[projekti nimi]-[ülesande number]-pealkiri
näiteks, kui projekti võti "GitHub Actions" on GA, siis GA-8-jira-bot võib olla haru ülesande GA-8 täitmiseks.
Integratsioon JIRA-ga töötab Atlassiani toimingute kaudu, mis pole ideaalsed. Tuleb öelda, et mõned neist ei ole mul üldse töötanud. Kuid arutame ainult neid, mis tõesti toimivad ja mida aktiivselt kasutatakse.
Esialgu tuleb JIRA-sse sisse logida toimingu kaudu: 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 }}
Selleks tuleb JIRA-s saada token, kuidas seda teha, on kirjas siin:
Tõmbame ülesande identifikaatori haru pealkirjast:
- nimi: Leia probleem
id: leia_probleem
shell: bash
run: |
echo "::set-output name=PROBLEEM_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo haru nimi: $GITHUB_HEAD_REF
echo eraldatud probleem: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- nimi: Kontrolli probleemi
shell: bash
run: |
if [[ "${{steps.leia_probleem.outputs.PROBLEEM_ID}}" == "" ]]; then
echo "Palun nimetage oma haru vastavalt JIRA probleemi: [project_key]-[task_number]-branch_name"
exit 1
fi
echo edukalt leitud JIRA probleem: ${{steps.leia_probleem.outputs.PROBLEEM_ID}}
Kui otsida GitHubi turult, siis saab leida sellele ülesandele tegevuse, kuid pidin kirjutama sama asja grep'iga haru nime järgi, sest see Atlassiani tegevus ei tahtnud mu projektis mingil viisil töötada, uurida, mis seal ei toiminud — võttis kauem aega kui käsitsi sama asja tegemine.
Ainus, mis jääb, on ülesande liigutamine 'Koodide ülevaatus' veergu pull-requesti loomisel:
- nimi: Ülesande üleminek
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.leia_probleem.outputs.PROBLEEM_ID }}
transition: "Koodide ülevaatus"
Selle jaoks on GitHubis spetsiaalne tegevus, mille jaoks on vajalik ainult ülesande ID, mille me eelmisel sammul saime, ja JIRA-s autoriseerimine, mida me ülal tegime.
Sellise lähenemisega saab ülesandeid tõmmata ka siis, kui toimub merge haru masterisse või teiste GitHub töövoogude sündmustega. Lõppkokkuvõttes sõltub kõik teie kujutlusvõimest ja soovist automatiseerida rutiinseid protsesse.
Järeldused
Kui vaadata klassikalist DEVOPS diagrammi, siis oleme katnud kõik etapid, välja arvatud operate. Arvan, et kui pingutada, siis leiab turult mõne tegevuse help-desk süsteemiga integreerimiseks, seega saame pidada, et pipeline on põhjalik ja selle kasutamise põhjal võib järeldusi teha.
Plussid:
- Marketplace valmisolevate tegevustega igasugusteks olukordadeks on tõeliselt lahe. Enamikus neist saab ka allikaid vaadata, et mõista, kuidas sarnast ülesannet lahendada, või saata autorile otsingutaotluse otse GitHubi hoidlas.
- Sihtplatvormi valimine ehitamiseks: Linux, macOS, Windows on päris huvitav funktsioon.
- GitHub Packages on suurepärane asi, kogu infrastruktuuri hoidmine ühes kohas on mugav, ei pea ringi surfama eri aknates, kõik on ühe või kahe hiireklõpsu raadiuses ja suurepäraselt integreeritud GitHub Actionsiga. Docker registry toetus tasuta versioonis on samuti hea eelis.
- GitHub peidab saladusi ehituse logides, seega ei ole selle kasutamine paroolide ja tokenite hoidmiseks nii hirmus. Kogu katsetamise aja jooksul ei suutnud ma kordagi näha saladust puhtal kujul konsoolis.
- Tasuta avatud lähtekoodiga projektide jaoks
Miinused:
- YML, ma ei armasta seda. Sellise töövooga on minu kõige sagedasem commit message "paranda yml formaati", et unustad kuskil tab'i panna või kirjutad valele reale. Ühesõnaga, ekraani ees joonlaud ja transportöör ei ole just kõige meeldivam tegevus.
- DEBUG, voogude tõrgete leidmine committide, uuesti ehitamise käivitamise ja konsooli väljundiga ei ole alati mugav, kuid see on rohkem stiilis "te olete hellitatud", harjunud töötama mugavate IDEA'dega, kus saab tõrkeid lahendada kõigega.
- Oma tegevusi saab kirjutada ükskõik millega, kui selle Dockerisse panna, kuid natiivset toetust on ainult javascriptile, muidugi on see maitse küsimus, aga ma eelistaksin midagi muud js-i asemel.
Tuletan meelde, et kõikide skriptide hoidla on siin:
Järgmisel nädalal esinen ma konverentsil Heisenbug 2020 Peterburis. Räägin mitte ainult sellest, kuidas vältida vigu testandmete ettevalmistamisel, vaid jagan ka oma töö saladusi andmekogumitega Java rakendustes!
Allikas: habr.com
