GitHub कार्यहरूको साथ नरकको सर्कलहरू (जाभा परियोजनाको लागि CI/CD पाइपलाइन निर्माण गर्दै)

मैले प्राय: जाभामा परियोजनाहरू निर्माण गर्न पाइपलाइन निर्माण गर्नुपर्छ। कहिलेकाहीँ यो खुला स्रोत हो, कहिलेकाहीं यो होइन। मैले भर्खरै मेरा केही भण्डारहरू Travis-CI र TeamCity बाट GitHub कार्यहरूमा सार्ने प्रयास गर्ने निर्णय गरे, र यो यसबाट बाहिर आएको हो।

हामी के स्वचालित हुनेछ?

पहिले, हामीलाई एउटा प्रोजेक्ट चाहिन्छ जुन हामी स्वचालित गर्नेछौं, स्प्रिंग बुट / Java 11 / Maven मा एउटा सानो अनुप्रयोग बनाउनुहोस्। यस लेखको उद्देश्यका लागि, हामी एप्लिकेसन तर्कमा कुनै पनि चासो लिने छैनौं; अनुप्रयोग वरपरको पूर्वाधार हाम्रो लागि महत्त्वपूर्ण छ, त्यसैले एक साधारण REST API नियन्त्रक हाम्रो लागि पर्याप्त हुनेछ।

तपाईं यहाँ स्रोतहरू हेर्न सक्नुहुन्छ: github.com/antkorwin/github-actions पाइपलाइन निर्माणको सबै चरणहरू यस परियोजनाको लागि पुल अनुरोधहरूमा प्रतिबिम्बित हुन्छन्।

JIRA र योजना

यो भन्न लायक छ कि हामी सामान्यतया JIRA लाई मुद्दा ट्र्याकरको रूपमा प्रयोग गर्छौं, त्यसैले यो परियोजनाको लागि छुट्टै बोर्ड सिर्जना गरौं र त्यहाँ पहिलो मुद्दाहरू थपौं:

केहि समय पछि हामी JIRA र GitHub ले संयोजनमा प्रस्ताव गर्न सक्ने रोचक चीजहरूमा फर्कनेछौं।

हामी परियोजना को विधानसभा स्वचालित

हाम्रो परीक्षण परियोजना maven मार्फत बनाइएको छ, त्यसैले यसलाई निर्माण एकदम सरल छ, हामीलाई चाहिएको मात्र mvn सफा प्याकेज हो।

Github कार्यहरू प्रयोग गरेर यो गर्नको लागि, हामीले हाम्रो कार्यप्रवाह वर्णन गर्ने भण्डारमा एउटा फाइल सिर्जना गर्न आवश्यक छ, यो नियमित yml फाइलसँग गर्न सकिन्छ, म भन्न सक्दिन कि मलाई "yml प्रोग्रामिंग" मन पर्छ, तर हामी के गर्न सक्छौं - हामी यसलाई .github/ Directory workflow/ file build.yml मा गर्छौं जसमा हामी मास्टर शाखा निर्माण गर्दा कार्यहरू वर्णन गर्नेछौं:

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 — यो घटनाको विवरण हो जसमा हाम्रो स्क्रिप्ट सुरु हुनेछ।

मा: पुल_अनुरोध/पुश - यो कार्यप्रवाह प्रत्येक पटक मास्टरमा पुश गर्दा र पुल अनुरोधहरू सिर्जना गर्दा सुरु गर्न आवश्यक छ भनेर संकेत गर्दछ।

निम्न कार्यहरूको विवरण छ (जब) र कार्यान्वयन चरणहरू (कदमप्रत्येक कार्यको लागि।

चलिरहेको छ - यहाँ हामी लक्षित OS चयन गर्न सक्छौं, आश्चर्यजनक रूपमा, तपाईं पनि Mac OS चयन गर्न सक्नुहुन्छ, तर निजी भण्डारहरूमा यो धेरै महँगो छ (लिनक्सको तुलनामा)।

उपयोगहरु तपाईँलाई अन्य कार्यहरू पुन: प्रयोग गर्न अनुमति दिन्छ, उदाहरणका लागि, हामीले Java 11 को लागि वातावरण स्थापना गर्ने कार्यहरू/सेटअप-जाभा कार्य प्रयोग गरेर।

सहयोगको साथ संग हामी मापदण्डहरू निर्दिष्ट गर्न सक्छौं जसको साथ हामीले कार्य सुरु गर्छौं, अनिवार्य रूपमा यी तर्कहरू हुन् जुन कार्यमा पठाइनेछ।

माभेनमा परियोजना निर्माण चलाउन बाँकी रहेको छ: run: mvn -B clean package झण्डा -B भन्छ कि हामीलाई एक गैर-अन्तर्क्रियात्मक मोड चाहिन्छ ताकि maven अचानक हामीलाई केहि सोध्न चाहँदैन।

महान! अब, प्रत्येक पटक जब तपाइँ मास्टरमा प्रतिबद्ध हुनुहुन्छ, परियोजना निर्माण सुरु हुन्छ।

स्वचालित परीक्षण प्रक्षेपण

विधानसभा राम्रो छ, तर वास्तवमा, एक परियोजना सुरक्षित रूपमा भेला गर्न सकिन्छ, तर काम छैन। त्यसकारण, अर्को चरण परीक्षण रनहरू स्वचालित गर्न हो। थप रूपमा, तपाईंले PR समीक्षा गर्दा परीक्षणहरू पास गर्ने नतिजाहरू हेर्न यो धेरै सुविधाजनक छ - तपाईंलाई निश्चित रूपमा थाहा छ कि परीक्षणहरू उत्तीर्ण हुन्छन् र मर्ज गर्नु अघि कसैले पनि आफ्नो शाखा चलाउन बिर्सेका छैनन्।

पुल अनुरोध र मास्टरमा मर्ज गर्दा हामी परीक्षणहरू चलाउनेछौं, र एकै समयमा हामी कोड-कभरेजमा रिपोर्टको सिर्जना थप्नेछौं।

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 }}

परीक्षणहरू कभर गर्न, म jacoco प्लगइनको संयोजनमा codecov प्रयोग गर्छु। codecov को आफ्नै कार्य छ, तर यसलाई हाम्रो पुल अनुरोध संग काम गर्न टोकन आवश्यक छ:

${{ secrets.CODECOV_TOKEN }} — हामी यो निर्माण एक पटक भन्दा बढी देख्नेछौं, रहस्य GitHub मा गोप्य भण्डारण गर्न को लागी एक संयन्त्र हो, हामी त्यहाँ पासवर्ड/टोकन/होस्ट/urls र अन्य डाटा लेख्न सक्छौं जुन भण्डार कोड आधारमा समावेश गर्नु हुँदैन।

तपाईं GitHub मा भण्डार सेटिङहरूमा गोप्य कुराहरू थप्न सक्नुहुन्छ:

मा टोकन प्राप्त गर्न सक्नुहुन्छ codecov.io GitHub को माध्यम बाट प्राधिकरण पछि, एक सार्वजनिक परियोजना थप्न को लागी तपाईले यो जस्तै लिङ्क पछ्याउनु पर्छ: GitHub प्रयोगकर्ता नाम/ [रिपो नाम]। एक निजी भण्डार पनि थप्न सकिन्छ; यो गर्नको लागि, तपाईंले Github मा अनुप्रयोगमा codecov अधिकार दिन आवश्यक छ।

POM फाइलमा jacoco प्लगइन थप्नुहोस्:

<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>

अब कोडकोभ बोटले हाम्रा प्रत्येक पुल अनुरोधहरू प्रविष्ट गर्नेछ र कभरेज परिवर्तन ग्राफ थप्नेछ:

एक स्थिर विश्लेषक थपौं

मेरा धेरै जसो खुला स्रोत परियोजनाहरूमा म स्थिर कोड विश्लेषणको लागि सोनार क्लाउड प्रयोग गर्दछु, यो ट्र्याभिस-सीमा जडान गर्न एकदम सजिलो छ। त्यसोभए यो एक तार्किक कदम हो जब GitHub कार्यहरूमा माइग्रेट गर्दा त्यसै गर्न। एक्शन मार्केट एक राम्रो चीज हो, तर यस पटक यसले मलाई अलिकति निराश बनायो, किनकि बानीको कारणले मैले मलाई आवश्यक पर्ने कार्य फेला पारे र यसलाई कार्यप्रवाहमा थपे। तर यो बाहिरियो कि सोनारले maven वा gradle मा परियोजनाहरूको विश्लेषणको लागि कार्य मार्फत काम गर्न समर्थन गर्दैन। अवश्य पनि, यो कागजातमा लेखिएको छ, तर कसले यसलाई पढ्छ?!

यो कार्य मार्फत सम्भव छैन, त्यसैले हामी यसलाई 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 - मा प्राप्त गर्न सकिन्छ sonarcloud.io र तपाईंले यसलाई गोप्य रूपमा दर्ता गर्न आवश्यक छ। GITHUB_TOKEN - यो एक निर्मित टोकन हो जुन GitHub ले उत्पन्न गर्दछ, जसको मद्दतले सोनारक्लाउड [बोट] ले हामीलाई पुल अनुरोधहरूमा सन्देशहरू छोड्न Git मा लग इन गर्न सक्षम हुनेछ।

Dsonar.projectKey - सोनारमा परियोजनाको नाम, तपाइँ यसलाई परियोजना सेटिङहरूमा देख्न सक्नुहुन्छ।

Dsonar.organization - GitHub बाट संगठनको नाम।

हामी एक पुल अनुरोध गर्छौं र सोनारक्लाउड [बोट] टिप्पणीहरूमा आउनको लागि पर्खन्छौं:

रिलीज व्यवस्थापन

निर्माण कन्फिगर गरिएको छ, परीक्षणहरू चलाइएको छ, र हामी रिलीज गर्न सक्छौं। GitHub कार्यहरूले कसरी रिलीज व्यवस्थापन धेरै सजिलो बनाउन सक्छ हेरौं।

काममा, मसँग परियोजनाहरू छन् जसको कोड आधार बिटबकेटमा छ (सबै कुरा त्यो कथामा जस्तै छ "म दिनको समयमा बिटबकेटमा लेख्छु, राती गिटहबमा प्रतिबद्ध छु")। दुर्भाग्यवश, बिटबकेटमा निर्मित रिलीज व्यवस्थापन उपकरणहरू छैनन्। यो एक समस्या हो, किनकि प्रत्येक रिलीजको लागि तपाईंले म्यानुअल रूपमा संगममा पृष्ठ सिर्जना गर्नु पर्छ र त्यहाँ रिलीजमा समावेश सबै सुविधाहरू फ्याँक्नु पर्छ, दिमागका दरबारहरू खोज्नुहोस्, जिरामा कार्यहरू, भण्डारमा कमिटहरू। त्यहाँ गल्ती गर्ने धेरै सम्भावनाहरू छन्, तपाइँ केहि बिर्सन सक्नुहुन्छ वा केहि प्रविष्ट गर्न सक्नुहुन्छ जुन पहिले नै पछिल्लो पटक जारी गरिएको थियो, कहिलेकाहीँ यो केवल स्पष्ट छैन कि पुल अनुरोधलाई के रूपमा वर्गीकृत गर्ने - यो सुविधा वा बग समाधान, वा सम्पादन परीक्षणहरू, वा केही पूर्वाधार।

GitHub कार्यहरूले हामीलाई कसरी मद्दत गर्न सक्छ? त्यहाँ एक उत्कृष्ट कार्य छ - रिलिज ड्राफ्टर, यसले तपाईंलाई पुल अनुरोधहरूको कोटीहरू सेट अप गर्न र तिनीहरूलाई रिलीज नोट फाइलमा स्वचालित रूपमा समूहबद्ध गर्न रिलीज नोट फाइल टेम्प्लेट सेट गर्न अनुमति दिन्छ:

रिपोर्ट सेटअप गर्नको लागि उदाहरण टेम्प्लेट (.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

मस्यौदा रिलीज (.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 }}

अब देखि सबै पुल अनुरोधहरू स्वचालित रूपमा रिलीज नोटहरूमा सङ्कलन गरिनेछ - जादू!

यहाँ प्रश्न उठ्न सक्छ: विकासकर्ताहरूले PR मा ट्यागहरू राख्न बिर्से भने के हुन्छ? त्यसोभए कुन श्रेणीमा राख्ने भन्ने स्पष्ट छैन, र फेरि तपाईले यसलाई म्यानुअल रूपमा व्यवहार गर्नुपर्नेछ, प्रत्येक पीआरको साथ छुट्टै। यो समस्या समाधान गर्न, हामी अर्को कार्य प्रयोग गर्न सक्छौं - लेबल प्रमाणिकरण - यसले पुल अनुरोधमा ट्यागहरूको उपस्थितिको लागि जाँच गर्दछ। यदि त्यहाँ कुनै आवश्यक ट्यागहरू छैनन् भने, त्यसपछि जाँच असफल हुनेछ र हामी हाम्रो पुल अनुरोधमा यस बारे सन्देश देख्नेछौं।

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'

अब कुनै पनि पुल-अनुरोधलाई ट्यागहरू मध्ये एकको साथ चिन्ह लगाइनुपर्छ: type:fix, type:features, type:documentation, type:tests, type:config।

पुल अनुरोधहरूको स्वत: एनोटेसन

हामीले पुल अनुरोधहरूको साथ प्रभावकारी कामको रूपमा यस्तो विषयलाई छोएकाले, यो लेबलरको रूपमा यस्तो कार्यको बारेमा कुरा गर्न लायक छ, यसले PR मा ट्यागहरू राख्छ जसको आधारमा फाइलहरू परिवर्तन गरिएका छन्। उदाहरणका लागि, हामी डाइरेक्टरीमा परिवर्तनहरू समावेश गर्ने कुनै पनि पुल अनुरोधलाई [build] को रूपमा चिन्ह लगाउन सक्छौं .github/workflow.

यो जडान एकदम सरल छ:

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 }}

हामीलाई परियोजना निर्देशिकाहरू र पुल अनुरोध विषयहरू बीचको पत्राचार वर्णन गर्ने फाइल पनि चाहिन्छ:

theme:build:
  - ".github/**"
  - "pom.xml"
  - ".travis.yml"
  - ".gitignore"
  - "Dockerfile"

theme:code:
  - "src/main/*"

theme:tests:
  - "src/test/*"

theme:documentation:
  - "docs/**"

theme:TRASH:
  - ".idea/**"
  - "target/**"

आवश्यक लेबलहरूको उपस्थितिको लागि जाँच गर्ने कार्यसँग पुल अनुरोधहरूमा स्वचालित रूपमा लेबलहरू राख्ने कार्यलाई जोडा बनाउन म सफल भएन; मिलान-लेबलले बोटद्वारा थपिएका लेबलहरू हेर्न चाहँदैन। दुबै चरणहरू संयोजन गर्ने तपाईंको आफ्नै कार्य लेख्न सजिलो देखिन्छ। तर यस फारममा पनि यो प्रयोग गर्न धेरै सुविधाजनक छ; तपाईंले पुल अनुरोध सिर्जना गर्दा सूचीबाट लेबल चयन गर्न आवश्यक छ।

यो तैनाथ गर्ने समय हो

मैले GitHub कार्यहरू (ssh मार्फत, scp मार्फत, र docker-hub प्रयोग गरेर) मार्फत धेरै डिप्लोयमेन्ट विकल्पहरू प्रयास गरें, र म भन्न सक्छु कि, सम्भवतः, तपाईले सर्भरमा बाइनरी अपलोड गर्ने तरिका पाउनुहुनेछ, तपाईको पाइपलाइन जतिसुकै बाङ्गो भए पनि। छ।

मलाई सम्पूर्ण पूर्वाधार एकै ठाउँमा राख्ने विकल्प मन पर्यो, त्यसैले GitHub प्याकेजहरूमा कसरी डिप्लोय गर्ने भनेर हेरौं (यो बाइनरी सामग्री, एनपीएम, जार, डकरको लागि भण्डार हो)।

डकर छवि निर्माण गर्न र 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 }}"

पहिले, हामीले हाम्रो अनुप्रयोगको JAR फाइल निर्माण गर्न आवश्यक छ, त्यसपछि हामी GitHub डकर रजिस्ट्री र हाम्रो छविको नामको मार्ग गणना गर्छौं। यहाँ केहि चालहरू छन् जुन हामीले अहिलेसम्म भेट्टाएका छैनौं:

• एउटा निर्माण जस्तै: echo "::set-output name=NAME::VALUE" ले तपाइँलाई हालको चरणमा चलको मान सेट गर्न अनुमति दिन्छ, ताकि यसलाई त्यसपछि अन्य सबै चरणहरूमा पढ्न सकिन्छ।
• तपाईंले यस चरणको पहिचानकर्ता मार्फत अघिल्लो चरणमा सेट गरिएको चरको मान प्राप्त गर्न सक्नुहुन्छ: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• मानक GITHUB_REPOSITORY चरले भण्डारको नाम र यसको मालिक ("मालिक/रेपो-नाम") भण्डार गर्दछ। भण्डारको नाम बाहेक यस रेखाबाट सबै कुरा काट्नको लागि, हामी ब्यास सिन्ट्याक्स प्रयोग गर्नेछौं: ${GITHUB_REPOSITORY#*/}

अर्को हामीले डकर छवि निर्माण गर्न आवश्यक छ:

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

रजिस्ट्रीमा लग इन गर्नुहोस्:

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

र छविलाई GitHub प्याकेज रिपोजिटरीमा प्रकाशित गर्नुहोस्:

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

छविको संस्करणलाई संकेत गर्नको लागि, हामी कमिटको SHA ह्यासबाट पहिलो अंकहरू प्रयोग गर्छौं - GITHUB_SHA त्यहाँ पनि यहाँ सूक्ष्मताहरू छन्, यदि तपाईंले मास्टरमा मर्ज गर्दा मात्र होइन, तर पुल अनुरोध सिर्जना अनुसार पनि निर्माण गर्नुहुन्छ भने। घटना, तब SHA ले हामीले git इतिहासमा देखेको ह्याससँग मेल खाँदैन, किनभने कार्य/चेकआउट कार्यले PR मा डेडलक गर्ने कार्यहरूबाट बच्नको लागि आफ्नै अद्वितीय ह्यास बनाउँछ।

यदि सबै कुरा राम्रोसँग काम गर्यो भने, त्यसपछि प्याकेज खण्ड खोल्दा (https://github.com/antkorwin/github-actions/packages) भण्डारमा, तपाईंले नयाँ डकर छवि देख्नुहुनेछ:

त्यहाँ तपाइँ डकर छविको संस्करणहरूको सूची पनि हेर्न सक्नुहुन्छ।

यो रजिस्ट्री संग काम गर्न र सेवा पुन: सुरु गर्न हाम्रो सर्भर कन्फिगर गर्न बाँकी छ। म सायद अर्को पटक systemd मार्फत यो कसरी गर्ने बारे कुरा गर्नेछु।

निगरानी गर्दै

GitHub कार्यहरू प्रयोग गरेर हाम्रो अनुप्रयोगको लागि स्वास्थ्य जाँच कसरी गर्ने भन्ने बारे एउटा सरल विकल्प हेरौं। हाम्रो बुट एप्लिकेसनमा एक्चुएटर छ, त्यसैले हामीले यसको स्थिति जाँच गर्न API लेख्न पनि आवश्यक पर्दैन; हामीले अल्छीका लागि सबै कुरा गरिसकेका छौं। तपाईंले मात्र होस्ट तान्न आवश्यक छ: 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"}

हामीलाई क्रोन प्रयोग गरेर सर्भर जाँच गर्न एउटा कार्य लेख्नु आवश्यक छ, र यदि अचानक यसले हामीलाई जवाफ दिँदैन भने, हामी टेलिग्राम मार्फत सूचना पठाउनेछौं।

पहिले, क्रोन कार्यप्रवाह कसरी चलाउने भनेर पत्ता लगाउनुहोस्:

on:
  schedule:
    - cron:  '*/5 * * * *'

यो सरल छ, म विश्वास गर्न सक्दिन कि Github मा तपाइँ घटनाहरू सिर्जना गर्न सक्नुहुन्छ जुन वेबहुकहरूमा फिट हुँदैन। विवरणहरू कागजातमा छन्: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

कर्ल मार्फत म्यानुअल रूपमा सर्भर स्थिति जाँच गरौं:

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"

पहिले, हामी सर्भरले अनुरोधमा प्रतिक्रिया दिएको भ्यारीएबलमा बचत गर्छौं, अर्को चरणमा हामी स्थिति UP हो भनेर जाँच गर्छौं र, यदि यो मामला होइन भने, हामी त्रुटिको साथ बाहिर निस्कन्छौं। यदि तपाइँ तपाइँको हातहरु संग एक कार्य "अधिपत्य" गर्न आवश्यक छ भने, त्यसपछि निकास 1१ - उपयुक्त हतियार।

  - 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 }}

अघिल्लो चरणमा कार्य असफल भएमा मात्र हामी टेलिग्राममा पठाउँछौं। सन्देश पठाउनको लागि हामीले Appleboy/telegram-action प्रयोग गर्छौं; तपाइँ कागजातमा बोट टोकन र च्याट आईडी कसरी प्राप्त गर्ने बारे पढ्न सक्नुहुन्छ: github.com/appleboy/telegram-action

Github मा गोप्य लेख्न नबिर्सनुहोस्: सर्भरको लागि URL र टेलिग्राम बोटको लागि टोकन।

बोनस ट्र्याक - अल्छी लागि JIRA

मैले जिरामा फर्कने वाचा गरेँ, र हामी फर्केका छौं। सयौं पटक मैले स्ट्यान्ड-अपमा अवस्था देखेको छु जब विकासकर्ताहरूले एक सुविधा बनाए, शाखा मर्ज गरे, तर मुद्दालाई JIRA मा तान्न बिर्सनुभयो। अवश्य पनि, यदि यो सबै एकै ठाउँमा गरिएको थियो भने, यो सजिलो हुनेछ, तर वास्तवमा हामी IDE मा कोड लेख्छौं, शाखाहरूलाई बिटबकेट वा GitHub मा मर्ज गर्छौं, र त्यसपछि कार्यहरूलाई जिरामा तान्दछौं, यसका लागि हामीले नयाँ विन्डोहरू खोल्न आवश्यक छ। , कहिलेकाहीँ फेरि लग इन गर्नुहोस् र आदि। जब तपाइँ पूर्ण रूपमा सम्झनुहुन्छ कि तपाइँ अर्को के गर्न आवश्यक छ, त्यसपछि फेरि बोर्ड खोल्ने कुनै मतलब छैन। नतिजाको रूपमा, बिहान स्ट्यान्डअपमा तपाईंले टास्क बोर्ड अपडेट गर्न समय खर्च गर्न आवश्यक छ।

GitHub ले हामीलाई यो दिनचर्या कार्यमा पनि मद्दत गर्नेछ; शुरुवातकर्ताहरूको लागि, हामीले पुल अनुरोध पेश गर्दा हामी समस्याहरूलाई स्वतः code_review स्तम्भमा ड्र्याग गर्न सक्छौं। तपाईले गर्नु पर्ने भनेको शाखा नामकरण कन्भेन्सन पालना गर्नु हो:

[имя проекта]-[номер таска]-название

उदाहरणका लागि, यदि परियोजना कुञ्जी "GitHub कार्यहरू" GA हो, त्यसपछि GA-8-jira-bot GA-8 कार्य कार्यान्वयनको लागि शाखा हुन सक्छ।

JIRA सँग एकीकरण एटलासियनबाट कार्यहरू मार्फत काम गर्दछ, तिनीहरू पूर्ण छैनन्, मैले भन्नै पर्छ कि तिनीहरूमध्ये केहीले मेरो लागि काम गरेनन्। तर हामी केवल ती कुराहरू छलफल गर्नेछौं जुन निश्चित रूपमा काम गर्दछ र सक्रिय रूपमा प्रयोग गरिन्छ।

पहिले तपाईंले कार्य प्रयोग गरेर JIRA मा लग इन गर्न आवश्यक छ: 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 }}

यो गर्नको लागि, तपाईंले JIRA मा टोकन प्राप्त गर्न आवश्यक छ, यो कसरी गर्ने यहाँ वर्णन गरिएको छ: confluence.atlassian.com/cloud/api-tokens-938839638.html

हामी शाखाको नामबाट कार्य पहिचानकर्ता निकाल्छौं:

  - 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}}

यदि तपाइँ GitHub बजारमा खोज्नुहुन्छ भने, तपाइँ यस कार्यको लागि कार्य फेला पार्न सक्नुहुन्छ, तर मैले शाखाको नाम प्रयोग गरेर grep प्रयोग गरेर उही कुरा लेख्नु परेको थियो, किनभने Atlassian को यो कार्य कुनै पनि हिसाबले मेरो परियोजनामा ​​काम गर्न चाहँदैन थियो। , त्यहाँ के गल्ती थियो पत्ता लगाउन - आफ्नो हातले एउटै कुरा गर्नु भन्दा लामो।

पुल अनुरोध सिर्जना गर्दा कार्यलाई "कोड समीक्षा" स्तम्भमा सार्न बाँकी रहेको छ:

  - name: Transition issue
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

GitHub मा यसको लागि एक विशेष कार्य छ, यसलाई अघिल्लो चरणमा प्राप्त मुद्दा ID र हामीले माथि गरेको JIRA मा प्राधिकरण चाहिन्छ।

त्यसै गरी, तपाईं मास्टरमा मर्ज गर्दा कार्यहरू ड्र्याग गर्न सक्नुहुन्छ, र GitHub कार्यप्रवाहबाट अन्य घटनाहरू। सामान्यतया, यो सबै तपाइँको कल्पना र दिनचर्या प्रक्रियाहरु स्वचालित गर्न इच्छा मा निर्भर गर्दछ।

निष्कर्ष

यदि तपाईंले क्लासिक DEVOPS रेखाचित्र हेर्नुभयो भने, हामीले सबै चरणहरू कभर गरेका छौं, सम्भवतः सञ्चालन बाहेक, मलाई लाग्छ यदि तपाईंले प्रयास गर्नुभयो भने, तपाईंले हेल्प-डेस्क प्रणालीसँग एकीकरणको लागि बजारमा केही कार्यहरू फेला पार्न सक्नुहुन्छ, त्यसैले हामी पाइपलाइन मोडियो भनेर अनुमान गर्नेछौं। यसको प्रयोगको आधारमा विस्तृत र निष्कर्ष निकाल्न सकिन्छ।

प्रो:

• सबै अवसरहरूको लागि तयार कार्यहरू भएको बजार, यो धेरै राम्रो छ। ती मध्ये धेरैमा, तपाईले स्रोत कोडलाई कसरी समान समस्या समाधान गर्ने भनेर बुझ्न वा लेखकलाई सिधै GitHub भण्डारमा एक सुविधा अनुरोध पोस्ट गर्न सक्नुहुन्छ।
• एसेम्बलीका लागि लक्षित प्लेटफर्म चयन गर्दै: लिनक्स, म्याक ओएस, विन्डोज एकदमै रोचक सुविधा हो।
• Github प्याकेजहरू एक महान कुरा हो, सम्पूर्ण पूर्वाधार एकै ठाउँमा राख्न यो सुविधाजनक छ, तपाईंले विभिन्न विन्डोजहरू मार्फत सर्फ गर्नुपर्दैन, सबै कुरा एक वा दुई माउस क्लिकको दायरा भित्र छ र GitHub कार्यहरूसँग पूर्ण रूपमा एकीकृत छ। नि: शुल्क संस्करणमा डकर रजिस्ट्री समर्थन पनि राम्रो फाइदा हो।
• GitHub ले बिल्ड लगहरूमा गोप्य कुराहरू लुकाउँछ, त्यसैले यसलाई पासवर्ड र टोकनहरू भण्डारण गर्न प्रयोग गर्नु डरलाग्दो छैन। मेरा सबै प्रयोगहरूको बखत, मैले कन्सोलमा यसको शुद्ध रूपमा गोप्य देख्न सकिन।
• खुला स्रोत परियोजनाहरूको लागि निःशुल्क

Cons:

• YML, ठीक छ, म उसलाई मन पराउँदैन। यस्तो प्रवाहको साथ काम गर्दा, मसँग सबैभन्दा सामान्य प्रतिबद्ध सन्देश "फिक्स yml ढाँचा" हो, त्यसपछि तपाइँ कतै ट्याब राख्न बिर्सनुभयो, वा तपाइँ यसलाई गलत लाइनमा लेख्नुहुन्छ। सामान्यतया, एक प्रोट्रेक्टर र शासक संग स्क्रिनको अगाडि बस्नु सबैभन्दा सुखद अनुभव होइन।
• DEBUG, कमिटहरूको साथ प्रवाह डिबग गर्ने, पुन: निर्माण चलाउने, र कन्सोलमा आउटपुट गर्ने सधैं सुविधाजनक हुँदैन, तर यो "तपाईले ओभरडन" श्रेणीको अधिक हो; तपाइँ सुविधाजनक IDEA सँग काम गर्न प्रयोग गर्नुहुन्छ, जब तपाइँ केहि पनि डिबग गर्न सक्नुहुन्छ। ।
• तपाईंले आफ्नो कार्यलाई कुनै पनि कुरामा लेख्न सक्नुहुन्छ यदि तपाईंले यसलाई डकरमा र्‍याप गर्नुभयो भने, तर जाभास्क्रिप्ट मात्र नेटिभ रूपमा समर्थित छ, निस्सन्देह यो स्वादको कुरा हो, तर म js को सट्टा अरू केहि रुचाउँछु।

मलाई सम्झाउन दिनुहोस् कि सबै स्क्रिप्टहरूको भण्डार यहाँ छ: github.com/antkorwin/github-actions

अर्को हप्ता म संग प्रदर्शन गर्नेछु रिपोर्ट Heisenbug 2020 Piter सम्मेलनमा। म तपाईलाई परीक्षण डाटा तयार गर्दा गल्तीहरूबाट बच्ने मात्र होइन, जाभा अनुप्रयोगहरूमा डाटा सेटहरूसँग काम गर्ने मेरो रहस्यहरू पनि साझा गर्ने छु!

स्रोत: www.habr.com