Često moram da napravim cevovod za izgradnju projekata u Javi. Ponekad je open source, ponekad nije. Nedavno sam odlučio da pokušam da premjestim neke od svojih spremišta iz Travis-CI i TeamCity na GitHub Actions, i to je ono što je ispalo iz toga.
Šta ćemo automatizovati?
Prvo nam je potreban projekat koji ćemo automatizovati, napravimo malu aplikaciju u Spring boot / Java 11 / Maven. Za potrebe ovog članka, logika aplikacije nas uopće neće zanimati; važna nam je infrastruktura oko aplikacije, pa će nam biti dovoljan jednostavan REST API kontroler.
Izvore možete pogledati ovdje: Sve faze izgradnje cjevovoda se odražavaju u zahtjevima za povlačenje za ovaj projekat.
JIRA i planiranje
Vrijedi reći da obično koristimo JIRA kao praćenje problema, pa hajde da napravimo zasebnu ploču za ovaj projekat i tamo dodamo prve probleme:
Malo kasnije ćemo se vratiti na ono što JIRA i GitHub mogu ponuditi u kombinaciji.
Automatiziramo montažu projekta
Naš testni projekat je napravljen preko mavena, tako da je njegova izrada prilično jednostavna, sve što nam treba je mvn clean paket.
Da bismo to uradili koristeći Github Actions, moraćemo da kreiramo datoteku u spremištu koja opisuje naš radni tok, to se može uraditi sa običnom yml datotekom, ne mogu reći da volim „yml programiranje“, ali šta možemo da uradimo - to radimo u .github/ direktorijumu workflow/ datoteci build.yml u kojoj ćemo opisati radnje prilikom izgradnje master grane:
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 — ovo je opis događaja na kojem će biti lansiran naš scenarij.
uključeno: pull_request/push — označava da se ovaj tok posla mora pokrenuti svaki put kada se izvrši pritisak na master i kreiraju se zahtjevi za povlačenje.
Slijedi opis zadataka (radna mjesta) i korake izvršenja (koraci) za svaki zadatak.
runs-on - ovdje možemo odabrati ciljni OS, iznenađujuće, možete odabrati čak i Mac OS, ali na privatnim spremištima to je prilično skupo (u poređenju sa Linuxom).
namjene omogućava vam da ponovo koristite druge radnje, na primjer, pomoću akcije actions/setup-java instaliramo okruženje za Javu 11.
Uz pomoć sa možemo specificirati parametre sa kojima pokrećemo akciju, u suštini to su argumenti koji će biti proslijeđeni akciji.
Sve što ostaje je pokrenuti izgradnju projekta sa Mavenom: run: mvn -B clean package zastava -B kaže da nam je potreban neinteraktivan način rada tako da maven odjednom ne želi da nas nešto pita
Odlično! Sada, svaki put kada se posvetite masteru, počinje izrada projekta.
Automatsko pokretanje testova
Montaža je dobra, ali u stvarnosti, projekat se može sigurno sastaviti, ali ne i raditi. Stoga je sljedeći korak automatizacija probnih izvođenja. Osim toga, prilično je zgodno pogledati rezultate prolaska testova kada radite PR pregled - sigurno znate da su testovi prošli i niko nije zaboravio pokrenuti svoju granu prije spajanja.
Pokrenut ćemo testove prilikom kreiranja pull zahtjeva i spajanja u master, a ujedno ćemo dodati i kreiranje izvještaja o pokrivenosti koda.
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 }}
Da pokrijem testove, koristim codecov u kombinaciji sa jacoco dodatkom. codecov ima svoju akciju, ali mu je potreban token za rad s našim zahtjevom za povlačenje:
${{ secrets.CODECOV_TOKEN }} — videćemo ovu konstrukciju više puta, secrets je mehanizam za pohranjivanje tajni u GitHub, tamo možemo pisati lozinke/tokene/hostove/url-ove i druge podatke koji ne bi trebali biti uključeni u bazu kodova spremišta.
Možete dodati varijablu tajnama u postavkama spremišta na GitHubu:
Možete dobiti token na Nakon autorizacije putem GitHub-a, za dodavanje javnog projekta potrebno je samo slijediti link kao što je ovaj: /[ime repo]. Privatno spremište se također može dodati; da biste to učinili, morate dati codecov prava aplikaciji u Githubu.
Dodajte jacoco dodatak u POM fajl:
<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>
Sada će codecov bot unijeti svaki naš zahtjev za povlačenjem i dodati graf promjene pokrivenosti:
Dodajmo statički analizator
U većini mojih projekata otvorenog koda koristim sonar oblak za statičku analizu koda, vrlo je lako povezati se na travis-ci. Dakle, logičan je korak prilikom migracije na GitHub Actions da učinite isto. Akciono tržište je super stvar, ali ovaj put me je malo iznevjerilo, jer sam iz navike pronašao akciju koja mi je bila potrebna i dodao je u radni tok. Ali pokazalo se da sonar ne podržava rad kroz akciju za analizu projekata na mavenu ili gradleu. Naravno, to piše u dokumentaciji, ali ko to čita?!
To nije moguće kroz akciju, pa ćemo to učiniti preko mvn dodatka:
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 - može se dobiti na i morate ga registrirati u tajnosti. GITHUB_TOKEN - ovo je ugrađeni token koji GitHub generiše, uz pomoć kojeg će se sonarcloud[bot] moći prijaviti na Git kako bi nam ostavljao poruke u zahtjevima za povlačenjem.
Dsonar.projectKey — naziv projekta u sonaru, možete ga vidjeti u postavkama projekta.
Dsonar.organizacija — naziv organizacije sa GitHub-a.
Dajemo zahtjev za povlačenje i čekamo da sonarcloud[bot] dođe u komentarima:
Upravljanje izdanjem
Izgradnja je konfigurirana, testovi su pokrenuti i možemo napraviti izdanje. Pogledajmo kako GitHub Actions može znatno olakšati upravljanje izdanjima.
Na poslu imam projekte čija je baza koda u bitbucket-u (sve je kao u onoj priči „Danju pišem u bitbucket, noću se obavezujem na GitHub“). Nažalost, bitbucket nema ugrađene alate za upravljanje izdanjima. Ovo je problem, jer za svako izdanje morate ručno kreirati stranicu u konfluentu i tamo baciti sve funkcije uključene u izdanje, pretraživati po palatama uma, zadatke u jiri, urezivanja u spremište. Postoji mnogo šansi da pogriješite, možete nešto zaboraviti ili unijeti nešto što je već bilo objavljeno prošli put, ponekad jednostavno nije jasno kako klasificirati zahtjev za povlačenjem - da li je to funkcija ili ispravka greške, ili testovi za uređivanje, ili nesto infrastrukturno.
Kako nam GitHub akcije mogu pomoći? Postoji sjajna akcija - program za izradu izdanja, koji vam omogućava da postavite predložak datoteke s napomenama o izdanju kako biste postavili kategorije zahtjeva za povlačenje i automatski ih grupirali u datoteci s bilješkama o izdanju:
Primjer predloška za postavljanje izvještaja (.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
Dodajte skriptu za generiranje nacrta izdanja (.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 }}
Svi zahtjevi za povlačenjem od sada će se automatski prikupljati u napomenama o izdanju - magija!
Ovdje se može postaviti pitanje: šta ako programeri zaborave staviti oznake u PR? Tada nije jasno u koju kategoriju to staviti, a opet ćete se morati baviti ručno, sa svakim PR-om posebno. Da bismo riješili ovaj problem, možemo koristiti drugu akciju - verifikator oznaka - on provjerava prisutnost oznaka na zahtjevu za povlačenje. Ako nema potrebnih oznaka, provjera će biti neuspješna i vidjet ćemo poruku o tome u našem zahtjevu za povlačenjem.
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'
Sada svaki zahtjev za povlačenjem mora biti označen jednom od oznaka: type:fix, type:features, type:documentation, type:tests, type:config.
Automatsko označavanje zahtjeva za povlačenjem
Budući da smo se dotakli takve teme kao što je efikasan rad sa zahtjevima za povlačenjem, vrijedi razgovarati o takvoj akciji kao što je labeler, on stavlja oznake u PR na osnovu kojih su datoteke promijenjene. Na primjer, možemo označiti kao [build] svaki zahtjev za izvlačenje koji sadrži promjene u direktoriju .github/workflow.
Povezivanje je prilično jednostavno:
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 }}
Također nam je potrebna datoteka koja opisuje korespondenciju između projektnih direktorija i tema zahtjeva za povlačenjem:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nisam uspio upariti radnju koja automatski postavlja oznake u zahtjeve za povlačenjem s akcijom koja provjerava prisutnost potrebnih oznaka; match-label ne želi vidjeti oznake koje je dodao bot. Čini se da je lakše napisati svoju akciju koja kombinuje obe faze. Ali čak i u ovom obliku prilično je zgodan za korištenje; potrebno je odabrati oznaku s liste kada kreirate zahtjev za povlačenje.
Vrijeme je za raspoređivanje
Isprobao sam nekoliko opcija implementacije putem GitHub Actions (preko ssh-a, preko scp-a i korištenjem docker-hub-a), i mogu reći da ćete, najvjerovatnije, pronaći način da učitate binarni fajl na server, bez obzira na to koliko je kriv vaš cjevovod je.
Svidjela mi se opcija čuvanja cjelokupne infrastrukture na jednom mjestu, pa hajde da pogledamo kako da se implementira na GitHub pakete (ovo je spremište za binarni sadržaj, npm, jar, docker).
Skripta za pravljenje docker slike i objavljivanje u GitHub paketima:
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 }}"
Prvo treba da napravimo JAR datoteku naše aplikacije, nakon čega izračunamo putanju do GitHub docker registra i naziv naše slike. Postoji nekoliko trikova na koje još nismo naišli:
- konstrukcija poput: echo “::set-output name=NAME::VALUE” vam omogućava da postavite vrijednost varijable u trenutnom koraku, tako da se može pročitati u svim ostalim koracima.
- možete dobiti vrijednost varijable postavljene u prethodnom koraku kroz identifikator ovog koraka: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standardna varijabla GITHUB_REPOSITORY pohranjuje ime spremišta i njegovog vlasnika (“vlasnik/repo-ime”). Kako bismo izrezali sve iz ovog reda osim imena spremišta, koristit ćemo bash sintaksu: ${GITHUB_REPOSITORY#*/}
Zatim moramo napraviti docker sliku:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Prijavite se u registar:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
I objavite sliku u GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Da bismo naznačili verziju slike, koristimo prve cifre iz SHA hash-a urezivanja - GITHUB_SHA tu su i nijanse, ako takve buildove pravite ne samo pri spajanju u master, već i prema kreiranju zahtjeva za povlačenjem događaj, onda se SHA možda neće podudarati s hešom koji vidimo u historiji git-a, jer akcija/odjava čini vlastiti jedinstveni hash kako bi se izbjegle akcije blokade u PR-u.
Ako je sve dobro ispalo, otvorite odjeljak o paketima (https://github.com/antkorwin/github-actions/packages) u spremištu, vidjet ćete novu docker sliku:
Tamo možete vidjeti i listu verzija docker slike.
Ostaje samo da konfigurišemo naš server da radi sa ovim registrom i ponovo pokrenemo servis. Vjerovatno ću drugi put razgovarati o tome kako to učiniti kroz systemd.
Monitoring
Pogledajmo jednostavnu opciju kako izvršiti provjeru zdravlja naše aplikacije pomoću GitHub Actions. Naša aplikacija za pokretanje ima aktuator, tako da ne trebamo čak ni pisati API da bismo provjerili njen status; već smo uradili sve za lijene. Samo trebate povući 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"}
Sve što trebamo je da napišemo zadatak za provjeru servera pomoću crona, a ako nam iznenada ne odgovori, poslat ćemo obavijest putem telegrama.
Prvo, hajde da shvatimo kako pokrenuti cron radni tok:
on:
schedule:
- cron: '*/5 * * * *'
Jednostavno je, ne mogu čak ni vjerovati da u Githubu možete kreirati događaje koji se uopće ne uklapaju u webhookove. Detalji su u dokumentaciji:
Provjerimo status servera ručno preko curl-a:
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"
Prvo spremamo u varijablu ono što je server odgovorio na zahtjev, u sljedećem koraku provjeravamo da li je status UP i, ako nije tako, izlazimo s greškom. Ako treba da "prevladate" akciju rukama, onda izlaz 1 - odgovarajuće oružje.
- 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 }}
Na telegram šaljemo samo ako akcija nije uspjela u prethodnom koraku. Za slanje poruke koristimo appleboy/telegram-action; o tome kako dobiti bot token i chat id možete pročitati u dokumentaciji:
Ne zaboravite upisati tajne na Github: URL za server i tokene za telegram bot.
Bonus staza - JIRA za lijene
Obećao sam da ćemo se vratiti u JIRA-u i vratili smo se. Stotine puta sam primetio situaciju na stand-up-u kada su programeri napravili funkciju, spojili granu, ali su zaboravili da prevuku problem u JIRA. Naravno, kada bi se sve ovo radilo na jednom mjestu, bilo bi lakše, ali u stvari pišemo kod u IDE-u, spajamo grane u bitbucket ili GitHub, a zatim prevlačimo zadatke u Jira, za to trebamo otvoriti nove prozore , ponekad se ponovo prijavite i sl. Kada se savršeno setite šta sledeće treba da uradite, onda nema smisla ponovo otvarati tablu. Kao rezultat toga, ujutro na standup-u morate provesti vrijeme ažurirajući tablu zadataka.
GitHub će nam također pomoći u ovom rutinskom zadatku; za početak, možemo automatski prevući probleme u stupac code_review kada podnesemo zahtjev za povlačenje. Sve što trebate učiniti je slijediti konvenciju imenovanja grana:
[имя проекта]-[номер таска]-название
na primjer, ako je ključ projekta "GitHub Actions" GA, onda GA-8-jira-bot može biti ogranak za implementaciju zadatka GA-8.
Integracija sa JIRA-om funkcioniše kroz akcije iz Atlassiana, nisu savršene, moram reći da mi neke od njih uopšte nisu radile. Ali razgovarat ćemo samo o onima koji definitivno rade i koji se aktivno koriste.
Prvo se morate prijaviti na JIRA koristeći akciju: 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 }}
Da biste to uradili, morate dobiti token u JIRA-i, kako to učiniti je opisano ovdje:
Izvlačimo identifikator zadatka iz naziva grane:
- 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}}
Ako pretražujete na GitHub marketplaceu, možete pronaći akciju za ovaj zadatak, ali sam morao napisati istu stvar koristeći grep koristeći naziv grane, jer ova akcija iz Atlassiana ni na koji način nije htjela raditi na mom projektu , da shvatite šta tu nije u redu - duže nego da radite istu stvar rukama.
Sve što ostaje je da premjestite zadatak u kolonu “Pregled koda” prilikom kreiranja zahtjeva za povlačenje:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Za ovo postoji posebna akcija na GitHubu, sve što treba je ID problema dobijen u prethodnom koraku i autorizacija u JIRA-i koju smo uradili gore.
Na isti način možete prevući zadatke prilikom spajanja u glavni i druge događaje iz GitHub toka posla. Općenito, sve ovisi o vašoj mašti i želji za automatizacijom rutinskih procesa.
nalazi
Ako pogledate klasični DEVOPS dijagram, pokrili smo sve faze, osim možda rada, mislim da ako pokušate, možete pronaći neku akciju na tržištu za integraciju sa help-desk sistemom, tako da ćemo pretpostaviti da se cevovod okrenuo biti detaljan i na osnovu njegove upotrebe mogu se izvući zaključci.
Pros:
- Marketplace sa gotovim akcijama za sve prilike, ovo je jako cool. U većini njih možete pogledati i izvorni kod da biste razumjeli kako riješiti sličan problem ili postaviti zahtjev za funkciju autoru direktno u GitHub spremište.
- Odabir ciljne platforme za sklapanje: Linux, mac os, windows je prilično zanimljiva karakteristika.
- Github paketi su odlična stvar, zgodno je držati cijelu infrastrukturu na jednom mjestu, ne morate surfati kroz različite prozore, sve je u radijusu od jednog ili dva klika mišem i savršeno je integrirano sa GitHub Actions. Podrška Docker registra u besplatnoj verziji je također dobra prednost.
- GitHub krije tajne u dnevnikima izgradnje, tako da njegovo korištenje za pohranjivanje lozinki i tokena nije toliko strašno. Tokom svih mojih eksperimenata, nikada nisam mogao da vidim tajnu u njenom čistom obliku u konzoli.
- Besplatno za projekte otvorenog koda
Cons:
- YML, pa, ne sviđa mi se. Kada radim sa takvim tokom, najčešća poruka urezivanja koju imam je "popravi yml format", ponekad zaboravite da negdje stavite tab, ponekad je napišete u pogrešnom redu. Općenito, sjedenje ispred ekrana s kutomjerom i ravnalom nije najprijatnije iskustvo.
- DEBUG, otklanjanje grešaka u toku urezivanja, pokretanje rebuild-a i izlaz na konzolu nije uvijek zgodno, ali je više iz kategorije „pretjerali ste“; navikli ste da radite sa prikladnom IDEA-om, kada možete otkloniti bilo šta .
- Svoju radnju možete napisati na bilo čemu ako je umotate u Docker, ali samo je javascript podržan, naravno ovo je stvar ukusa, ali ja bih više volio nešto drugo umjesto js.
Da vas podsjetim da je spremište sa svim skriptama ovdje:
Sljedeće sedmice ću nastupiti sa na Heisenbug 2020 Piter konferenciji. Reći ću vam ne samo kako da izbjegnete greške prilikom pripreme testnih podataka, već ću podijeliti i svoje tajne rada sa skupovima podataka u Java aplikacijama!
izvor: www.habr.com