Ég þarf oft að byggja leiðslu fyrir byggingarverkefni í Java. Stundum er það opinn uppspretta, stundum ekki. Ég ákvað nýlega að prófa að færa nokkrar af geymslum mínum frá Travis-CI og TeamCity til GitHub Actions, og þetta er það sem kom út úr því.
Hvað munum við gera sjálfvirkan?
Fyrst þurfum við verkefni sem við munum gera sjálfvirkan, við skulum búa til lítið forrit í Spring boot / Java 11 / Maven. Í tilgangi þessarar greinar munum við alls ekki hafa áhuga á rökfræði forritsins; innviðirnir í kringum forritið eru mikilvægir fyrir okkur, svo einfaldur REST API stjórnandi mun nægja okkur.
Hægt er að skoða heimildirnar hér: Öll stig við að byggja upp leiðslu endurspeglast í dráttarbeiðnum fyrir þetta verkefni.
JIRA og skipulagning
Það er þess virði að taka það fram að við notum JIRA venjulega sem málafylkingu, svo við skulum búa til sérstaka stjórn fyrir þetta verkefni og bæta við fyrstu málunum þar:
Nokkru síðar munum við snúa aftur að því hvað JIRA og GitHub geta boðið upp á í sameiningu.
Við gerum sjálfvirkan samsetningu verkefnisins
Prófunarverkefnið okkar er byggt í gegnum maven, svo það er frekar einfalt að byggja það, allt sem við þurfum er mvn hreinn pakki.
Til að gera þetta með því að nota Github Actions þurfum við að búa til skrá í geymslunni sem lýsir vinnuflæðinu okkar, þetta er hægt að gera með venjulegri yml skrá, ég get ekki sagt að mér líki “yml forritun”, en hvað getum við gert - við gerum það í .github/ directory workflow/ skrá build.yml þar sem við munum lýsa aðgerðum þegar búið er að byggja aðalgreinina:
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 — þetta er lýsing á atburðinum sem handritið okkar verður sett á.
á: pull_request/push — gefur til kynna að þetta verkflæði þurfi að ræsa í hvert sinn sem ýtt er á meistarann og dráttarbeiðnir eru búnar til.
Eftirfarandi er lýsing á verkefnum (störf) og framkvæmdarskref (skref) fyrir hvert verkefni.
keyrir áfram - hér getum við valið mark OS, furðu, þú getur jafnvel valið Mac OS, en á einkageymslum er þetta frekar dýrt (miðað við Linux).
notar gerir þér kleift að endurnýta aðrar aðgerðir, til dæmis með því að nota actions/setup-java aðgerðina sem við setjum upp umhverfið fyrir Java 11.
Með með við getum tilgreint færibreyturnar sem við ræsum aðgerðina með, í meginatriðum eru þetta rökin sem verða send til aðgerðarinnar.
Allt sem er eftir er að keyra verkefnisbygginguna með Maven: run: mvn -B clean package fána -B segir að við þurfum ekki gagnvirkan hátt svo að maven vilji skyndilega ekki spyrja okkur að einhverju
Frábært! Nú, í hvert skipti sem þú skuldbindur þig til meistarans, byrjar verkefnisgerðin.
Gerir sjálfvirkan prófun
Samsetning er góð, en í raun er hægt að setja saman verkefni á öruggan hátt, en ekki vinna. Þess vegna er næsta skref að gera prófunarkeyrslur sjálfvirkar. Að auki er nokkuð þægilegt að skoða niðurstöður þess að standast prófin þegar þú gerir PR-endurskoðun - þú veist fyrir víst að prófin standast og enginn gleymdi að reka útibúið sitt áður en þú sameinaðir.
Við munum keyra próf þegar þú býrð til dráttarbeiðni og sameinast í master, og á sama tíma munum við bæta við gerð skýrslu um kóðaþekju.
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 }}
Til að ná yfir próf nota ég codecov í tengslum við jacoco viðbótina. codecov hefur sína eigin aðgerð, en það þarf tákn til að vinna með pull beiðni okkar:
${{ secrets.CODECOV_TOKEN }} — við munum sjá þessa byggingu oftar en einu sinni, leyndarmál er vélbúnaður til að geyma leyndarmál í GitHub, við getum skrifað þar lykilorð/tákn/hýsingar/slóðir og önnur gögn sem ættu ekki að vera með í geymslukóðagrunninum.
Þú getur bætt breytu við leyndarmál í geymslustillingunum á GitHub:
Hægt er að fá tákn kl Eftir heimild í gegnum GitHub, til að bæta við opinberu verkefni þarftu bara að fylgja hlekk eins og þessum: /[nafn söluaðila]. Einnig er hægt að bæta við einkageymsla; til að gera þetta þarftu að gefa forritinu codecov réttindi í Github.
Bættu jacoco viðbótinni við POM skrána:
<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>
Nú mun codecov botinn slá inn hverja afdráttarbeiðni okkar og bæta við grafi fyrir breytingu á umfangi:
Við skulum bæta við kyrrstöðugreiningartæki
Í flestum opnum verkefnum mínum nota ég sónarský fyrir kyrrstöðugreiningu, það er frekar auðvelt að tengjast travis-ci. Svo það er rökrétt skref þegar þú flytur yfir í GitHub Actions að gera það sama. Aðgerðamarkaðurinn er flottur hlutur, en í þetta skiptið sló hann mig aðeins niður, því af vana fann ég aðgerðina sem ég þurfti og bætti því við verkflæðið. En það kom í ljós að sonar styður ekki að vinna í gegnum aðgerð til að greina verkefni á Maven eða Gradle. Auðvitað er þetta skrifað í skjölin, en hver les það?!
Það er ekki mögulegt með aðgerð, svo við gerum það í gegnum mvn viðbótina:
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 - hægt að nálgast á og þú þarft að skrá það í leyndarmálum. GITHUB_TOKEN - þetta er innbyggt tákn sem GitHub býr til, með hjálp þess mun sonarcloud[bot] geta skráð sig inn á Git til að skilja eftir okkur skilaboð í pull-beiðnum.
Dsonar.projectKey — heiti verkefnisins í sónarnum, þú getur séð það í verkefnastillingunum.
Dsonar.stofnun - nafn stofnunarinnar frá GitHub.
Við gerum beiðni um aðdrátt og bíðum eftir að sonarcloud[bot] komi í athugasemdum:
Sleppistjórnun
Byggingin hefur verið stillt, prófin hafa verið keyrð og við getum gert útgáfu. Við skulum skoða hvernig GitHub Actions getur gert útgáfustjórnun mun auðveldari.
Í vinnunni er ég með verkefni þar sem kóðagrunnurinn er í bitbucket (allt er eins og í þeirri sögu „Ég skrifa á bitbucket á daginn, skuldbinda mig til GitHub á kvöldin“). Því miður er bitbucket ekki með innbyggt útgáfustjórnunartæki. Þetta er vandamál vegna þess að fyrir hverja útgáfu þarftu að búa til síðu í samruna handvirkt og henda öllum eiginleikum útgáfunnar þangað, leita í gegnum hallir hugans, verkefni í jira, skuldbinda sig í geymslunni. Það eru mörg tækifæri til að gera mistök, þú getur gleymt einhverju eða slegið inn eitthvað sem þegar var gefið út síðast, stundum er einfaldlega ekki ljóst hvað á að flokka pull request sem - er það eiginleiki eða villuleiðrétting, eða klippipróf, eða eitthvað innviðafræðilegt.
Hvernig geta GitHub aðgerðir hjálpað okkur? Það er frábær aðgerð - útgáfuuppkast, það gerir þér kleift að stilla sniðmát fyrir útgáfuskýrsluskrár til að setja upp flokka útdráttarbeiðna og flokka þær sjálfkrafa í útgáfuskýrsluskrána:
Dæmi um sniðmát til að setja upp skýrslu (.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
Bættu við skriftu til að búa til drög að útgáfu (.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 }}
Öllum dráttarbeiðnum héðan í frá verður safnað sjálfkrafa í útgáfunótur - galdur!
Hér gæti spurningin vaknað: hvað ef verktaki gleymir að setja merki í PR? Þá er ekki ljóst í hvaða flokk á að setja það og aftur verður þú að takast á við það handvirkt, með hvern PR fyrir sig. Til að laga þetta vandamál getum við notað aðra aðgerð - merki sannprófandi - hún athugar hvort merki séu til staðar á dragbeiðninni. Ef það eru engin áskilin merki, þá mun athugunin mistakast og við munum sjá skilaboð um þetta í dráttarbeiðni okkar.
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'
Nú þarf að merkja allar dráttarbeiðnir með einu af merkjunum: type:fix, type:features, type:documentation, type:tests, type:config.
Sjálfvirk skýring á dráttarbeiðnum
Þar sem við snertum svo efni eins og árangursríka vinnu með dráttarbeiðnum, er þess virði að tala um slíka aðgerð eins og merkimiða, það setur merki í PR byggt á því hvaða skrám hefur verið breytt. Til dæmis getum við merkt sem [byggja] hvaða dráttarbeiðni sem er sem inniheldur breytingar á skránni .github/workflow.
Að tengja það er frekar einfalt:
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 }}
Okkur vantar líka skrá sem lýsir samsvörun milli verkefnaskránna og efnisþátta um dráttarbeiðni:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Mér tókst ekki að para aðgerðina sem setur merki sjálfkrafa í dráttarbeiðnir við aðgerðina sem athugar hvort tilskilin merki séu til staðar; match-label vill ekki sjá merkimiðana sem botninn hefur bætt við. Það virðist auðveldara að skrifa eigin aðgerð sem sameinar bæði stigin. En jafnvel í þessu formi er það nokkuð þægilegt í notkun; þú þarft að velja merkimiða af listanum þegar þú býrð til dráttarbeiðni.
Það er kominn tími til að dreifa
Ég prófaði nokkra dreifingarvalkosti í gegnum GitHub Actions (í gegnum ssh, í gegnum scp og með því að nota docker-hub), og ég get sagt að líklega muntu finna leið til að hlaða upp tvöfaldanum á netþjóninn, sama hversu skakkt leiðslan þín er er.
Mér líkaði við möguleikann á að halda öllu innviði á einum stað, svo við skulum skoða hvernig á að dreifa á GitHub pakka (þetta er geymsla fyrir tvöfaldur efni, npm, jar, docker).
Forskrift til að byggja upp bryggjumynd og birta hana í GitHub pakka:
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 }}"
Í fyrsta lagi þurfum við að búa til JAR skrána af forritinu okkar, eftir það reiknum við út slóðina að GitHub docker registry og nafn myndarinnar okkar. Það eru nokkur brellur hér sem við höfum ekki rekist á ennþá:
- smíði eins og: echo “::set-output name=NAME::VALUE” gerir þér kleift að stilla gildi breytu í núverandi skrefi, þannig að hægt sé að lesa hana í öllum öðrum skrefum.
- þú getur fengið gildi breytunnar í fyrra skrefi í gegnum auðkenni þessa skrefs: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Staðlaða GITHUB_REPOSITORY breytan geymir nafn geymslunnar og eiganda hennar („eigandi/repo-nafn“). Til að klippa allt úr þessari línu nema nafnið á geymslunni, munum við nota bash setningafræði: ${GITHUB_REPOSITORY#*/}
Næst þurfum við að smíða Docker myndina:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Skráðu þig inn á skrána:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Og birtu myndina í GitHub pakkageymslunni:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Til að gefa til kynna útgáfu myndarinnar notum við fyrstu tölustafina úr SHA kjötkássa skuldbindingarinnar - GITHUB_SHA það eru líka blæbrigði hér, ef þú gerir slíkar byggingar ekki aðeins þegar sameinast í master, heldur einnig í samræmi við sköpunarbeiðnina atburður, þá gæti SHA ekki passað við kjötkássa sem við sjáum í git sögunni, vegna þess að aðgerðirnar/útskráningaraðgerðin býr til sína eigin einstöku kjötkássa til að koma í veg fyrir stöðvunaraðgerðir í PR.
Ef allt gekk vel, opnaðu pakkahlutann (https://github.com/antkorwin/github-actions/packages) í geymslunni, þú munt sjá nýja bryggjumynd:
Þar geturðu líka séð lista yfir útgáfur af Docker myndinni.
Allt sem er eftir er að stilla netþjóninn okkar til að vinna með þessa skrásetningu og endurræsa þjónustuna. Ég mun líklega tala um hvernig á að gera þetta í gegnum systemd annan tíma.
Eftirlit
Við skulum skoða einfaldan valkost um hvernig á að gera heilsufarsskoðun fyrir forritið okkar með því að nota GitHub Actions. Stígvélaforritið okkar er með stýribúnaði, svo við þurfum ekki einu sinni að skrifa API til að athuga stöðu þess; við höfum nú þegar gert allt fyrir lata. Þú þarft bara að draga gestgjafann: 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"}
Allt sem við þurfum er að skrifa verkefni til að athuga netþjóninn með cron, og ef skyndilega svarar það okkur ekki, þá munum við senda tilkynningu með símskeyti.
Fyrst skulum við reikna út hvernig á að keyra cron verkflæði:
on:
schedule:
- cron: '*/5 * * * *'
Það er einfalt, ég get ekki einu sinni trúað því að í Github sé hægt að búa til viðburði sem passa alls ekki inn í webhooks. Upplýsingar eru í skjölunum:
Við skulum athuga stöðu netþjónsins handvirkt 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 "health check is failed"
exit 1
fi
echo "It's OK"
Í fyrsta lagi vistum við í breytu það sem þjónninn svaraði beiðninni, í næsta skrefi athugum við hvort staðan sé UPP og ef svo er ekki þá sleppum við með villu. Ef þú þarft að „yfirgnæfa“ aðgerð með höndunum, þá útgönguleið 1 - viðeigandi vopn.
- 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 }}
Við sendum í símskeyti aðeins ef aðgerðin mistókst í fyrra skrefi. Til að senda skilaboð notum við appleboy/telegram-action; þú getur lesið um hvernig á að fá botnalykil og spjallauðkenni í skjölunum:
Ekki gleyma að skrifa í leyndarmálin á Github: URL fyrir netþjóninn og tákn fyrir símskeyti bot.
Bónus lag - JIRA fyrir lata
Ég lofaði að við myndum snúa aftur til JIRA og við erum komin aftur. Hundruð sinnum hef ég fylgst með aðstæðum í uppistandi þegar forritarar bjuggu til eiginleika, sameinuðu útibú, en gleymdu að draga málið inn í JIRA. Auðvitað, ef allt þetta væri gert á einum stað, væri það auðveldara, en í raun skrifum við kóða í IDE, sameinum greinar í bitbucket eða GitHub og drögum svo verkefnin inn í Jira, til þess þurfum við að opna nýja glugga , stundum skrá þig inn aftur og o.s.frv. Þegar þú manst fullkomlega hvað þú þarft að gera næst, þá þýðir ekkert að opna töfluna aftur. Þar af leiðandi þarftu að eyða tíma í að uppfæra verkefnaborðið á morgnana í standup.
GitHub mun einnig hjálpa okkur í þessu venjubundnu verkefni; til að byrja með getum við dregið mál sjálfkrafa inn í code_review dálkinn þegar við sendum inn beiðni um drátt. Allt sem þú þarft að gera er að fylgja nafnareglunni fyrir útibú:
[имя проекта]-[номер таска]-название
til dæmis, ef verkefnislykillinn „GitHub Actions“ er GA, þá GA-8-jira-bot gæti verið útibú til að innleiða GA-8 verkefnið.
Samþætting við JIRA virkar með aðgerðum frá Atlassian, þær eru ekki fullkomnar, ég verð að segja að sumar þeirra virkuðu alls ekki fyrir mig. En við munum aðeins ræða þá sem örugglega virka og eru virkir notaðir.
Fyrst þarftu að skrá þig inn á JIRA með aðgerðinni: 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 }}
Til að gera þetta þarftu að fá tákn í JIRA, hvernig á að gera þetta er lýst hér:
Við tökum út verkefnaauðkennið úr heiti útibúsins:
- 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}}
Ef þú leitar á GitHub markaðstorginu geturðu fundið aðgerð fyrir þetta verkefni, en ég þurfti að skrifa það sama með því að nota grep með því að nota nafn útibúsins, vegna þess að þessi aðgerð frá Atlassian vildi ekki vinna verkefnið mitt á nokkurn hátt , til að komast að því hvað var að þarna - lengur en að gera það sama með höndunum.
Allt sem er eftir er að færa verkefnið í „Kóðaskoðun“ dálkinn þegar þú býrð til dráttarbeiðni:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Það er sérstök aðgerð fyrir þetta á GitHub, allt sem það þarf er útgáfuauðkennið sem fékkst í fyrra skrefi og heimildin í JIRA sem við gerðum hér að ofan.
Á sama hátt geturðu dregið verkefni þegar sameinað er í meistarann og aðra atburði frá GitHub verkflæði. Almennt fer það allt eftir ímyndunarafli þínu og löngun til að gera sjálfvirkan venjubundna ferla.
Niðurstöður
Ef þú horfir á klassíska DEVOPS skýringarmyndina höfum við farið yfir öll stig, nema kannski starfræksla, ég held að ef þú reynir, þá geturðu fundið einhverjar aðgerðir á markaðnum fyrir samþættingu við þjónustuborðskerfið, svo við munum gera ráð fyrir að leiðslan hafi snúist út að vera ítarleg og hægt er að draga ályktanir út frá notkun þess.
Kostir:
- Markaðstorg með tilbúnum aðgerðum fyrir öll tækifæri, þetta er mjög flott. Í flestum þeirra geturðu líka skoðað frumkóðann til að skilja hvernig á að leysa svipað vandamál eða senda eiginleikabeiðni til höfundar beint í GitHub geymsluna.
- Að velja markvettvang fyrir samsetningu: Linux, Mac OS, Windows er nokkuð áhugaverður eiginleiki.
- Github pakkar eru frábærir hlutir, það er þægilegt að halda öllum innviðum á einum stað, þú þarft ekki að vafra um mismunandi glugga, allt er innan radíus frá einum eða tveimur músarsmellum og er fullkomlega samþætt GitHub Actions. Docker skrásetningarstuðningur í ókeypis útgáfunni er líka góður kostur.
- GitHub felur leyndarmál í byggingarskrám, svo að nota það til að geyma lykilorð og tákn er ekki svo skelfilegt. Í öllum tilraunum mínum gat ég aldrei séð leyndarmálið í sinni hreinu mynd í stjórnborðinu.
- Ókeypis fyrir Open Source verkefni
Gallar:
- YML, jæja, mér líkar ekki við hann. Þegar ég er að vinna með svona flæði eru algengustu commit skilaboðin sem ég hef "fix yml format", þá gleymirðu að setja flipa einhvers staðar, eða þú skrifar það á ranga línu. Almennt séð er það ekki skemmtilegasta upplifunin að sitja fyrir framan skjá með gráðuboga og reglustiku.
- KEMBÚA, kemba flæðið með skuldbindingum, keyra enduruppbyggingu og úttak á stjórnborðið er ekki alltaf þægilegt, en það er meira af "þú ert ofgert" flokki; þú ert vanur að vinna með þægilegri IDEA, þegar þú getur villuleitt hvað sem er .
- Þú getur skrifað aðgerðina þína á hvað sem er ef þú pakkar henni inn í Docker, en bara javascript er native stutt, auðvitað er þetta smekksatriði, en ég myndi vilja eitthvað annað í staðinn fyrir js.
Leyfðu mér að minna þig á að geymslan með öllum skriftunum er hér:
Í næstu viku mun ég koma fram með á Heisenbug 2020 Piter ráðstefnunni. Ég mun segja þér ekki aðeins hvernig á að forðast mistök við undirbúning prófunargagna, heldur einnig deila leyndarmálum mínum um að vinna með gagnasett í Java forritum!
Heimild: www.habr.com