Spessu aghju da custruisce un pipeline per i prughjetti di custruzzione in Java. A volte hè open source, à volte ùn hè micca. Recentemente aghju decisu di pruvà à spustà alcuni di i mo repositori da Travis-CI è TeamCity à GitHub Actions, è questu hè ciò chì hè ghjuntu.
Chì avemu da automatizà ?
Prima, avemu bisognu di un prughjettu chì avemu da automatizà, facemu una piccula applicazione in Spring boot / Java 11 / Maven. Per i scopi di questu articulu, ùn seremu micca interessatu in a logica di l'applicazione; l'infrastruttura intornu à l'applicazione hè impurtante per noi, cusì un semplice controller API REST ci basterà.
Pudete vede e fonti quì: Tutte e tappe di custruisce un pipeline sò riflesse in e richieste di pull per stu prughjettu.
JIRA è pianificazione
Vale a pena di dì chì usualmente usemu JIRA cum'è un tracker di prublemi, allora creemu un tavulinu separatu per stu prughjettu è aghjunghje i primi prublemi quì:
Un pocu dopu avemu da vultà à ciò chì interessanti cose JIRA è GitHub ponu offre in cumminazione.
Automatizemu l'assemblea di u prugettu
U nostru prughjettu di prova hè custruitu via maven, cusì custruì hè abbastanza simplice, tuttu ciò chì avemu bisognu hè u pacchettu mvn clean.
Per fà questu utilizendu Github Actions, avemu bisognu di creà un schedariu in u repository chì descrive u nostru flussu di travagliu, questu pò esse fattu cù un schedariu yml regulare, ùn possu micca dì chì mi piace "programmazione yml", ma chì pudemu fà - Facemu in u .github/ directory workflow/ file build.yml in quale descriveremu l'azzioni quandu custruiscenu u ramu maestru:
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 - questu hè una descrizzione di l'avvenimentu nantu à quale u nostru script serà lanciatu.
nantu à: pull_request/push - indica chì stu flussu di travagliu deve esse lanciatu ogni volta chì una spinta hè fatta à u maestru è e richieste di pull sò create.
A seguita hè una descrizzione di i travaglii (Franchisee) è passi di esecuzione (passi) per ogni compitu.
corre-on - quì pudemu selezziunà u SO di destinazione, sorprendentemente, pudete ancu sceglie Mac OS, ma nantu à i repositori privati questu hè abbastanza caru (paragunatu à Linux).
Nonza permette di riutilizà altre azzioni, per esempiu, usendu l'azzioni / setup-java chì installemu l'ambiente per Java 11.
Cù l'aiutu di cù pudemu specificà i paràmetri cù quale lanciamu l'azzione, essenzialmente questi sò l'argumenti chì saranu passati à l'azzione.
Tuttu ciò chì resta hè di eseguisce u prughjettu di custruisce in Maven: run: mvn -B clean package bandiera -B dice chì avemu bisognu di un modu micca interattivu per chì u maven di colpu ùn ci vole micca dumandà qualcosa
Perfettu! Avà, ogni volta chì vi impegnate à u maestru, a custruzzione di u prugettu principia.
L'automatizazione di i lanciamenti di teste
L'assemblea hè bona, ma in a realtà, un prughjettu pò esse assemblatu in modu sicuru, ma micca travagliu. Per quessa, u prossimu passu hè di automatizà e teste di prova. In più, hè abbastanza còmuda di guardà i risultati di passà i testi quandu fate una rivista PR - sapete di sicuru chì i testi passanu è nimu ùn si scurdava di curriri a so ramu prima di fà una fusione.
Eseguiremu testi quandu creanu una dumanda di pull è fusione in u maestru, è à u stessu tempu aghjunghjemu a creazione di un rapportu nantu à a cobertura di codice.
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 }}
Per copre e teste, aghju utilizatu codecov in cunghjunzione cù u plugin jacoco. codecov hà a so propria azzione, ma hà bisognu di un token per travaglià cù a nostra dumanda di pull:
${{ secrets.CODECOV_TOKEN }} - Videremu sta custruzzione più di una volta, i secreti hè un mecanismu per almacenà sicreti in GitHub, pudemu scrive quì password / tokens / hosts / urls è altri dati chì ùn deve esse micca inclusi in a basa di codice di repository.
Pudete aghjunghje una variabile à i sicreti in i paràmetri di repository in GitHub:
Pudete piglià un token à Dopu l'autorizazione via GitHub, per aghjunghje un prughjettu publicu basta à seguità un ligame cum'è questu: /[nome repo]. Un repositoriu privatu pò ancu esse aghjuntu; per fà questu, avete bisognu di dà diritti codecov à l'applicazione in Github.
Aghjunghjite u plugin jacoco à u schedariu POM:
<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>
Avà u bot codecov entrerà in ognuna di e nostre richieste di pull è aghjunghje un graficu di cambiamentu di copertura:
Aghjunghjemu un analizatore staticu
In a maiò parte di i mo prughjetti open source, aghju utilizatu sonar cloud per l'analisi di codice staticu, hè abbastanza faciule per cunnette à travis-ci. Allora hè un passu logicu quandu migrate à GitHub Actions per fà u listessu. U mercatu di l'azzione hè una cosa fresca, ma sta volta m'hà lasciatu un pocu, perchè per abitudine aghju trovu l'azzione chì avia bisognu è aghjunghje à u flussu di travagliu. Ma hè risultatu chì u sonar ùn sustene micca u travagliu attraversu una azione per analizà i prughjetti in maven o gradle. Di sicuru, questu hè scrittu in a ducumentazione, ma quale a leghje ?!
Ùn hè micca pussibule per un'azzione, cusì a faremu cù u 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 - pò esse acquistatu à è avete bisognu di registrà in sicreti. GITHUB_TOKEN - questu hè un token integratu chì GitHub genera, cù l'aiutu di quale sonarcloud[bot] puderà login in Git per lascià messagi in pull requests.
Dsonar.projectKey - u nome di u prughjettu in u sonaru, pudete vede in i paràmetri di u prugettu.
Dsonar.urganisazione - nome di l'urganizazione da GitHub.
Facemu una dumanda di pull è aspittemu chì sonarcloud [bot] vene in i cumenti:
Gestione di liberazione
A custruzione hè stata cunfigurata, i testi sò stati eseguiti, è pudemu fà una liberazione. Fighjemu cumu GitHub Actions pò fà a gestione di liberazione assai più faciule.
À u travagliu, aghju prughjetti chì a basa di codice hè in bitbucket (tuttu hè cum'è in quella storia "Scrivu à bitbucket durante u ghjornu, impegnate in GitHub di notte"). Sfortunatamente, bitbucket ùn hà micca strumenti di gestione di liberazione integrati. Questu hè un prublema, perchè per ogni liberazione avete da creà manualmente una pagina in cunfluenza è scaccià tutte e funziunalità incluse in a liberazione quì, cercate à traversu i palazzi di a mente, compiti in jira, cummette in u repository. Ci hè parechje probabilità di fà un sbagliu, pudete scurdà qualcosa o inserisce qualcosa chì era digià liberatu l'ultima volta, à volte ùn hè simplicemente micca chjaru ciò chì classificà una dumanda di pull cum'è - hè una funzione o una correzione di bug, o testi di edizione, o qualcosa di infrastrutturali.
Cumu l'azzioni di GitHub ci ponu aiutà? Ci hè una grande azione - redattore di liberazione, vi permette di stabilisce un mudellu di fugliale di note di liberazione per stabilisce categurie di richieste di pull è automaticamente raggruppate in u schedariu di note di liberazione:
Esempiu di mudellu per stabilisce un rapportu (.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
Aghjunghjite un script per generà un draft release (.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 }}
Tutte e richieste di pull da avà saranu raccolte automaticamente in note di liberazione - magia!
Quì a quistione pò esse: chì si i sviluppatori si scurdanu di mette tag in u PR? Allora ùn hè micca chjaru in quale categuria mette in, è dinò avete da trattà manualmente, cù ogni PR separatamente. Per risolve stu prublema, pudemu usà un'altra azione - verificatore di l'etichetta - verifica a presenza di tag in a dumanda di pull. Se ùn ci sò micca tags richiesti, allora u cuntrollu serà fallutu è vedemu un missaghju nantu à questu in a nostra dumanda di pull.
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'
Avà ogni pull-request deve esse marcatu cù una di e tag: type:fix, type: features, type:documentation, type:tests, type:config.
Annotazione automatica di richieste di pull
Siccomu avemu toccu un tema cum'è un travagliu efficace cù e dumande di pull, vale a pena parlà di una tale azzione cum'è labeler, mette tag in PR basatu nantu à quale i schedari sò stati cambiati. Per esempiu, pudemu marcà cum'è [build] ogni pull request chì cuntene cambiamenti à u cartulare .github/workflow.
A cunnessione hè abbastanza simplice:
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 }}
Avemu ancu bisognu di un schedariu chì descrive a currispundenza trà i repertorii di u prugettu è i temi di pull request:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Ùn aghju micca riesciutu à accoppià l'azzione chì mette automaticamente e etichette in e richieste di pull cù l'azzione chì verifica a presenza di l'etichette richieste; match-label ùn vole micca vede l'etichette aghjuntu da u bot. Sembra più faciule per scrive a vostra propria azzione chì combina i dui fasi. Ma ancu in questa forma hè abbastanza còmuda à utilizà; avete bisognu di selezziunà una etichetta da a lista quandu crea una dumanda di pull.
Hè ora di implementà
Aghju pruvatu parechje opzioni di implementazione via GitHub Actions (via ssh, via scp, è utilizendu docker-hub), è possu dì chì, assai prubabilmente, truverete un modu per carica u binariu à u servitore, ùn importa micca quantu stortu u vostru pipeline. hè.
Mi piaceva l'opzione di mantene l'infrastruttura intera in un locu, cusì fighjemu cumu implementà in i Pacchetti GitHub (questu hè un repository per u cuntenutu binariu, npm, jar, docker).
Script per a custruisce una maghjina docker è a publicazione in i Pacchetti GitHub:
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 }}"
Prima, avemu bisognu di custruisce u schedariu JAR di a nostra applicazione, dopu avè calculatu u percorsu à u registru docker GitHub è u nome di a nostra maghjina. Ci hè uni pochi di trucchi quì chì ùn avemu micca scontru ancu:
- una custruzzione cum'è: echo "::set-output name=NAME::VALUE" permette di stabilisce u valore di una variàbile in u passu currente, in modu chì pò esse lettu in tutti l'altri passi.
- pudete uttene u valore di a variàbile stabilita in u passu precedente attraversu l'identificatore di stu passu: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- A variabile standard GITHUB_REPOSITORY guarda u nome di u repository è u so pruprietariu ("proprietariu / repo-name"). Per taglià tuttu da sta linea eccettu u nome di u repository, useremu a sintassi bash: ${GITHUB_REPOSITORY#*/}
Dopu avemu bisognu di custruisce l'imagine docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Entra in u registru:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
È publicate l'imaghjini à u Repositoriu di Pacchetti GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Per indicà a versione di l'imaghjini, usemu i primi numeri da u SHA hash di u cummitteddu - GITHUB_SHA ci sò ancu sfumature quì, se fate tali custruzzioni micca solu quandu si fusione in maestru, ma ancu secondu a creazione di pull request. avvenimentu, allora SHA ùn pò micca currisponde à l'hash chì vedemu in a storia di git, perchè l'azzione di l'azzioni / checkout face u so propiu hash unicu per evità l'azzioni di bloccu in u PR.
Se tuttu hà travagliatu bè, aprendu a sezione di pacchetti (https://github.com/antkorwin/github-actions/packages) in u repository, vi vede una nova maghjina docker:
Quì pudete ancu vede una lista di versioni di l'imaghjini docker.
Tuttu ciò chì resta hè di cunfigurà u nostru servitore per travaglià cù questu registru è riavvia u serviziu. Probabilmente parleraghju di cumu fà questu attraversu systemd un'altra volta.
Monitoramentu
Fighjemu una opzione simplice nantu à cumu fà un cuntrollu di salute per a nostra applicazione utilizendu GitHub Actions. A nostra applicazione di boot hà un attuatore, cusì ùn avemu mancu bisognu di scrive una API per verificà u so statutu; avemu digià fattu tuttu per i pigri. Basta à tirà l'ospite: 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"}
Tuttu ciò chì avemu bisognu hè di scrive un compitu per verificà u servitore cù cron, è se di colpu ùn ci risponde micca, allora manderemu una notificazione via telegramma.
Prima, scopremu cumu eseguisce un flussu di travagliu cron:
on:
schedule:
- cron: '*/5 * * * *'
Hè simplice, ùn possu mancu crede chì in Github pudete creà avvenimenti chì ùn si adattanu micca à i webhooks. I dettagli sò in a documentazione:
Cuntrollamu u statu di u servitore manualmente via 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"
Prima, salvemu in una variabile ciò chì u servitore hà rispostu à a dumanda, in u passu prossimu verificamu chì u statutu hè UP è, se ùn hè micca u casu, allora esce cù un errore. Sè avete bisognu di "sguassate" una azzione cù e vostre mani, allora surtite 1 - arma adatta.
- 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 }}
Mandemu à telegramma solu se l'azzione falluta à u passu precedente. Per mandà un missaghju usemu appleboy/telegram-action; pudete leghje nantu à cumu uttene un token di bot è chat id in a documentazione:
Ùn vi scurdate di scrive in i sicreti in Github: URL per u servitore è tokens per u telegram bot.
Bonus track - JIRA per i pigri
Aghju prumessu chì vulteremu à JIRA, è avemu tornatu. Centinaie di volte aghju osservatu una situazione in stand-ups quandu i sviluppatori anu fattu una funzione, fusiona una filiera, ma scurdatu di trascinà u prublema in JIRA. Di sicuru, se tuttu questu hè statu fattu in un locu, saria più faciule, ma in fattu scrivimu codice in l'IDE, unisce e rami in bitbucket o GitHub, è poi trascinate i travaglii in Jira, per questu avemu bisognu di apre una nova finestra. , qualchì volta accede à novu è ecc. Quandu vi ricurdate perfettamente ciò chì avete bisognu à fà dopu, allora ùn ci hè nunda à apre u bordu di novu. In u risultatu, in a matina in un standup avete bisognu di passà u tempu per aghjurnà u tavulinu di travagliu.
GitHub ci aiuterà ancu in questa attività di rutina; per principianti, pudemu trascinà i prublemi automaticamente in a colonna code_review quandu inviemu una dumanda di pull. Tuttu ciò chì duvete fà hè di seguità a cunvenzione di denominazione di filiale:
[имя проекта]-[номер таска]-название
per esempiu, se a chjave di u prughjettu "GitHub Actions" hè GA, allora GA-8-jira-bot puderia esse un ramu per l'implementazione di u compitu GA-8.
L'integrazione cù JIRA travaglia per l'azzioni di Atlassian, ùn sò micca perfetti, devi dì chì alcuni ùn anu micca travagliatu per mè in tuttu. Ma avemu da discutiri solu quelli chì definitivamente travaglianu è sò attivamente utilizati.
Prima avete bisognu di login in JIRA usendu l'azzione: 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 }}
Per fà questu, avete bisognu di ottene un token in JIRA, cumu fà questu hè descrittu quì:
Estratemu l'identificatore di u travagliu da u nome di a filiera:
- 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}}
Sè vo circate in u mercatu di GitHub, pudete truvà una azione per questu compitu, ma aghju avutu à scrive a listessa cosa cù grep cù u nome di u ramu, perchè sta azione da Atlassian ùn vulia micca travaglià in u mo prughjettu in ogni modu. , per capisce ciò chì era sbagliatu quì - più longu di fà a listessa cosa cù e vostre mani.
Tuttu ciò chì resta hè di spustà u compitu à a colonna "Revisione di codice" quandu crea una dumanda di pull:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Ci hè una azzione speciale per questu nantu à GitHub, tuttu ciò chì hà bisognu hè l'ID di prublema ottenutu in u passu precedente è l'autorizazione in JIRA chì avemu fattu sopra.
In u listessu modu, pudete arrastà i travaglii quandu si fusione in u maestru, è altri avvenimenti da u flussu di travagliu GitHub. In generale, tuttu dipende di a vostra imaginazione è u desideriu di automatizà i prucessi di rutina.
scuperti
Se fighjate à u schema classicu DEVOPS, avemu cupertu tutte e tappe, salvu forse uperà, pensu chì s'ellu pruvate, pudete truvà qualchì azzione in u mercatu per integrazione cù u sistema di help-desk, cusì assumeremu chì u pipeline turnò. per esse cumpletu è e cunclusioni ponu esse tratte nantu à u so usu.
Pros:
- Mercatu cù azzioni pronti per tutte l'occasioni, questu hè assai cool. In a maiò parte di elli, pudete ancu guardà u codice fonte per capisce cumu risolve un prublema simili o post una dumanda di funziunalità à l'autore direttamente in u repository GitHub.
- A selezzione di a piattaforma di destinazione per l'assemblea: Linux, mac os, windows hè una funzione assai interessante.
- Github Packages hè una grande cosa, hè cunvenutu per mantene l'infrastruttura intera in un locu, ùn avete micca bisognu di navigà attraversu diverse finestre, tuttu hè in un raghju di unu o dui clicchi di mouse è hè perfettamente integratu cù GitHub Actions. U supportu di u registru Docker in a versione libera hè ancu un bonu vantaghju.
- GitHub oculta i sicreti in i logs di custruzzione, cusì l'utilizanu per almacenà password è tokens ùn hè micca cusì spaventoso. Duranti tutti i mo esperimenti, ùn aghju mai pussutu vede u sicretu in a so forma pura in a cunsola.
- Gratuitu per i prughjetti Open Source
Cons:
- YML, bè, ùn mi piace micca. Quandu u travagliu cù un tali flussu, u missaghju di cummissione più cumuni chì aghju hè "fix yml format", qualchì volta vi scurdate di mette una tabulazione in un locu, qualchì volta u scrivite nantu à a linea sbagliata. In generale, à pusà davanti à una schermu cù un protractor è un regnu ùn hè micca l'esperienza più piacevule.
- DEBUG, debugging the flow with commits, run a rebuild, and outputing to the console ùn hè micca sempre cunvene, ma hè più di a categuria "sò overdone"; site abituatu à travaglià cù l'IDEA conveniente, quandu pudete debug qualcosa. .
- Pudete scrive a vostra azzione nantu à qualcosa s'ellu l'imbulighjate in Docker, ma solu javascript hè supportatu nativamente, di sicuru questu hè una questione di gustu, ma preferiscu qualcosa d'altru invece di js.
Lasciami ricurdà chì u repository cù tutti i script hè quì:
A settimana prossima aghju da fà cun à a cunferenza Heisenbug 2020 Piter. Vi dicu micca solu cumu per evità l'errori quandu preparanu dati di prova, ma ancu sparte i mo sicreti di travaglià cù seti di dati in applicazioni Java!
Source: www.habr.com