Mi ofte devas konstrui dukton por konstruado de projektoj en Java. Foje ĝi estas malferma fonto, foje ĝi ne estas. Mi lastatempe decidis provi movi kelkajn el miaj deponejoj de Travis-CI kaj TeamCity al GitHub Actions, kaj jen kio eliris el ĝi.
Kion ni aŭtomatigos?
Unue, ni bezonas projekton, kiun ni aŭtomatigos, ni faru malgrandan aplikaĵon en Spring boot / Java 11 / Maven. Por la celoj de ĉi tiu artikolo, ni tute ne interesiĝos pri la aplika logiko; la infrastrukturo ĉirkaŭ la aplikaĵo estas grava por ni, do simpla REST API-regilo sufiĉos por ni.
Vi povas vidi la fontojn ĉi tie: Ĉiuj etapoj de konstruado de dukto estas reflektitaj en la tirpetoj por ĉi tiu projekto.
JIRA kaj planado
Indas diri, ke ni kutime uzas JIRA kiel temo-spurilo, do ni kreu apartan tabulon por ĉi tiu projekto kaj aldonu la unuajn numerojn tie:
Iom poste ni revenos al kiaj interesaj aferoj JIRA kaj GitHub povas proponi kombine.
Ni aŭtomatigas la muntadon de la projekto
Nia testa projekto estas konstruita per maven, do konstrui ĝin estas sufiĉe simpla, ĉio, kion ni bezonas, estas la mvn-pura pako.
Por fari tion uzante Github Actions, ni devos krei dosieron en la deponejo priskribanta nian laborfluon, tio povas esti farita per regula yml-dosiero, mi ne povas diri, ke mi ŝatas "yml-programadon", sed kion ni povas fari - ni faras ĝin en la .github/ dosierujo workflow/ dosiero build.yml en kiu ni priskribos la agojn dum konstruado de la majstra branĉo:
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 — jen priskribo de la evento, pri kiu nia skripto estos lanĉita.
sur: pull_request/push — indikas, ke ĉi tiu laborfluo devas esti lanĉita ĉiufoje kiam oni faras puŝon al la majstro kaj kreiĝas tirpetoj.
La sekvanta estas priskribo de la taskoj (laborpostenojn) kaj ekzekutŝtupoj (paŝoj) por ĉiu tasko.
kuras plu - ĉi tie ni povas elekti la celitan OS, surprize, vi eĉ povas elekti Mac OS, sed ĉe privataj deponejoj tio estas sufiĉe multekosta (kompare kun Linukso).
uzoj permesas al vi reuzi aliajn agojn, ekzemple, uzante la agojn/agordi-java ago ni instalas la medion por Java 11.
Kun la helpo de kun ni povas specifi la parametrojn per kiuj ni lanĉas la agon, esence ĉi tiuj estas la argumentoj, kiuj estos pasigitaj al la ago.
Restas nur ruli la projekton kun Maven: run: mvn -B clean package flago -B diras, ke ni bezonas ne-interagan reĝimon, por ke la maven subite ne volas demandi al ni ion.
Bonege! Nun, ĉiufoje kiam vi kompromitas al la majstro, la projekto-konstruo komenciĝas.
Aŭtomatigi testlanĉojn
Asembleo estas bona, sed fakte, projekto povas esti kunvenita sekure, sed ne funkcias. Tial, la sekva paŝo estas aŭtomatigi la provojn. Krome, estas sufiĉe oportune rigardi la rezultojn de trapaso de la testoj kiam vi faras PR-revizion - vi certe scias, ke la testoj trapasas kaj neniu forgesis prizorgi sian branĉon antaŭ fari kunfandi.
Ni faros provojn kreante tirpeton kaj kunfandi en la majstron, kaj samtempe ni aldonos la kreadon de raporto pri kodo-kovrado.
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 }}
Por kovri testojn, mi uzas codecov kune kun la jacoco kromaĵo. codecov havas sian propran agon, sed ĝi bezonas ĵetonon por funkcii kun nia tirpeto:
${{ secrets.CODECOV_TOKEN }} — ni vidos ĉi tiun konstruon pli ol unufoje, sekretoj estas mekanismo por stoki sekretojn en GitHub, ni povas skribi tie pasvortojn/tokens/hosts/urls kaj aliajn datumojn, kiuj ne devus esti inkluditaj en la deponeja kodobazo.
Vi povas aldoni variablon al sekretoj en la deponejaj agordoj en GitHub:
Vi povas akiri ĵetonon ĉe Post rajtigo per GitHub, por aldoni publikan projekton vi nur bezonas sekvi ligon kiel ĉi tion: /[reponomo]. Privata deponejo ankaŭ povas esti aldonita; por fari tion, vi devas doni codecov-rajtojn al la aplikaĵo en Github.
Aldonu la jacoco-aldonaĵon al la POM-dosiero:
<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>
Nun la codecov-bot enmetos ĉiun el niaj tiraj petoj kaj aldonos kovroŝanĝan grafikon:
Ni aldonu statikan analizilon
En la plej multaj el miaj malfermfontaj projektoj mi uzas sonarnubon por statika koda analizo, estas sufiĉe facile konekti al travis-ci. Do ĝi estas logika paŝo dum migrado al GitHub Agoj fari la samon. La agomerkato estas bonega afero, sed ĉi-foje ĝi iomete lasis min, ĉar pro kutimo mi trovis la agon, kiun mi bezonis, kaj aldonis ĝin al la laborfluo. Sed montriĝis, ke sonaro ne subtenas labori per ago por analizi projektojn pri maven aŭ gradle. Kompreneble, ĉi tio estas skribita en la dokumentado, sed kiu legas ĝin?!
Ne eblas per ago, do ni faros ĝin per la mvn kromaĵo:
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 - akireblas ĉe kaj vi devas registri ĝin en sekretoj. GITHUB_TOKEN - ĉi tio estas enkonstruita signo, kiun generas GitHub, kun la helpo de kiu sonarcloud[bot] povos ensaluti al Git por lasi al ni mesaĝojn en tiraj petoj.
Dsonar.projectKey — la nomo de la projekto en la sonaro, vi povas vidi ĝin en la projektaj agordoj.
Dsonar.organizo — nomo de la organizo de GitHub.
Ni faras tiran peton kaj atendas ke sonarcloud[bot] venos en la komentoj:
Eldona administrado
La konstruo estis agordita, la testoj estis rulitaj, kaj ni povas fari eldonon. Ni rigardu kiel GitHub-Agoj povas multe plifaciligi eldonadministradon.
Ĉe la laboro, mi havas projektojn, kies kodbazo estas en bitbucket (ĉio estas kiel en tiu rakonto "Mi skribas al bitbucket dumtage, kompromitas al GitHub nokte"). Bedaŭrinde, bitbucket ne havas enkonstruitajn eldonadministrajn ilojn. Ĉi tio estas problemo, ĉar por ĉiu eldono vi devas permane krei paĝon en kunfluo kaj ĵeti ĉiujn funkciojn inkluzivitajn en la eldono tien, serĉi tra la palacoj de la menso, taskoj en jira, kompromiti en la deponejo. Estas multaj ŝancoj fari eraron, vi povas forgesi ion aŭ enigi ion, kio jam estis publikigita la lastan fojon, foje simple ne klaras, kion klasifiki tiran peton kiel - ĉu ĝi estas funkcio aŭ cimo korekto, aŭ redaktado de testoj, aŭ io infrastruktura.
Kiel GitHub-agoj povas helpi nin? Estas bonega agado - eldonredaktilo, ĝi ebligas al vi agordi ŝablonon de dosiernotoj por agordi kategoriojn de tirpetoj kaj aŭtomate grupigi ilin en la dosiero de eldonnotoj:
Ekzempla ŝablono por agordi raporton (.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
Aldonu skripton por generi skizan eldonon (.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 }}
Ĉiuj tirpetoj de nun estos kolektitaj en eldonnotoj aŭtomate - magio!
Ĉi tie povas ŝpruci la demando: kio se la programistoj forgesos meti etikedojn en la PR? Tiam ne estas klare en kiu kategorio meti ĝin, kaj denove vi devos trakti ĝin permane, kun ĉiu PR aparte. Por solvi ĉi tiun problemon, ni povas uzi alian agon - etikedkontrolilo - ĝi kontrolas la ĉeeston de etikedoj sur la tirpeto. Se ne estas bezonataj etikedoj, tiam la kontrolo malsukcesos kaj ni vidos mesaĝon pri tio en nia tira peto.
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'
Nun iu ajn tirpeto devas esti markita per unu el la etikedoj: tipo:fikso, tipo:funkcioj, tipo:dokumentado, tipo:testoj, tipo:agordo.
Aŭtomata komentario de tirpetoj
Ĉar ni tuŝis tian temon kiel efikan laboron kun tirpetoj, indas paroli pri tia ago kiel labeler, ĝi metas etikedojn en PR surbaze de kiuj dosieroj estis ŝanĝitaj. Ekzemple, ni povas marki kiel [konstrui] ajnan tiran peton kiu enhavas ŝanĝojn al la dosierujo .github/workflow.
Konekti ĝin estas sufiĉe simpla:
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 }}
Ni ankaŭ bezonas dosieron priskribantan la korespondadon inter la projektaj dosierujoj kaj la tirpetoj-temoj:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Mi ne sukcesis kunigi la agon, kiu aŭtomate metas etikedojn en tirpetojn kun la ago, kiu kontrolas la ĉeeston de bezonataj etikedoj; match-label ne volas vidi la etikedojn aldonitajn de la bot. Ŝajnas pli facile verki vian propran agon, kiu kombinas ambaŭ stadiojn. Sed eĉ en ĉi tiu formo ĝi estas sufiĉe oportuna uzi; vi devas elekti etikedon el la listo kiam vi kreas tiran peton.
Estas tempo por deploji
Mi provis plurajn disfaldajn opciojn per GitHub-Agoj (per ssh, per scp kaj uzante docker-hub), kaj mi povas diri, ke, plej verŝajne, vi trovos manieron alŝuti la binaron al la servilo, kiom ajn malrektita via dukto. estas.
Mi ŝatis la eblon konservi la tutan infrastrukturon en unu loko, do ni rigardu kiel deploji al GitHub-Pakoj (ĉi tio estas deponejo por binara enhavo, npm, jar, docker).
Skripto por konstrui docker-bildon kaj publikigi ĝin en GitHub-Pakoj:
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 }}"
Unue, ni devas konstrui la JAR-dosieron de nia aplikaĵo, post kio ni kalkulas la vojon al la GitHub-docker-registro kaj la nomon de nia bildo. Estas kelkaj lertaĵoj ĉi tie, kiujn ni ankoraŭ ne trovis:
- konstruo kiel: echo “::set-output name=NAME::VALUE” ebligas al vi agordi la valoron de variablo en la nuna paŝo, por ke ĝi tiam estu legita en ĉiuj aliaj paŝoj.
- vi povas akiri la valoron de la variablo aro en la antaŭa paŝo per la identigilo de ĉi tiu paŝo: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- La norma GITHUB_REPOSITORY variablo konservas la nomon de la deponejo kaj ĝia posedanto ("posedanto/repo-nomo"). Por tranĉi ĉion el ĉi tiu linio krom la nomo de la deponejo, ni uzos bash-sintakso: ${GITHUB_REPOSITORY#*/}
Poste ni devas konstrui la docker-bildon:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Ensalutu al la registro:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Kaj publikigu la bildon al GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Por indiki la version de la bildo, ni uzas la unuajn ciferojn de la SHA hash de la kommit - GITHUB_SHA ankaŭ estas nuancoj ĉi tie, se vi faras tiajn konstruojn ne nur dum kunfandado en majstron, sed ankaŭ laŭ la tirpeto kreado. evento, tiam SHA eble ne kongruas kun la hash, kiun ni vidas en la git-historio, ĉar la agoj/elĉerpa ago faras sian propran unikan hash por eviti blokiĝajn agojn en la PR.
Se ĉio funkciis bone, tiam malfermante la sekcion pri pakoj (https://github.com/antkorwin/github-actions/packages) en la deponejo, vi vidos novan docker-bildon:
Tie vi ankaŭ povas vidi liston de versioj de la docker-bildo.
Restas nur agordi nian servilon por labori kun ĉi tiu registro kaj rekomenci la servon. Mi verŝajne parolos pri kiel fari tion per systemd alian fojon.
Monitorado
Ni rigardu simplan opcion pri kiel fari sankontrolon por nia aplikaĵo uzante GitHub Actions. Nia lanĉa aplikaĵo havas aktuarilon, do ni eĉ ne bezonas skribi API por kontroli ĝian staton; ni jam faris ĉion por maldiligentuloj. Vi nur bezonas tiri la gastiganton: 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"}
Ni bezonas nur skribi taskon por kontroli la servilon per cron, kaj se subite ĝi ne respondas al ni, tiam ni sendos sciigon per telegramo.
Unue, ni eltrovu kiel ruli cron-laborfluon:
on:
schedule:
- cron: '*/5 * * * *'
Ĝi estas simpla, mi eĉ ne povas kredi, ke en Github vi povas krei eventojn, kiuj tute ne taŭgas en rethokoj. Detaloj estas en la dokumentado:
Ni kontrolu la servilon staton permane per buklo:
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"
Unue, ni konservas en variablon, kion la servilo respondis al la peto, en la sekva paŝo ni kontrolas, ke la stato estas UP kaj, se ĉi tio ne estas la kazo, tiam ni eliras kun eraro. Se vi bezonas "superforti" agon per viaj manoj, tiam eliro 1 - taŭga armilo.
- 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 }}
Ni sendas al telegramo nur se la ago malsukcesis ĉe la antaŭa paŝo. Por sendi mesaĝon ni uzas appleboy/telegram-action; vi povas legi pri kiel akiri bot-ĵetonon kaj babilejon en la dokumentado:
Ne forgesu skribi en la sekretoj sur Github: URL por la servilo kaj ĵetonoj por la telegrambot.
Bonustrako - JIRA por mallaboruloj
Mi promesis, ke ni revenos al JIRA, kaj ni revenis. Centfoje mi observis situacion ĉe stand-ups kiam programistoj faris funkcion, kunfandis branĉon, sed forgesis treni la aferon en JIRA. Kompreneble, se ĉio ĉi estus farita en unu loko, estus pli facile, sed fakte ni skribas kodon en la IDE, kunfandas branĉojn en bitbucket aŭ GitHub, kaj poste trenas la taskojn en Jira, por tio ni bezonas malfermi novajn fenestrojn. , foje ensalutu denove kaj ktp. Kiam vi perfekte memoras, kion vi devas fari poste, tiam ne utilas malfermi la tabulon denove. Kiel rezulto, matene ĉe stando vi devas pasigi tempon ĝisdatigante la taskotabulon.
GitHub ankaŭ helpos nin en ĉi tiu rutina tasko; por komenci, ni povas treni problemojn aŭtomate en la kolumnon code_review kiam ni sendas tiran peton. Ĉio, kion vi bezonas fari, estas sekvi la branĉan nomkonvencion:
[имя проекта]-[номер таска]-название
ekzemple, se la projektŝlosilo "GitHub Agoj" estas GA, tiam GA-8-jira-bot povus esti branĉo por efektivigi la taskon GA-8.
Integriĝo kun JIRA funkcias per agoj de Atlassian, ili ne estas perfektaj, mi devas diri, ke kelkaj el ili tute ne funkciis por mi. Sed ni diskutos nur tiujn, kiuj certe funkcias kaj estas aktive uzataj.
Unue vi devas ensaluti al JIRA per la ago: 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 }}
Por fari tion, vi devas akiri ĵetonon en JIRA, kiel fari tion estas priskribita ĉi tie:
Ni ĉerpas la taskidentigilon el la branĉonomo:
- 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}}
Se vi serĉas en la vendoplaco GitHub, vi povas trovi agon por ĉi tiu tasko, sed mi devis skribi la samon uzante grep uzante la nomon de la branĉo, ĉar ĉi tiu ago de Atlassian neniel volis labori pri mia projekto. , por eltrovi kio estis malbone tie - pli longe ol fari la samon per viaj manoj.
Restas nur movi la taskon al la kolumno "Koda revizio" kiam vi kreas tiran peton:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Estas speciala ago por ĉi tio sur GitHub, ĉio, kion ĝi bezonas, estas la eldona ID akirita en la antaŭa paŝo kaj la rajtigon en JIRA, kiujn ni faris supre.
De la sama maniero, vi povas treni taskojn dum kunfandado en la majstron, kaj aliajn eventojn de GitHub laborfluo. Ĝenerale, ĉio dependas de via imago kaj deziro aŭtomatigi rutinajn procezojn.
trovoj
Se vi rigardas la klasikan DEVOPS-diagramon, ni kovris ĉiujn stadiojn, krom eble funkcii, mi pensas, ke se vi provos, vi povas trovi iun agon en la merkato por integriĝo kun la helpa sistemo, do ni supozos, ke la dukto turniĝis. esti ĝisfunda kaj konkludoj povas esti desegnitaj surbaze de ĝia uzo.
Pros:
- Foirejo kun pretaj agoj por ĉiuj okazoj, ĉi tio estas tre bonega. En la plej multaj el ili, vi ankaŭ povas rigardi la fontkodon por kompreni kiel solvi similan problemon aŭ sendi peton pri funkcio al la aŭtoro rekte en la deponejo de GitHub.
- Elekti la celplatformon por kunigo: Linukso, mac os, fenestroj estas sufiĉe interesa trajto.
- Github-Pakoj estas bonega afero, estas oportune konservi la tutan infrastrukturon en unu loko, vi ne devas navigi tra malsamaj fenestroj, ĉio estas en radio de unu aŭ du musklakoj kaj estas perfekte integrita kun GitHub Actions. Docker-registra subteno en la senpaga versio ankaŭ estas bona avantaĝo.
- GitHub kaŝas sekretojn en konstruaj protokoloj, do uzi ĝin por stoki pasvortojn kaj ĵetonojn ne estas tiom timiga. Dum ĉiuj miaj eksperimentoj, mi neniam povis vidi la sekreton en ĝia pura formo en la konzolo.
- Senpaga por Open Source projektoj
Kons:
- YML, nu, mi ne ŝatas lin. Kiam vi laboras kun tia fluo, la plej ofta commit-mesaĝo kiun mi havas estas "fix yml format", tiam vi forgesas meti langeton ien, aŭ vi skribas ĝin sur la malĝusta linio. Ĝenerale, sidi antaŭ ekrano kun transportilo kaj regulo ne estas la plej agrabla sperto.
- ELSENCIRMI, sencimigi la fluon per kommits, ruli rekonstruon kaj eligi al la konzolo ne ĉiam estas oportuna, sed ĝi estas pli de la kategorio "vi troigis"; vi kutimas labori kun oportuna IDEO, kiam vi povas sencimigi ion ajn. .
- Vi povas skribi vian agon pri io ajn, se vi envolvas ĝin en Docker, sed nur javaskripto estas denaske subtenata, kompreneble ĉi tio estas demando de gusto, sed mi preferus ion alian anstataŭ js.
Mi memorigu vin, ke la deponejo kun ĉiuj skriptoj estas ĉi tie:
Venontsemajne mi prezentos kun ĉe la Heisenbug 2020 Piter-konferenco. Mi diros al vi ne nur kiel eviti erarojn kiam vi preparas testajn datumojn, sed ankaŭ konigos miajn sekretojn pri laboro kun datumaj aroj en Java-aplikoj!
fonto: www.habr.com