Gyakran kell csővezetéket építenem Java-projektek építéséhez. Néha nyílt forráskódú, néha nem. Nemrég úgy döntöttem, hogy megpróbálok áthelyezni néhány adattárat a Travis-CI-ről és a TeamCity-ről a GitHub Actions-re, és ez jött ki belőle.
Mit fogunk automatizálni?
Először is szükségünk van egy projektre, amelyet automatizálunk, készítsünk egy kis alkalmazást Spring boot / Java 11 / Maven alatt. Ebben a cikkben egyáltalán nem fogunk érdekelni az alkalmazás logikája, fontos számunkra az alkalmazás körüli infrastruktúra, így egy egyszerű REST API vezérlő is elegendő számunkra.
A forrásokat itt tudod megnézni: A csővezeték építésének minden szakasza megjelenik a projekt lehívási kérelmeiben.
JIRA és tervezés
Érdemes elmondani, hogy általában a JIRA-t használjuk hibakövetőként, ezért hozzunk létre egy külön táblát ehhez a projekthez, és adjuk hozzá az első problémákat:
Kicsit később visszatérünk arra, hogy milyen érdekességeket tud nyújtani a JIRA és a GitHub együtt.
Automatizáljuk a projekt összeszerelését
Tesztprojektünk maven-en keresztül épül fel, így az elkészítése meglehetősen egyszerű, csak az mvn clean csomagra van szükségünk.
Ehhez a Github Actions segítségével létre kell hoznunk egy fájlt a repository-ban, amely leírja a munkafolyamatunkat, ezt egy normál yml fájllal megtehetjük, nem mondhatom, hogy szeretem az „yml programozást”, de mit tehetünk? ezt a .github/ directory workflow/ build.yml fájlban végezzük, amelyben leírjuk a fő ág felépítésének műveleteit:
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 — ez annak az eseménynek a leírása, amelyen a forgatókönyvünk elindul.
on: pull_request/push — azt jelzi, hogy ezt a munkafolyamatot minden alkalommal el kell indítani, amikor leküldésre kerül a mester, és lehívási kérések jönnek létre.
Az alábbiakban a feladatok leírása található (munkahelyek) és végrehajtási lépések (lépések) minden feladathoz.
ráfutás - itt választhatjuk ki a cél operációs rendszert, meglepő módon akár Mac OS-t is választhatunk, de a privát tárolókban ez elég drága (a Linuxhoz képest).
használ lehetővé teszi más műveletek újrafelhasználását, például az Actions/setup-java művelettel telepítjük a Java 11 környezetét.
Révén val vel megadhatjuk azokat a paramétereket, amelyekkel elindítjuk a műveletet, lényegében ezek azok az argumentumok, amelyek átadódnak a műveletnek.
Már csak a projektfelépítést kell futtatni a Mavenben: run: mvn -B clean package zászló -B azt mondja, hogy szükségünk van egy nem interaktív módra, hogy a maven hirtelen ne akarjon kérdezni tőlünk valamit
Nagy! Most minden alkalommal, amikor elkötelezi magát a mester mellett, elkezdődik a projekt felépítése.
A tesztindítások automatizálása
Az összeszerelés jó, de a valóságban egy projektet biztonságosan össze lehet szerelni, de nem működik. Ezért a következő lépés a tesztfutások automatizálása. Ezen túlmenően, PR-ellenőrzés során nagyon kényelmes megnézni a tesztek sikeres teljesítésének eredményeit - biztosan tudja, hogy a tesztek sikeresek, és senki sem felejtette el futtatni az ágát az összevonás előtt.
Lehívási kérés létrehozásakor teszteket fogunk futtatni és beolvadunk a masterbe, és ezzel egyidejűleg hozzáadjuk a kódlefedettségről szóló jelentés elkészítését.
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 }}
A tesztek lefedésére a codecov-ot használom a jacoco beépülő modullal együtt. A codecov saját művelettel rendelkezik, de szüksége van egy tokenre, hogy működjön a lehívási kérésünkkel:
${{ secrets.CODECOV_TOKEN }} — ezt a konstrukciót nem egyszer látni fogjuk, a secrets a titkok tárolásának mechanizmusa a GitHubban, oda írhatunk jelszavakat/tokeneket/hostokat/url-eket és egyéb olyan adatokat, amelyeket nem szabad beletenni a repository kódbázisba.
Változót adhat hozzá a titkokhoz a GitHub adattárbeállításaiban:
A címen kaphat tokent A GitHubon keresztüli engedélyezés után nyilvános projekt hozzáadásához csak egy ehhez hasonló linket kell követnie: /[repo neve]. Privát adattár is hozzáadható; ehhez codecov jogokat kell adni az alkalmazáshoz a Githubban.
Adja hozzá a jacoco beépülő modult a POM fájlhoz:
<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>
Most a codecov bot beírja az összes lekérési kérésünket, és hozzáad egy lefedettségi változási grafikont:
Adjunk hozzá egy statikus analizátort
A legtöbb nyílt forráskódú projektemben szonárfelhőt használok statikus kódelemzésre, elég könnyű csatlakozni a travis-ci-hez. Tehát logikus lépés, amikor áttér a GitHub Actions szolgáltatásra, hogy ugyanezt tegye. Az akciópiac klassz dolog, de ezúttal egy kicsit cserbenhagyott, mert megszokásból megtaláltam a szükséges akciót, és hozzáadtam a munkafolyamathoz. De kiderült, hogy a szonár nem támogatja a projektek elemzését a mavenen vagy a gradle-n. Persze ez le van írva a dokumentációban, de ki olvassa el?!
Ez nem lehetséges művelettel, ezért az mvn beépülő modulon keresztül tesszük meg:
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 - átvehető a címen és titokban kell regisztrálnia. GITHUB_TOKEN - ez egy beépített token, amit a GitHub generál, aminek segítségével a sonarcloud[bot] be tud majd jelentkezni a Gitbe, hogy lehívási kérésben üzeneteket hagyhasson nekünk.
Dsonar.projectKey — a projekt neve a szonárban, ezt a projektbeállításokban láthatja.
Dsonar.szervezet — a szervezet neve a GitHubból.
Lehívási kérelmet nyújtunk be, és várjuk, hogy a sonarcloud[bot] megérkezzen a megjegyzésekben:
Release menedzsment
A build konfigurálva, a tesztek lefutottak, és kiadhatjuk a kiadást. Nézzük meg, hogyan könnyítheti meg a GitHub Actions a kiadáskezelést.
A munkahelyemen vannak olyan projektjeim, amelyek kódbázisa bitbucketben van (minden úgy van, mint abban a történetben: „Nappal bitbucket-nek írok, éjjel a GitHub-ra kötelezem el magát”). Sajnos a bitbucket nem rendelkezik beépített kiadáskezelő eszközökkel. Ez azért baj, mert minden kiadáshoz manuálisan kell összefolyni egy oldalt, és oda kell dobni a kiadásban szereplő összes funkciót, keresgélni az elme palotáiban, jira-ban feladatok, a repository-ban commitok. Sok esély van a hibázásra, elfelejthetsz valamit, vagy beírhatsz olyat, ami már a múltkor megjelent, néha egyszerűen nem világos, hogy minek minősítsd a lehívási kérelmet - ez funkció vagy hibajavítás, vagy tesztek szerkesztése, ill. valami infrastrukturális .
Hogyan segíthetnek nekünk a GitHub-műveletek? Van egy nagyszerű akció – kiadási tervezet, amely lehetővé teszi egy kiadási megjegyzések fájlsablon beállítását a lekérési kérelmek kategóriáinak beállításához, és automatikusan csoportosítja azokat a kiadási megjegyzések fájljában:
Példa sablon jelentés beállításához (.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
Adjon hozzá egy szkriptet a kiadásvázlat létrehozásához (.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 }}
Ezentúl minden lehívási kérelmet automatikusan a kiadási megjegyzésekbe gyűjtünk – varázslat!
Itt felmerülhet a kérdés: mi van, ha a fejlesztők elfelejtenek címkéket tenni a PR-ba? Ezután nem világos, hogy melyik kategóriába helyezze, és megint kézzel kell kezelni, minden PR-vel külön-külön. A probléma megoldásához használhatunk egy másik műveletet - a címkeellenőrzőt -, amely ellenőrzi a címkék jelenlétét a lekérési kérelemben. Ha nincsenek szükséges címkék, akkor az ellenőrzés sikertelen lesz, és erről üzenetet fogunk látni a lehívási kérésünkben.
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'
Most minden lehívási kérelmet meg kell jelölni a következő címkék egyikével: type:fix, type:features, type:documentation, type:tests, type:config.
A lekérési kérések automatikus annotációja
Mivel olyan témát érintettünk, mint a hatékony munka a pull kérésekkel, ezért érdemes beszélni egy olyan műveletről, mint a labeler, amely a fájlok módosítása alapján helyez el címkéket a PR-be. Például megjelölhetünk [build]-ként minden olyan lekérést, amely a könyvtár módosításait tartalmazza .github/workflow.
A csatlakoztatás nagyon egyszerű:
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 }}
Szükségünk van egy fájlra is, amely leírja a projektkönyvtárak és a lekérési témakörök közötti megfelelést:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nem sikerült párosítanom azt a műveletet, amely automatikusan elhelyezi a címkéket a lekérési kérésekben, azzal a művelettel, amely ellenőrzi a szükséges címkék meglétét; a match-label nem akarja látni a bot által hozzáadott címkéket. Könnyebbnek tűnik saját cselekvést írni, amely mindkét szakaszt ötvözi. De még ebben a formában is nagyon kényelmes a használata; a lehívási kérelem létrehozásakor ki kell választania egy címkét a listából.
Ideje bevetni
Kipróbáltam több telepítési lehetőséget a GitHub Actions segítségével (ssh-n, scp-n keresztül és docker-hub használatával), és elmondhatom, hogy valószínűleg megtalálja a módját a bináris feltöltésének a szerverre, függetlenül attól, hogy milyen görbe a folyamat. van.
Tetszett a lehetőség, hogy a teljes infrastruktúrát egy helyen tartom, ezért nézzük meg, hogyan telepíthetem a GitHub-csomagokat (ez a bináris tartalom, npm, jar, docker tárolója).
Szkript egy docker-kép létrehozásához és GitHub-csomagokban való közzétételéhez:
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 }}"
Először is fel kell építenünk az alkalmazásunk JAR fájlját, ami után kiszámítjuk a GitHub docker registry elérési útját és a képünk nevét. Van itt néhány trükk, amivel még nem találkoztunk:
- egy olyan konstrukció, mint: echo „::set-output name=NAME::VALUE” lehetővé teszi egy változó értékének beállítását az aktuális lépésben, így az az összes többi lépésben olvasható lesz.
- az előző lépésben beállított változó értékét ennek a lépésnek az azonosítóján keresztül kaphatja meg: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- A szabványos GITHUB_REPOSITORY változó tárolja a lerakat nevét és tulajdonosát („owner/repo-name”). Annak érdekében, hogy ebből a sorból mindent kivágjunk, kivéve a tárhely nevét, a bash szintaxist használjuk: ${GITHUB_REPOSITORY#*/}
Ezután létre kell hoznunk a docker képet:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Jelentkezzen be a rendszerleíró adatbázisba:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
És tegye közzé a képet a GitHub Packages Repository-ban:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
A kép verziójának jelzésére a véglegesítés SHA hash-jének első számjegyeit használjuk - GITHUB_SHA itt is vannak árnyalatok, ha nem csak a masterbe egyesítve készít ilyen buildeket, hanem a pull kérelem létrehozása szerint is. esemény, akkor előfordulhat, hogy az SHA nem egyezik a git-előzményekben látható hash-sel, mert a műveletek/kijelentkezési műveletek saját egyedi hash-t készítenek, hogy elkerüljék a holtpontos műveleteket a PR-ban.
Ha minden jól sikerült, akkor a csomagok szakaszt (https://github.com/antkorwin/github-actions/packages) megnyitva a tárolóban egy új docker-kép jelenik meg:
Itt megtekintheti a docker kép verzióinak listáját is.
Már csak be kell állítani a szerverünket, hogy működjön együtt ezzel a beállításjegyzékkel, és újraindítsa a szolgáltatást. Valószínűleg egy másik alkalommal fogok beszélni arról, hogyan kell ezt megtenni a systemd-n keresztül.
megfigyelés
Nézzünk meg egy egyszerű lehetőséget arra vonatkozóan, hogyan ellenőrizzük az alkalmazásunk állapotát a GitHub Actions segítségével. A rendszerindító alkalmazásunknak van egy aktuátora, így még API-t sem kell írnunk az állapotának ellenőrzéséhez, már mindent megtettünk a lustákért. Csak ki kell húznia a gazdagépet: 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"}
Csak egy feladatot kell írnunk a szerver ellenőrzésére a cron segítségével, és ha hirtelen nem válaszol, akkor táviratban értesítjük.
Először is nézzük meg, hogyan kell futtatni egy cron munkafolyamatot:
on:
schedule:
- cron: '*/5 * * * *'
Egyszerű, el sem hiszem, hogy a Githubban olyan eseményeket lehet létrehozni, amik egyáltalán nem férnek bele a webhookokba. Részletek a dokumentációban:
Ellenőrizzük a szerver állapotát manuálisan a curl segítségével:
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"
Először elmentjük egy változóba, amit a szerver válaszolt a kérésre, a következő lépésben ellenőrizzük, hogy az állapot FEL van-e, és ha nem így van, akkor hibával kilépünk. Ha egy akciót a kezével kell „elborítani”, akkor 1. kijárat - megfelelő fegyver.
- 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 }}
Csak akkor küldünk táviratba, ha a művelet az előző lépésben sikertelen volt. Üzenetküldéshez appleboy/telegram-actiont használunk; a bot token és chat azonosító beszerzéséről a dokumentációban olvashat:
Ne felejtse el beírni a titkokat a Githubon: URL a szerverhez és tokenek a távirat-bothoz.
Bónusz szám - JIRA lustáknak
Megígértem, hogy visszatérünk a JIRA-ba, és visszatértünk. Több százszor figyeltem meg olyan helyzetet a stand-upoknál, amikor a fejlesztők létrehoztak egy funkciót, egyesítettek egy ágat, de elfelejtették behúzni a problémát a JIRA-ba. Persze ha mindez egy helyen történne, egyszerűbb lenne, de valójában az IDE-ben írunk kódot, egyesítjük az ágakat bitbucketbe vagy GitHubba, majd a Jira-ba húzzuk a feladatokat, ehhez új ablakokat kell nyitni. , néha jelentkezz be újra stb. Ha tökéletesen emlékszel arra, hogy mit kell tenned, akkor nincs értelme újra kinyitni a táblát. Ennek eredményeként reggel egy standupnál időt kell töltenie a feladattábla frissítésével.
A GitHub ebben a rutinfeladatban is segítségünkre lesz; először is a problémákat automatikusan behúzhatjuk a code_review oszlopba, amikor lekérési kérelmet küldünk. Mindössze annyit kell tennie, hogy kövesse az ág elnevezési konvenciót:
[имя проекта]-[номер таска]-название
Ha például a „GitHub Actions” projektkulcs GA, akkor GA-8-jira-bot ág lehet a GA-8 feladat megvalósításához.
A JIRA-val való integráció Atlassian akciókon keresztül működik, ezek nem tökéletesek, azt kell mondanom, hogy némelyik egyáltalán nem működött nekem. De csak azokat tárgyaljuk, amelyek biztosan működnek és aktívan használják.
Először be kell jelentkeznie a JIRA-ba a következő művelettel: 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 }}
Ehhez be kell szereznie egy tokent a JIRA-ban, ennek módja itt található:
Kivonjuk a feladatazonosítót az ág nevéből:
- 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}}
Ha a GitHub piactéren keresel, találsz egy műveletet ehhez a feladathoz, de ugyanezt a grep segítségével kellett leírnom az ág nevével, mert ez az Atlassian művelet semmilyen módon nem akart működni a projektemen , hogy rájöjjön, mi volt ott a hiba – hosszabb ideig, mint ugyanazt a kézzel csinálni.
Már csak át kell helyezni a feladatot a „Kódellenőrzés” oszlopba lekérési kérelem létrehozásakor:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Erre van egy speciális művelet a GitHubon, ehhez csak az előző lépésben kapott problémaazonosítóra és a fent megtett JIRA-beli engedélyezésre van szüksége.
Ugyanígy húzhat át feladatokat a főbevonatba, és más eseményeket a GitHub-munkafolyamatból. Általában minden a képzeletétől és a rutinfolyamatok automatizálásának vágyától függ.
Álláspontja
Ha megnézzük a klasszikus DEVOPS diagramot, minden szakaszt lefedtünk, kivéve talán a működést, úgy gondolom, ha megpróbálja, találhat valamit a piacon a help-desk rendszerrel való integrációhoz, ezért feltételezzük, hogy a csővezeték megfordult. alaposnak kell lennie, és felhasználása alapján következtetéseket lehet levonni.
Előnyök:
- Piactér kész akciókkal minden alkalomra, ez nagyon klassz. A legtöbb esetben megnézheti a forráskódot is, hogy megértse, hogyan lehet megoldani egy hasonló problémát, vagy közvetlenül a GitHub-tárhelyen küldhet el egy szolgáltatáskérést a szerzőnek.
- Az összeállítás célplatformjának kiválasztása: Linux, mac os, Windows elég érdekes szolgáltatás.
- A Github Packages nagyszerű dolog, kényelmes egy helyen tartani a teljes infrastruktúrát, nem kell különböző ablakokon keresztül böngészni, minden egy-két egérkattintás körzetében van, és tökéletesen integrálható a GitHub Actions-szel. A Docker rendszerleíró adatbázis támogatása az ingyenes verzióban szintén jó előny.
- A GitHub titkokat rejteget az összeállítási naplókban, így használata jelszavak és tokenek tárolására nem olyan ijesztő. Minden kísérletem során soha nem láttam a titkot tiszta formájában a konzolban.
- Ingyenes nyílt forráskódú projektekhez
Hátrányok:
- YML, hát nem szeretem őt. Amikor ilyen folyamattal dolgozom, a legáltalánosabb commit üzenetem a „fix yml format”, akkor elfelejti betenni valahova egy tabulátort, vagy rossz sorba írja. Általában a képernyő előtt szögmérővel és vonalzóval ülni nem a legkellemesebb élmény.
- DEBUG, a folyamat hibakeresése véglegesítésekkel, az újraépítés futtatása és a konzolra való kimenet nem mindig kényelmes, de ez inkább a „túlzásba vitted” kategória; megszoktad, hogy kényelmes IDEA-val dolgozhatsz, amikor bármit hibakereshetsz. .
- Bármire ráírhatod az akciódat, ha Dockerbe csomagolod, de natívan csak a javascript támogatott, ez persze ízlés dolga, de én inkább mást választanék a js helyett.
Hadd emlékeztesselek arra, hogy az összes szkriptet tartalmazó tároló itt található:
Jövő héten együtt fogok fellépni a Heisenbug 2020 Piter konferencián. Nemcsak azt mondom el, hogyan kerülje el a hibákat a tesztadatok elkészítésekor, hanem megosztom a Java alkalmazások adatkészleteivel való munka titkaimat is!
Forrás: will.com