Së shpesh më duhet të ndërtoj një pipeline për ndërtimin e projekteve në Java. Ndonjëherë është open source, ndonjëherë jo. Kohët e fundit vendosa të provoj të transferoj disa nga reposet e mia nga Travis-CI dhe TeamCity në GitHub Actions, dhe ja çfarë rezultati arrita.
Çfarë do të automatizojmë
Fillimisht, na nevojitet një projekt që do të automatizojmë, le të krijojmë një aplikacion të vogël në Spring Boot / Java 11 / Maven. Brenda kësaj artikulli, logjika e aplikacionit nuk do të na interesojë fare, na rëndësishme është infrastruktura rreth aplikacionit, kështu që na mjafton një kontrollues i thjeshtë REST API.
Mund të shikoni burimet këtu: të gjitha fazat e ndërtimit të pipeline-it reflektohen në pull request-et e këtij projekti.
JIRA dhe planifikimi
Duhet thënë se zakonisht përdorim JIRA si ndjekës të detyrave, prandaj le të krijojmë një board të veçantë për këtë projekt dhe të shtojmë atje detyrat fillestare:
Pak më vonë do të kthehemi të shohim se çfarë interesante mund të ofrojnë lidhja e JIRA dhe GitHub.
Automatizojmë ndërtimin e projektit
Projekti ynë testues ndërtuohet përmes Maven, kështu që ndërtimi i tij është mjaft i thjeshtë, gjithçka që na nevojitet është mvn clean package.
Për ta bërë këtë me GitHub Actions, na duhen krijuar në depo një skedar që përshkruan workflow-in tonë, kjo mund të bëhet me një skedar të zakonshëm yml, nuk mund të them që më pëlqen «programimi në yml», por çfarë të bëjmë — krijojmë në direktorinë .github/workflow/ skedarin build.yml në të cilin 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ë — ky është një përshkrim i ngjarjes, mbi të cilin do të nisë skripti ynë.
on: pull_request / push — tregon se ky workflow duhet të niset për çdo push në master dhe kur krijohen pull request-e.
Më pas vjen përshkrimi i detyrave (punë) dhe hapave të ekzekutimit (steps) për çdo detyrë.
runs-on — këtu mund të zgjidhni sistemin operativ të synuar, për çudi mund të zgjidhni madje edhe Mac OS, por në depo private kjo është një kënaqësi mjaft e shtrenjtë (në krahasim me linux-in).
uses lejon ri-përdorimin e veprimeve të tjera, për shembull, me anë të veprimit actions/setup-java ne vendosim ambientin për Java 11.
Me ndihmën e me ne mund të specifikojmë parametrat me të cilat nisim veprimin, në thelb janë argumentet që do të kalohen në veprimin.
Nuk mbetet gjë tjetër veçse të nisim ndërtimin e projektit me Maven: run: mvn -B clean package flaga -B tregon se na nevojitet mode non-interactive, që Maven të mos na pyesë për ndonjë gjë.
Shkëlqyer! Tani, me çdo commit në master, aktivizohet ndërtimi i projektit.
Automatizojmë nisin e testeve
Ndërtimi është i mirë, por në realitet projekti mund të ndërtosh mirë, por të mos funksionojë. Prandaj hapi tjetër është të merremi me automatizimin e ekzekutimit të testeve. Për më tepër, është shumë e dobishme të shihni rezultatet e kalimit të testeve kur bëni rishikimin e PR - e dini saktësisht që testet përshkohen dhe askush nuk harroi, para se të bëni bashkimin, të testoni filialin tuaj.
Nisim ekzekutimin e testeve kur krijojmë pull request dhe bashkohen në master, dhe njëkohësisht të shtojmë ndërtimin e raportit për 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, unë përdor codecov në bashkëpunim me plugin-in jacoco. codecov ka veprimin e tij, por për të punuar me pull-request-in tonë, ai i nevojitet një token:
${{ secrets.CODECOV_TOKEN }} — një konstruksion të tillë do ta takojmë edhe disa herë, secrets është mekanizmi i ruajtjes së sekreteve në GitHub, ku mund të regjistrojmë fjalëkalime/token, hoste, URL dhe të dhëna të tjera që nuk duhet të shfaqen në kodin e depozitës.
Për të shtuar një variablë në secrets, mund ta bëni këtë në cilësimet e depozitës në GitHub:
Token-in mund ta merrni në pas autorizimit përmes GitHub, për të shtuar projektin publik, mjafton të ndiqni një lidhje të tipit: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Shtojmë plugin-in 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, në çdo kërkesë tonën për tërheqje, do të hyjë boti codecov dhe do të shtojë një grafik të ndryshimit të mbulimit:
Do të shtojmë një analizues statik
Në shumicën e projekteve të mia open-source përdor sonar cloud për analizën statike të kodit, është mjaft e lehtë ta lidhësh me travis-ci. Pra, ky është një hap logjik në migrimin në GitHub Actions, të bësh të njëjtën gjë. Marketingu i aksioneve është një gjë e mirë, por këtë herë pak më ka shqetësuar, sepse me zakon e gjeta aksionin e nevojshëm dhe e shkrova në workflow. Por doli se sonar nuk mbështet punën përmes aksionit për analizën e projekteve në maven ose gradle. Natyrisht, për këtë është shkruar në dokumentacion, por kush e lexon atë?!
Përmes aksionit nuk mundemi, prandaj 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 ta shkruash në secrets. GITHUB_TOKEN — është një token i integruar, i cili gjenerohet nga GitHub, me ndihmën e tij sonarcloud[bot] do të mund të autorizohet në git për të na lënë mesazhe në kërkesat e bashkimit.
Dsonar.projectKey — emri i projektit në Sonar, mund ta shihni në cilësimet e projektit.
Dsonar.organization — emri i organizatës nga GitHub.
Krijojmë një kërkesë bashkimi dhe presim që sonarcloud[bot] të vijë në komentet:
Menaxhimi i lëshimeve
Build-in e kemi konfigurua, testet i kemi përfunduar, tani mund të bëjmë një lëshim. Le të shohim se si GitHub Actions ndihmon ndjeshëm në thjeshtimin e menaxhimit të lëshimeve.
Në punë kam projekte, ku kodi është në bitbucket (të gjitha si në atë histori «ditën shkruaj në bitbucket, natën bëj commit në GitHub»). Fatkeqësisht, në bitbucket nuk ka mjete të integruara për menaxhimin e lëshimeve. Kjo është një problem, sepse për çdo lëshim duhet të krijosh manualisht një faqe në confluence dhe të transferosh atje të gjitha karakteristikat e përfshira në lëshim, të shqyrtosh mendimet, detyrat në jira, commit-et në repository. Ka shumë mundësi për gabime, mund të harrosh diçka ose të shkruash atë që e kemi lëshuar më herët, ndonjëherë thjesht nuk është e qartë se si të kategorizosh një kërkesë bashkimi — është një tipar apo një rregullim i gabimeve, apo përmirësim testesh, apo diçka infrastrukturore.
Si GitHub actions mund të na ndihmojë? Ka një veprim të shkëlqyer — release drafter, i cili lejon të caktoni një model për skedën e shënimeve të lëshimit, për të organizuar kategoritë e pull-request-ave dhe për t'i grupuar ato automatikisht në skedën e shënimeve të lëshimit:
Shembulli i një modeli për konfigurimin e raportit (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Karakteristikat e Reja'
labels:
- 'type:features'
# në këtë kategori mbledhim të gjitha PR me etiketën type:features
- title: ' Korrigjimet e Gabimeve'
labels:
- 'type:fix'
# gjithashtu për etiketën type:fix etj.
- title: ' Dokumentacioni'
labels:
- 'type:documentation'
- title: ' Konfigurimi'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Ndryshimet
$CHANGES
Shtojmë skriptin për gjenerimin e draftit të lëshimit (.github/workflows/release-draft.yml):
name: "Krijo draft lëshimi"
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ë mblidhen automatikisht në shënimet e lëshimit — magji!
Këtu mund të lindë një pyetje: çfarë nëse zhvilluesit harrojnë të vendosin etiketat në PR? Atëherë nuk kuptohet në cilën kategori ta përfshijmë, dhe sërish do të duhet të merremi me çdo PR veç e veç. Për të zgjidhur këtë problem, mund të përdorim një veprim tjetër — verifikuesin e etiketimeve — ai kontrollon siç duken etiketat në kërkesën për tërheqje. Nëse nuk ka asnjë etiketë të detyrueshme, kontrolli do të dështojë dhe ne do ta shohim një mesazh për këtë në kërkesën tonë për tërheqje.
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'
Tani çdo kërkesë për tërheqje 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ë e përmendëm një temë si puna efektive me kërkesat për tërheqje, është e rëndësishme të flasim edhe për këtë veprim tjetër, siç është etiketuesi, ai vendos etiketat në PR në bazë të skedareve të ndryshuara. Për shembull, ne mund ta etiketojmë si [build] çdo kërkesë për tërheqje në të cilën ka ndryshime në katalogun .github/workflow.
Ta lidhësh atë është mjaft e thjeshtë:
emri: "Auto-assign themes to PR"
në:
- pull_request
punët:
triage:
vjen në: ubuntu-18.04
hapa:
- përdor: actions/labeler@v2
me:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Na nevojitet gjithashtu një skedar për përshkrimin e përputhjes së katalogëve të projektit me temat e pull-request-ave:
tema:ndërtim:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
tema:kod:
- "src/main/*"
tema:teste:
- "src/test/*"
tema:dokumentacion:
- "docs/**"
tema:MBETURINA:
- ".idea/**"
- "target/**"
Nuk arrita të lidh veprimin që automatikisht vendos etiketat në pull-request-a me veprimin që kontrollon praninë e etiketave të detyrueshme, match-label nuk do të shohë etiketat e vendosura nga boti. Duket se është më e thjeshtë të shkruaj një veprim timin që përfshin të dyja etapet. Por edhe në këtë formë është mjaft e përshtatshme, duhet të zgjidhni një etiketë nga lista gjatë krijimit të pull-request-it.
Është koha për të bërë deploy
Kam provuar disa variante për depozitim përmes GitHub Actions (përmes ssh, përmes scp, dhe me ndihmën e docker-hub), dhe mund të them se, me siguri do të gjeni një mënyrë për të ngarkuar binarët në server, pavarësisht sa i çrregullt të jetë pipeline-i juaj.
Më pëlqeu opsioni për të mbajtur gjithë infrastrukturën në një vend, prandaj le të shohim si të bëjmë deploy në GitHub Packages (ky është një repo për përmbajtje binar, npm, jar, docker).
Scripti për ndërtimin e imazhit docker dhe publikimin e tij në GitHub Packages:
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 }}"
Për të filluar, na nevojitet të mbledhim JAR-n e aplikacionit tonë, pastaj llogarisim rrugën dhe emrin e imazhit në regjistrin docker të GitHub-it. Ka disa truke këtu, me të cilat ende nuk jemi përballur:
- konstruksioni i formës: echo «::set-output name=NAME::VALUE» lejon të përcaktohet vlera e një variabli në hapin aktual, në mënyrë që më pas të mund të lexohet në të gjithë hapat e tjerë.
- për të marrë vlerën e variablit të vendosur në hapin e kaluar, mund ta bëni këtë përmes identifikuesit të këtij hapi: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Në variablën standarde GITHUB_REPOSITORY ruhet emri i regjistrit dhe pronari i tij («owner/repo-name»). Për të nxjerrë nga kjo varg gjithçka përveç emrit të regjistrit, do të përdorim sintaksën bash: ${GITHUB_REPOSITORY#*/}
Pastaj, na nevojitet të mbledhim imazhin docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Të identifikohemi në regjistrin:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Dhe të publikojmë imazhin në Repository-n e Pakove të GitHub-it:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Për të specifikuar versionin e imazhit, përdorim numrat e parë nga SHA-hashi i commit-it — GITHUB_SHA ka gjithashtu nuances, nëse do të bëni këto ndërtime jo vetëm kur bashkoni në master, por edhe në ngjarjen e krijimit të pull-request-it, atëherë SHA mund të mos përputhet me hash-in që shohim në historinë e git-it, sepse veprimi actions/checkout krijon hash-in e vet unik për të shmangur bllokimet e ndërsjella në veprimet e PR.
Nëse gjithçka ka shkuar mirë, duke hapur seksionin packages (https://github.com/antkorwin/github-actions/packages) në depo, do të shihni një imazh të ri docker:
Aty mund të shihni gjithashtu listën e versioneve të imazhit docker.
Mbete vetëm të konfigurojmë serverin tonë për të punuar me këtë registry dhe të fillojmë rinisjen e shërbimit. Si ta bëjmë këtë përmes systemd, ndoshta do ta tregoj në një herë tjetër.
Monitorimi
Le të shohim një variant të thjeshtë, si të bëjmë kontrollin e shëndetit të aplikacionit tonë përmes GitHub Actions. Në aplikacionin tonë boot, ka actuator, kështu që API për të kontrolluar gjendjen e tij as nuk ka nevojë të shkruhet, për të lenjtë është bërë gjithçka. Thjesht duhet të thërrasim host-in: 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"}
E gjithë çka na nevojitet është të shkruajmë një detyrë për verifikimin e serverit në cron, dhe nëse ndonjëherë ai nuk na përgjigjet, atëherë do të dërgojmë një njoftim në Telegram.
Së pari, le të shohim se si të aktivizojmë workflow me cron:
on:
schedule:
- cron: '*/5 * * * *'
E thjeshtë, madje nuk besoj se në GitHub mund të krijosh evenamente që nuk janë të përshtatshme për webhook. Detajet gjenden në dokumentacion:
Verifikimin e statusit të serverit do ta bëjmë manualisht me 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 "kontrolli i shëndetit ka dështuar"
exit 1
fi
echo "Është në rregull"
Së pari, ruajmë në një variabël atë që përgjigjet serveri në kërkesë, në hapin tjetër kontrollojmë nëse statusi është UP dhe, nëse nuk është kështu, dalim me një gabim. Nëse duam ta "biem" veprimin manualisht, atëherë exit 1 është arma e duhur.
- name: dërgo paralajmërim në telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Kontrolli i shëndetit të:
${{secrets.SERVER_HOST}}/api/actuator/health
dështoi me rezultatin:
${{ steps.ping.outputs.status }}
Ne dërgojmë në telegram vetëm nëse veprimi dështoi në hapin e mëparshëm. Për dërgimin e mesazhit, përdorim appleboy/telegram-action, për atë se si të merrni tokenin e botit dhe id-në e bisedës, mund të lexoni në dokumentacion:
Mos harroni të shenoni në sekretet e GitHub: URL-në për serverin dhe tokenet për botin e telegramit.
Kënga bonus — JIRA për të lenjët
Premtova se do të kthehemi te JIRA, dhe ne u kthyem. Njëqind herë kam parë në stand-up situatën, kur zhvilluesit e bënë veçorinë, përfunduan degën, por harruan të tërheqin detyrën në JIRA. Sigurisht, po të bëhej gjithçka në një vend, do të ishte më e lehtë, por në të vërtetë ne shkruajmë kodin në IDE, përfundojmë degët në bitbucket ose GitHub, ndërsa detyrat më pas i rregullojmë në Jira, për këtë duhet të hapim dritare të reja, ndonjëherë të loginohemi përsëri etj. Kur ti e di saktësisht se çfarë duhet të bësh më pas, nuk ka shumë kuptim të hapësh bordin një herë tjetër. Si rezultat, në mëngjes në stand-up duhet të shpenzojmë kohë për të azhurnuar tabelën e detyrave.
GitHub do të na ndihmojë edhe në këtë detyrë rutinë, fillimisht mund të tërheqim automatikisht detyrat në kolonën code_review, kur të kemi dërguar një kërkesë për bashkim. E gjithë që na nevojitet është të respektojmë marrëveshjen për emërtimin e degëve:
[emri i projektit]-[numri i detyrës]-titulli
për shembull, nëse çelësi i projektit "GitHub Actions" është GA, atëherë GA-8-jira-bot mund të jetë dega për realizimin e detyrës GA-8.
Integrimi me JIRA funksionon përmes veprimeve nga Atlassian, ato nuk janë perfekt, duhet të them se disa nga to nuk më kanë funksionuar fare. Por ne do të diskutojmë vetëm ato që përfundimisht funksionojnë dhe përdoren aktivisht.
Fillimisht, duhet të kaloni authentikimin në JIRA përmes veprimit: 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 }}
Për këtë duhet të merrni një token në JIRA, si të bëhet kjo është e shkruar këtu:
Ekstraktojmë identifikuesin e detyrës nga emri i degës:
- name: Gjej Problemin
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo emri i degës: $GITHUB_HEAD_REF
echo problemi i nxjerrë: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Kontrollo Problemin
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Ju lutem emëroni degën tuaj sipas problemit JIRA: [project_key]-[task_number]-branch_name"
exit 1
fi
echo ndodhi suksesesh të gjejmë problemin JIRA: ${{steps.find_issue.outputs.ISSUE_ID}}
Nëse kërkoni në tregun e GitHub, mund të gjeni një veprim për këtë detyrë, por më duhej të shkruaja të njëjtën gjë përmes grep në emrin e degës, sepse kjo veprim nga Atlassian nuk deshi të punonte në projektin tim, dhe të kuptoj se çfarë nuk shkon merr më shumë kohë sesa ta bëj manualisht.
Kjo mbetet vetëm për të kaluar detyrën në kolonën «Rishikimi i kodit» kur krijoni një kërkesë tërheqjeje:
- name: Kaloni problemin
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Rishikimi i kodit"
Për këtë ka një veprim të veçantë në GitHub, gjithçka që i nevojitet është identifikatori i problemit, i marrë në hapin e mëparshëm dhe autorizimi në JIRA, që e kemi bërë më lart.
Në të njëjtën mënyrë, mund të tërhiqni detyrat gjatë merge në master dhe në ngjarje të tjera nga GitHub workflow. Në përgjithësi, gjithçka varet nga fantazia juaj dhe dëshira për të automatizuar proceset rutinë.
Përfundimet
Nëse shikoni diagramin klasik DEVOPS, kemi mbuluar të gjitha fazat, ndoshta përveç operimit. Mendoj se, nëse përpiqemi, mund të gjejmë ndonjë veprim në tregun e aplikacioneve për integrimin me sistemin help-desk, kështu që le të themi se pipeline doli i plotë dhe, mbi bazën e përdorimit të tij, mund të nxjerrim përfundime.
Avantazhet:
- Tregu i aplikacioneve me veprime të gatshme për çdo rast është shumë i shkëlqyer. Në shumicën e tyre, gjithashtu mund të shikoni burimet për të kuptuar si të zgjidhni një detyrë të ngjashme ose të postoni një kërkesë veçorie tek autori drejtpërdrejt në repozitorin e GitHub.
- Zgjedhja e platformës së synuar për ndërtimin: Linux, macOS, Windows është një veçori mjaft interesante.
- GitHub Packages është një gjë e shkëlqyer; mbajtja e gjithë infrastrukturës në një vend është e përshtatshme, nuk nevojitet të kërkoni nëpër okat e ndryshme, gjithçka është brenda një ose dy klikimeve të mausit dhe është integuruar mrekullisht me GitHub Actions. Mbështetje për docker registry në versionin falas është gjithashtu një avantazh i mirë.
- GitHub fsheh sekrete në log-et e ndërtimit, prandaj përdorimi i tij për ruajtjen e fjalëkalimeve dhe tokenëve nuk është kaq i frikshëm. Gjatë të gjithë eksperimenteve, nuk më ka ndodhur asnjëherë të shoh një sekret në formë të pastër në konsolë.
- I lirë për projektet Open Source
Disavantazhet:
- YML, nuk e pëlqej. Kur punoj me një fluks të tillë, mesazhi më i shpeshtë i commit-it është "fix yml format", ose harroj të vendos një tab, ose shkruaj në rreshtin e gabuar. Në përgjithësi, të qëndrosh përpara ekranit me transport e linjë nuk është një aktivitet shumë i këndshëm.
- DEBUG, të debug-osh fluksin me commit-e, duke e nisur ndërtesën dhe duke e output-uar në konsolë nuk është gjithmonë e lehtë, por kjo është më shumë si "ju jeni bërë të kërkoni komoditet", jeni mësuar të punoni me IDEA të rehatshme, kur mund të debug-on çdo gjë.
- Mund të shkruani veprimin tuaj në çfarëdo gjuhe nëse e vendosni në docker, por natyrisht mbështetet vetëm javascript, sigurisht që është çështje shije, por do të preferoja diçka tjetër në vend të js.
Më kujtohet se repozitori me të gjitha skriptet është këtu:
Javaj në javën e ardhshme do të bëj një në konferencën Heisenbug 2020 Piter. Do të flas jo vetëm për mënyrat për të shmangur gabimet gjatë përgatitjes së të dhënave testuese, por gjithashtu do të ndaj sekretet e mia të punës me grumbujt e të dhënave në aplikacionet Java!
Burimi: habr.com
