Često moram izgraditi cjevovod za izgradnju projekata u Javi. Ponekad je open source, ponekad nije. Nedavno sam odlučio pokušati premjestiti neke od svojih repozitorija s Travis-CI i TeamCity na GitHub Actions, i evo što je ispalo iz toga.
Što ćemo automatizirati?
Prvo, trebamo projekt koji ćemo automatizirati, napravimo malu aplikaciju u Spring boot / Java 11 / Maven. Za potrebe ovog članka nećemo se uopće zanimati za logiku aplikacije, bitna nam je infrastruktura oko aplikacije pa će nam biti dovoljan i jednostavan REST API kontroler.
Izvore možete pogledati ovdje: Sve faze izgradnje cjevovoda odražavaju se u zahtjevima za povlačenje za ovaj projekt.
JIRA i planiranje
Vrijedno je reći da obično koristimo JIRA kao praćenje problema, pa napravimo zasebnu ploču za ovaj projekt i tamo dodamo prve probleme:
Malo kasnije vratit ćemo se na zanimljivosti koje JIRA i GitHub mogu ponuditi u kombinaciji.
Automatiziramo montažu projekta
Naš testni projekt izgrađen je putem mavena, tako da je njegova izrada vrlo jednostavna, sve što nam treba je mvn clean paket.
Da bismo to učinili pomoću Github Actions, morat ćemo stvoriti datoteku u repozitoriju koja opisuje naš tijek rada, to se može učiniti s običnom yml datotekom, ne mogu reći da volim “yml programiranje”, ali što možemo - to radimo u .github/ direktoriju workflow/ datoteci build.yml u kojoj ćemo opisati radnje prilikom izgradnje glavne 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 pokrenuta naša skripta.
na: pull_request/push — označava da se ovaj tijek rada mora pokrenuti svaki put kada se izvrši push prema glavnom uređaju i kada se kreiraju zahtjevi za povlačenjem.
Slijedi opis zadataka (poslovi) i koraci izvršenja (koraci) za svaki zadatak.
naletjeti - ovdje možemo odabrati ciljni OS, iznenađujuće, čak možete odabrati Mac OS, ali na privatnim repozitorijima to je prilično skupo (u usporedbi s Linuxom).
namjene omogućuje vam ponovnu upotrebu drugih radnji, na primjer, korištenjem akcije/postavljanje-java akcije instaliramo okruženje za Javu 11.
Putem s možemo specificirati parametre s kojima pokrećemo akciju, u biti to su argumenti koji će biti proslijeđeni akciji.
Sve što preostaje je pokrenuti izgradnju projekta u Mavenu: run: mvn -B clean package zastava -B kaže da nam treba neinteraktivni mod da nas maven odjednom ne želi nešto pitati
Sjajno! Sada, svaki put kada se posvetite masteru, počinje izgradnja projekta.
Automatiziranje testnih pokretanja
Montaža je dobra, ali u stvarnosti se projekt može sigurno sastaviti, ali ne i raditi. Stoga je sljedeći korak automatizacija probnih izvođenja. Osim toga, vrlo je zgodno pogledati rezultate prolaska testova kada radite PR pregled - sigurno znate da testovi prolaze i nitko nije zaboravio pokrenuti svoju granu prije spajanja.
Pokretat ćemo testove prilikom kreiranja pull request-a i spajanja u master, a ujedno ćemo dodati i izradu 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 }}
Za pokrivanje testova koristim codecov u kombinaciji s dodatkom jacoco. codecov ima vlastitu akciju, ali mu je potreban token da radi s našim zahtjevom za povlačenjem:
${{ secrets.CODECOV_TOKEN }} — vidjet ćemo ovu konstrukciju više puta, secrets je mehanizam za pohranu tajni u GitHub, tamo možemo pisati lozinke/tokene/hostove/urlove i druge podatke koji ne bi trebali biti uključeni u bazu koda repozitorija.
Možete dodati varijablu tajnama u postavkama repozitorija na GitHubu:
Token možete dobiti na Nakon autorizacije putem GitHuba, za dodavanje javnog projekta trebate samo slijediti poveznicu poput ove: /[naziv spremišta]. Privatni repozitorij također se može dodati; da biste to učinili, morate dati codecov prava aplikaciji u Githubu.
Dodajte jacoco dodatak u POM datoteku:
<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 od naših zahtjeva za povlačenjem i dodati grafikon promjene pokrivenosti:
Dodajmo statički analizator
U većini svojih projekata otvorenog koda koristim sonar oblak za statičku analizu koda, vrlo je jednostavno spojiti se na travis-ci. Stoga je logičan korak pri prelasku na GitHub Actions učiniti isto. Akcijski market je fora stvar, ali ovaj put me malo iznevjerio, jer sam iz navike pronašao akciju koja mi je trebala i dodao je u workflow. Ali pokazalo se da sonar ne podržava rad kroz akciju za analizu projekata na maven ili gradle. Naravno, to piše u dokumentaciji, ali tko to čita?!
To nije moguće putem akcije, pa ćemo to učiniti putem 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 nabaviti na i trebate ga registrirati u tajnama. GITHUB_TOKEN - ovo je ugrađeni token koji GitHub generira, 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 s GitHuba.
Izrađujemo zahtjev za povlačenje i čekamo da sonarcloud[bot] uđe u komentare:
Upravljanje izdanjima
Gradnja je konfigurirana, testovi su pokrenuti i možemo izdati. Pogledajmo kako GitHub Actions može uvelike olakšati upravljanje izdanjima.
Na poslu imam projekte čija je baza koda u bitbucketu (sve je kao u onoj priči “danju pišem u bitbucket, noću se obvezujem na GitHub”). Nažalost, bitbucket nema ugrađene alate za upravljanje izdanjima. To je problem, jer za svako izdanje morate ručno kreirati stranicu u spoju i tamo baciti sve značajke uključene u izdanje, pretraživati palače uma, zadatke u jiri, predaje u repozitorij. Postoje mnoge mogućnosti da pogriješite, možete zaboraviti nešto ili unijeti nešto što je već objavljeno prošli put, ponekad jednostavno nije jasno u što klasificirati zahtjev za povlačenjem - je li to značajka ili ispravak greške, ili testovi uređivanja ili nešto infrastrukturno.
Kako nam GitHub akcije mogu pomoći? Postoji sjajna radnja - drafter izdanja, omogućuje vam postavljanje predloška datoteke s bilješkama o izdanju za postavljanje kategorija zahtjeva za povlačenjem i njihovo automatsko grupiranje u datoteci s bilješkama o izdanju:
Primjer predloška za postavljanje izvješća (.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 bilješkama o izdanju - magija!
Ovdje se može postaviti pitanje: što ako programeri zaborave staviti oznake u PR? Onda nije jasno u koju kategoriju ga staviti, a opet ćete to morati rješavati ručno, sa svakim PR-om posebno. Kako bismo riješili ovaj problem, možemo upotrijebiti drugu radnju - verifikator oznake - on provjerava prisutnost oznaka na zahtjevu za povlačenjem. Ako nema potrebnih oznaka, provjera neće biti uspješ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 učinkovit rad sa zahtjevima za povlačenje, vrijedi razgovarati o takvoj radnji kao što je labeler, stavlja oznake u PR na temelju toga koje su datoteke promijenjene. Na primjer, možemo označiti kao [build] svaki zahtjev za povlačenjem koji sadrži promjene u direktoriju .github/workflow.
Povezivanje je vrlo 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 treba datoteka koja opisuje korespondenciju između direktorija projekta 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 radnjom koja provjerava prisutnost potrebnih oznaka; match-label ne želi vidjeti oznake koje je dodao bot. Čini se da je lakše napisati vlastitu akciju koja kombinira obje faze. Ali čak iu ovom obliku vrlo je praktičan za korištenje; trebate odabrati oznaku s popisa prilikom stvaranja zahtjeva za povlačenjem.
Vrijeme je za raspoređivanje
Isprobao sam nekoliko opcija implementacije putem GitHub Actions (putem ssh-a, putem scp-a i korištenjem docker-hub-a) i mogu reći da ćete najvjerojatnije pronaći način za učitavanje binarne datoteke na poslužitelj, bez obzira na to koliko je kriv vaš cjevovod je.
Svidjela mi se opcija držanja cijele infrastrukture na jednom mjestu, pa pogledajmo kako implementirati na GitHub pakete (ovo je repozitorij za binarni sadržaj, npm, jar, docker).
Skripta za izradu docker slike i njezino 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 trebamo izgraditi JAR datoteku naše aplikacije, nakon čega izračunavamo put 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” omogućuje vam postavljanje vrijednosti varijable u trenutnom koraku, tako da se onda 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 naziv repozitorija i njegovog vlasnika ("vlasnik/naziv repozitorija"). Kako bismo izrezali sve iz ovog retka osim naziva repozitorija, koristit ćemo bash sintaksu: ${GITHUB_REPOSITORY#*/}
Zatim moramo izgraditi 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"
Kako bismo naznačili verziju slike, koristimo prve znamenke iz SHA hash-a komitiranja - GITHUB_SHA, ovdje također postoje nijanse, ako napravite takve gradnje ne samo pri spajanju u master, već i prema stvaranju zahtjeva za povlačenje događaja, tada se SHA možda neće podudarati s hashom koji vidimo u povijesti git-a, jer radnja radnje/odjave stvara vlastiti jedinstveni hash kako bi se izbjegle radnje zastoja u PR-u.
Ako je sve dobro funkcioniralo, otvorite odjeljak paketa (https://github.com/antkorwin/github-actions/packages) u repozitoriju, vidjet ćete novu docker sliku:
Tamo također možete vidjeti popis verzija docker slike.
Sve što preostaje je konfigurirati naš poslužitelj za rad s ovim registrom i ponovno pokrenuti uslugu. Vjerojatno ću drugi put govoriti o tome kako to učiniti putem systemd-a.
nadgledanje
Pogledajmo jednostavnu opciju kako napraviti provjeru zdravlja naše aplikacije pomoću GitHub Actions. Naša aplikacija za pokretanje ima aktuator, tako da ne trebamo čak ni napisati API da bismo provjerili njen status; već smo sve učinili 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 napisati zadatak za provjeru poslužitelja pomoću crona, a ako nam iznenada ne odgovori, poslat ćemo obavijest putem telegrama.
Prvo, shvatimo kako pokrenuti cron tijek rada:
on:
schedule:
- cron: '*/5 * * * *'
Jednostavno je, ne mogu ni vjerovati da u Githubu možete kreirati događaje koji uopće ne stanu u webhookove. Detalji su u dokumentaciji:
Provjerimo status poslužitelja ručno putem curla:
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 poslužitelj odgovorio na zahtjev, u sljedećem koraku provjeravamo da li je status UP i, ako to nije slučaj, izlazimo s greškom. Ako trebate "pretrpati" akciju rukama, onda izlaz 1 - prikladno 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 }}
Telegramu šaljemo samo ako akcija nije uspjela u prethodnom koraku. Za slanje poruke koristimo appleboy/telegram-action; možete pročitati o tome kako dobiti token bota i chat ID u dokumentaciji:
Ne zaboravite napisati tajne na Githubu: URL za poslužitelj i tokene za telegram bot.
Bonus pjesma - JIRA za lijene
Obećao sam da ćemo se vratiti u JIRU i vratili smo se. Stotine puta sam primijetio situaciju na stand-upu kada su programeri napravili značajku, spojili granu, ali su zaboravili odvući problem u JIRA. Naravno, kada bi se sve ovo radilo na jednom mjestu, bilo bi lakše, ali zapravo pišemo kod u IDE-u, spajamo grane u bitbucket ili GitHub, a zatim povlačimo zadatke u Jira, za to moramo otvoriti nove prozore , ponekad se ponovno prijaviti itd. Kada se savršeno sjetite što trebate učiniti sljedeće, onda nema smisla ponovno otvarati ploču. Kao rezultat toga, ujutro na standupu trebate provesti vrijeme ažurirajući ploču zadataka.
GitHub će nam također pomoći u ovom rutinskom zadatku; za početak, probleme možemo automatski povući u stupac code_review kada pošaljemo zahtjev za povlačenje. Sve što trebate učiniti je slijediti konvenciju o imenovanju grana:
[имя проекта]-[номер таска]-название
na primjer, ako je ključ projekta "GitHub Actions" GA, tada GA-8-jira-bot mogao biti ogranak za provedbu zadatka GA-8.
Integracija s JIRA-om radi preko akcija iz Atlassiana, nisu savršene, moram reći da mi neke od njih uopće nisu radile. Ali razgovarat ćemo samo o onima koji definitivno rade i aktivno se koriste.
Najprije se trebate 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 učinili, 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 tržištu, 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 nije htjela raditi na mom projektu ni na koji način , da shvatite što tu nije u redu - dulje nego da radite istu stvar rukama.
Sve što preostaje je premjestiti zadatak u stupac "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 to postoji posebna radnja na GitHubu, sve što treba je ID problema dobiven u prethodnom koraku i autorizacija u JIRA-i koju smo napravili gore.
Na isti način možete povući zadatke prilikom spajanja u master i druge događaje iz GitHub radnog tijeka. Općenito, sve ovisi o vašoj mašti i želji za automatizacijom rutinskih procesa.
Zaključci
Ako pogledate klasični DEVOPS dijagram, pokrili smo sve faze, osim možda rada, mislim da ako pokušate, možete pronaći neke radnje na tržištu za integraciju sa sustavom službe za pomoć, pa ćemo pretpostaviti da je cjevovod okrenuo biti temeljit i zaključci se mogu izvući na temelju njegove upotrebe.
Pros:
- Tržište s gotovim akcijama za sve prilike, ovo je jako cool. U većini njih također možete pogledati izvorni kod da biste razumjeli kako riješiti sličan problem ili objaviti zahtjev za značajku autoru izravno u GitHub repozitoriju.
- Odabir ciljne platforme za sastavljanje: Linux, mac os, windows prilično je zanimljiva značajka.
- Github Packages je super stvar, zgodno je držati cijelu infrastrukturu na jednom mjestu, ne morate surfati kroz različite prozore, sve je u radijusu jednog ili dva klika mišem i savršeno je integrirano s GitHub Actions. Podrška za Docker registar u besplatnoj verziji također je dobra prednost.
- GitHub skriva tajne u zapisnicima izgradnje, tako da njegova upotreba za pohranu lozinki i tokena nije tako strašna. Tijekom svih mojih eksperimenata nikada nisam uspio vidjeti tajnu u njenom čistom obliku na konzoli.
- Besplatno za projekte otvorenog koda
Cons:
- YML, pa, ne sviđa mi se. Kada radim s takvim tokom, najčešća poruka predaje koju imam je "popravi yml format", onda zaboravite negdje staviti tabulator ili ga napišete u krivom redu. Općenito, sjedenje pred ekranom s kutomjerom i ravnalom nije najugodnije iskustvo.
- DEBUG, otklanjanje pogrešaka u tijeku s obvezama, pokretanje ponovne izgradnje i izlaz na konzolu nije uvijek zgodno, ali više spada u kategoriju "pretjerali ste"; navikli ste raditi s praktičnom IDEA-om, kada možete otkloniti pogreške bilo čega .
- Svoju akciju možete napisati na bilo čemu ako je omotate u Docker, ali samo je javascript izvorno podržan, naravno, to je stvar ukusa, ali ja bih radije nešto drugo umjesto js-a.
Da vas podsjetim da je repozitorij sa svim skriptama ovdje:
Sljedeći tjedan ću nastupiti sa na konferenciji Heisenbug 2020 Piter. Reći ću vam ne samo kako izbjeći pogreške prilikom pripreme testnih podataka, već ću također podijeliti svoje tajne rada sa skupovima podataka u Java aplikacijama!
Izvor: www.habr.com