រង្វង់នៃឋាននរកជាមួយនឹងសកម្មភាព GitHub (ការកសាងបំពង់ CI/CD សម្រាប់គម្រោង Java)

ជារឿយៗខ្ញុំត្រូវសាងសង់បំពង់សម្រាប់គម្រោងសាងសង់នៅកោះជ្វា។ ពេលខ្លះវាជាប្រភពបើកចំហ ពេលខ្លះវាមិនមែនទេ។ ថ្មីៗនេះ ខ្ញុំបានសម្រេចចិត្តព្យាយាមផ្លាស់ប្តូរឃ្លាំងរបស់ខ្ញុំមួយចំនួនពី Travis-CI និង TeamCity ទៅ GitHub Actions ហើយនេះគឺជាអ្វីដែលចេញពីវា។

តើយើងនឹងធ្វើអ្វីដោយស្វ័យប្រវត្តិ?

ដំបូងយើងត្រូវការគម្រោងដែលយើងនឹងធ្វើស្វ័យប្រវត្តិ ចូរយើងបង្កើតកម្មវិធីតូចមួយនៅក្នុង Spring boot / Java 11 / Maven ។ សម្រាប់គោលបំណងនៃអត្ថបទនេះ យើងនឹងមិនចាប់អារម្មណ៍លើតក្កវិជ្ជាកម្មវិធីទាល់តែសោះ ហេដ្ឋារចនាសម្ព័ន្ធជុំវិញកម្មវិធីមានសារៈសំខាន់សម្រាប់យើង ដូច្នេះឧបករណ៍បញ្ជា REST API សាមញ្ញនឹងគ្រប់គ្រាន់សម្រាប់យើង។

អ្នកអាចមើលប្រភពនៅទីនេះ៖ github.com/antkorwin/github-actions ដំណាក់កាលទាំងអស់នៃការសាងសង់បំពង់បង្ហូរប្រេងត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងសំណើទាញសម្រាប់គម្រោងនេះ។

JIRA និងការធ្វើផែនការ

វាមានតម្លៃនិយាយថាជាធម្មតាយើងប្រើ JIRA ជាកម្មវិធីតាមដានបញ្ហា ដូច្នេះសូមបង្កើតបន្ទះដាច់ដោយឡែកសម្រាប់គម្រោងនេះ ហើយបន្ថែមបញ្ហាដំបូងនៅទីនោះ៖

បន្តិចទៀតយើងនឹងត្រលប់ទៅអ្វីដែលគួរឱ្យចាប់អារម្មណ៍ដែល JIRA និង GitHub អាចផ្តល់ជូនរួមបញ្ចូលគ្នា។

យើងធ្វើស្វ័យប្រវត្តិកម្មការជួបប្រជុំគ្នានៃគម្រោង

គម្រោងសាកល្បងរបស់យើងត្រូវបានសាងសង់តាមរយៈ maven ដូច្នេះការសាងសង់វាគឺសាមញ្ញណាស់ អ្វីដែលយើងត្រូវការគឺកញ្ចប់ mvn clean ។

ដើម្បីធ្វើដូច្នេះដោយប្រើ Github Actions យើងនឹងត្រូវការបង្កើតឯកសារមួយនៅក្នុងឃ្លាំងដែលពិពណ៌នាអំពីដំណើរការការងាររបស់យើង នេះអាចត្រូវបានធ្វើជាមួយឯកសារ 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 — នេះគឺជាការពិពណ៌នាអំពីព្រឹត្តិការណ៍ដែលស្គ្រីបរបស់យើងនឹងត្រូវបានដាក់ឱ្យដំណើរការ។

លើ៖ pull_request/push — បង្ហាញថាលំហូរការងារនេះត្រូវតែចាប់ផ្តើមរាល់ពេលដែលការជំរុញត្រូវបានធ្វើឡើងចំពោះមេ និងសំណើរទាញត្រូវបានបង្កើតឡើង។

ខាង​ក្រោម​នេះ​គឺ​ជា​ការ​ពិពណ៌នា​អំពី​ភារកិច្ច (ការងារ) និង​ជំហាន​អនុវត្ត (ជំហាន) សម្រាប់កិច្ចការនីមួយៗ។

ដំណើរការ - នៅទីនេះយើងអាចជ្រើសរើស OS គោលដៅ គួរឱ្យភ្ញាក់ផ្អើល អ្នកថែមទាំងអាចជ្រើសរើស Mac OS ប៉ុន្តែនៅលើឃ្លាំងឯកជនវាមានតម្លៃថ្លៃណាស់ (បើធៀបនឹងលីនុច)។

ការប្រើប្រាស់ អនុញ្ញាតឱ្យអ្នកប្រើឡើងវិញនូវសកម្មភាពផ្សេងទៀត ឧទាហរណ៍ ដោយប្រើ actions/setup-java action យើងដំឡើងបរិស្ថានសម្រាប់ Java 11។

ដោយមានជំនួយពី ជាមួយ យើង​អាច​បញ្ជាក់​ប៉ារ៉ាម៉ែត្រ​ដែល​យើង​ចាប់​ផ្ដើម​សកម្មភាព សំខាន់​ទាំង​នេះ​គឺ​ជា​អាគុយម៉ង់​ដែល​នឹង​ត្រូវ​បញ្ជូន​ទៅ​សកម្មភាព។

អ្វីដែលនៅសេសសល់គឺត្រូវដំណើរការគម្រោងសាងសង់ជាមួយ Maven៖ 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 }}

ដើម្បីគ្របដណ្តប់ការធ្វើតេស្ត ខ្ញុំប្រើ codecov ដោយភ្ជាប់ជាមួយកម្មវិធីជំនួយ jacoco ។ codecov មានសកម្មភាពផ្ទាល់របស់វា ប៉ុន្តែវាត្រូវការសញ្ញាសម្ងាត់ដើម្បីធ្វើការជាមួយសំណើទាញរបស់យើង៖

${{ secrets.CODECOV_TOKEN }} — យើងនឹងឃើញការសាងសង់នេះច្រើនជាងម្តង អាថ៌កំបាំងគឺជាយន្តការសម្រាប់រក្សាទុកអាថ៌កំបាំងនៅក្នុង GitHub យើងអាចសរសេរនៅទីនោះ ពាក្យសម្ងាត់/tokens/hosts/urls និងទិន្នន័យផ្សេងទៀតដែលមិនគួរបញ្ចូលក្នុងមូលដ្ឋានកូដឃ្លាំង។

អ្នកអាចបន្ថែមអថេរទៅអាថ៌កំបាំងនៅក្នុងការកំណត់ឃ្លាំងនៅលើ GitHub៖

អ្នកអាចទទួលបាននិមិត្តសញ្ញានៅ codecov.io បន្ទាប់ពីការអនុញ្ញាតតាមរយៈ GitHub ដើម្បីបន្ថែមគម្រោងសាធារណៈ អ្នកគ្រាន់តែធ្វើតាមតំណដូចនេះ៖ ឈ្មោះអ្នកប្រើ GitHub/ [ឈ្មោះ repo] ។ ឃ្លាំងឯកជនក៏អាចបន្ថែមបានដែរ ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវផ្តល់សិទ្ធិ codecov ដល់កម្មវិធីនៅក្នុង Github ។

បន្ថែមកម្មវិធីជំនួយ jacoco ទៅឯកសារ POM៖

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

ឥឡូវនេះ codecov bot នឹងបញ្ចូលសំណើទាញរបស់យើងនីមួយៗ ហើយបន្ថែមក្រាហ្វការផ្លាស់ប្តូរការគ្របដណ្តប់៖

តោះបន្ថែមឧបករណ៍វិភាគឋិតិវន្ត

នៅក្នុងគម្រោងប្រភពបើកចំហរភាគច្រើនរបស់ខ្ញុំ ខ្ញុំប្រើ sonar cloud សម្រាប់ការវិភាគកូដឋិតិវន្ត វាងាយស្រួលណាស់ក្នុងការតភ្ជាប់ទៅ travis-ci ។ ដូច្នេះ​វា​ជា​ជំហាន​ឡូជីខល​ពេល​ធ្វើ​ចំណាក​ស្រុក​ទៅ GitHub Actions ដើម្បី​ធ្វើ​ដូច​គ្នា។ ទីផ្សារសកម្មភាពគឺជារឿងដ៏ត្រជាក់មួយ ប៉ុន្តែលើកនេះវាធ្វើឱ្យខ្ញុំខកចិត្តបន្តិច ព្រោះខ្ញុំបានរកឃើញសកម្មភាពដែលខ្ញុំត្រូវការ ហើយបន្ថែមវាទៅក្នុងដំណើរការការងារ។ ប៉ុន្តែវាបានប្រែក្លាយថា sonar មិនគាំទ្រការធ្វើការតាមរយៈសកម្មភាពសម្រាប់ការវិភាគគម្រោងលើ 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 បង្កើត ដោយមានជំនួយពី sonarcloud [bot] នឹងអាចចូលទៅក្នុង Git ដើម្បីទុកសារឱ្យយើងនៅក្នុងសំណើទាញ។

Dsonar.projectKey - ឈ្មោះនៃគម្រោងនៅក្នុង sonar អ្នកអាចឃើញវានៅក្នុងការកំណត់គម្រោង។

Dsonar.organization - ឈ្មោះរបស់អង្គការពី GitHub ។

យើងធ្វើសំណើរទាញ ហើយរង់ចាំ sonarcloud [bot] ចូលមកក្នុងមតិយោបល់៖

ការគ្រប់គ្រងការដោះលែង

ការស្ថាបនាត្រូវបានកំណត់រចនាសម្ព័ន្ធ ការធ្វើតេស្តត្រូវបានដំណើរការ ហើយយើងអាចធ្វើការចេញផ្សាយបាន។ តោះមើលពីរបៀបដែល GitHub Actions អាចធ្វើឱ្យការគ្រប់គ្រងការចេញផ្សាយកាន់តែងាយស្រួល។

នៅកន្លែងធ្វើការ ខ្ញុំមានគម្រោងដែលមានមូលដ្ឋានកូដនៅក្នុង bitbucket (អ្វីគ្រប់យ៉ាងគឺដូចជានៅក្នុងរឿងនោះ “ខ្ញុំសរសេរទៅ bitbucket ពេលថ្ងៃ ប្តេជ្ញាទៅ GitHub នៅពេលយប់”)។ ជាអកុសល bitbucket មិនមានឧបករណ៍គ្រប់គ្រងការចេញផ្សាយដែលភ្ជាប់មកជាមួយទេ។ នេះគឺជាបញ្ហាមួយ ពីព្រោះសម្រាប់ការចេញផ្សាយនីមួយៗ អ្នកត្រូវតែបង្កើតទំព័រមួយនៅក្នុងចំណុចប្រសព្វដោយដៃ ហើយបោះលក្ខណៈពិសេសទាំងអស់ដែលបានរួមបញ្ចូលនៅក្នុងការចេញផ្សាយនៅទីនោះ ស្វែងរកតាមវិមាននៃចិត្ត កិច្ចការនៅក្នុង jira ប្រព្រឹត្តនៅក្នុងឃ្លាំង។ មានឱកាសជាច្រើនក្នុងការធ្វើខុស អ្នកអាចភ្លេចអ្វីមួយ ឬបញ្ចូលអ្វីមួយដែលត្រូវបានចេញផ្សាយកាលពីលើកមុន ពេលខ្លះវាមិនច្បាស់ថាត្រូវចាត់ថ្នាក់សំណើទាញអ្វីនោះទេ - តើវាជាលក្ខណៈពិសេស ឬជួសជុលកំហុស ឬការធ្វើតេស្តកែសម្រួល ឬ ហេដ្ឋារចនាសម្ព័ន្ធ។

តើសកម្មភាព 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? បន្ទាប់មកវាមិនច្បាស់ថាប្រភេទណាដែលត្រូវដាក់វា ហើយម្តងទៀតអ្នកនឹងត្រូវដោះស្រាយវាដោយដៃ ដោយ 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 ដោយផ្អែកលើឯកសារដែលត្រូវបានផ្លាស់ប្តូរ។ ឧទាហរណ៍ យើងអាចសម្គាល់ថាជា [បង្កើត] សំណើរទាញណាមួយដែលមានការផ្លាស់ប្តូរទៅកាន់ថត .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 Actions (តាមរយៈ ssh តាមរយៈ scp និងការប្រើប្រាស់ docker-hub) ហើយខ្ញុំអាចនិយាយបានថា ទំនងជាអ្នកនឹងរកឃើញវិធីមួយដើម្បីផ្ទុកប្រព័ន្ធគោលពីរទៅម៉ាស៊ីនមេ មិនថាបំពង់បង្ហូរប្រេងរបស់អ្នកកោងយ៉ាងណានោះទេ។ គឺ

ខ្ញុំចូលចិត្តជម្រើសនៃការរក្សាហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលនៅកន្លែងតែមួយ ដូច្នេះសូមក្រឡេកមើលរបៀបដាក់ពង្រាយទៅកាន់ GitHub Packages (នេះគឺជាឃ្លាំងសម្រាប់មាតិកាគោលពីរ, npm, jar, docker)។

ស្គ្រីបសម្រាប់បង្កើតរូបភាព docker និងបោះពុម្ពវានៅក្នុងកញ្ចប់ 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 docker registry និងឈ្មោះរូបភាពរបស់យើង។ មាន​ល្បិច​មួយ​ចំនួន​ដែល​យើង​មិន​ទាន់​បាន​ជួប​នៅ​ឡើយ​ទេ៖

• សំណង់ដូចជា៖ echo “::set-output name=NAME::VALUE” អនុញ្ញាតឱ្យអ្នកកំណត់តម្លៃនៃអថេរក្នុងជំហានបច្ចុប្បន្ន ដូច្នេះវាអាចត្រូវបានអាននៅក្នុងជំហានផ្សេងទៀតទាំងអស់។
• អ្នកអាចទទួលបានតម្លៃនៃអថេរដែលបានកំណត់ក្នុងជំហានមុន តាមរយៈការកំណត់អត្តសញ្ញាណនៃជំហាននេះ៖ ${{step.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• អថេរ GITHUB_REPOSITORY ស្ដង់ដាររក្សាទុកឈ្មោះឃ្លាំង និងម្ចាស់របស់វា (“ម្ចាស់/repo-name”)។ ដើម្បីកាត់អ្វីគ្រប់យ៉ាងចេញពីបន្ទាត់នេះ លើកលែងតែឈ្មោះឃ្លាំង យើងនឹងប្រើវាក្យសម្ព័ន្ធ bash៖ ${GITHUB_REPOSITORY#*/}

បន្ទាប់យើងត្រូវបង្កើតរូបភាព docker៖

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 Packages Repository៖

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

ដើម្បីបង្ហាញពីកំណែនៃរូបភាព យើងប្រើខ្ទង់ទីមួយពី SHA hash នៃ commit - GITHUB_SHA វាក៏មានចំនុចពិសេសនៅទីនេះផងដែរ ប្រសិនបើអ្នកបង្កើតការស្ថាបនាបែបនេះមិនត្រឹមតែនៅពេលបញ្ចូលគ្នាជាមេប៉ុណ្ណោះទេ ប៉ុន្តែក៏យោងទៅតាមការបង្កើតសំណើរទាញផងដែរ។ ព្រឹត្តិការណ៍ បន្ទាប់មក SHA ប្រហែលជាមិនត្រូវគ្នានឹង hash ដែលយើងឃើញនៅក្នុង git history ទេ ពីព្រោះសកម្មភាព/សកម្មភាព checkout បង្កើត hash តែមួយគត់របស់វា ដើម្បីជៀសវាងសកម្មភាពជាប់គាំងនៅក្នុង PR ។

ប្រសិនបើអ្វីៗដំណើរការបានល្អ បន្ទាប់មកបើកផ្នែកកញ្ចប់ (https://github.com/antkorwin/github-actions/packages) នៅក្នុងឃ្លាំង អ្នកនឹងឃើញរូបភាព docker ថ្មី៖

នៅទីនោះ អ្នកក៏អាចឃើញបញ្ជីកំណែនៃរូបភាព docker ផងដែរ។

អ្វីដែលនៅសេសសល់គឺដើម្បីកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេរបស់យើងដើម្បីធ្វើការជាមួយបញ្ជីឈ្មោះនេះហើយចាប់ផ្តើមសេវាកម្មឡើងវិញ។ ខ្ញុំប្រហែលជានឹងនិយាយអំពីរបៀបធ្វើវាតាមរយៈ systemd ពេលមួយទៀត។

ការត្រួតពិនិត្យ

សូមក្រឡេកមើលជម្រើសដ៏សាមញ្ញមួយអំពីរបៀបធ្វើការត្រួតពិនិត្យសុខភាពសម្រាប់កម្មវិធីរបស់យើងដោយប្រើ GitHub Actions។ កម្មវិធីចាប់ផ្ដើមរបស់យើងមាន actuator ដូច្នេះយើងមិនចាំបាច់សរសេរ 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"}

អ្វីដែលយើងត្រូវការគឺត្រូវសរសេរភារកិច្ចដើម្បីពិនិត្យមើលម៉ាស៊ីនមេដោយប្រើ cron ហើយប្រសិនបើភ្លាមៗនោះគាត់មិនឆ្លើយតបមកយើងទេនោះយើងនឹងផ្ញើការជូនដំណឹងតាមតេឡេក្រាម។

ជាដំបូង ចូរយើងស្វែងយល់ពីរបៀបដំណើរការការងារ cron៖

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

វាសាមញ្ញ ខ្ញុំមិនអាចជឿថានៅក្នុង Github អ្នកអាចបង្កើតព្រឹត្តិការណ៍ដែលមិនសមនឹង webhooks ទាល់តែសោះ។ ព័ត៌មានលម្អិតមាននៅក្នុងឯកសារ៖ help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

តោះពិនិត្យមើលស្ថានភាពម៉ាស៊ីនមេដោយដៃតាមរយៈ 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"

ដំបូង យើងរក្សាទុកទៅក្នុងអថេរដែលម៉ាស៊ីនមេបានឆ្លើយតបទៅនឹងសំណើនោះ នៅជំហានបន្ទាប់ យើងពិនិត្យមើលថាស្ថានភាពគឺ 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 អ្នកអាចអានអំពីរបៀបទទួលបាន bot token និង chat id នៅក្នុងឯកសារ៖ github.com/appleboy/telegram-action

កុំភ្លេចសរសេរអាថ៌កំបាំងនៅលើ Github: URL សម្រាប់ server និង tokens សម្រាប់ telegram bot។

បទប្រាក់រង្វាន់ - JIRA សម្រាប់អ្នកខ្ជិល

ខ្ញុំបានសន្យាថាយើងនឹងត្រលប់ទៅ JIRA ហើយយើងបានត្រឡប់មកវិញ។ រាប់រយដងដែលខ្ញុំបានសង្កេតឃើញស្ថានភាពមួយនៅការក្រោកឈរឡើង នៅពេលដែលអ្នកអភិវឌ្ឍន៍បានបង្កើតលក្ខណៈពិសេសមួយ រួមបញ្ចូលគ្នានូវសាខាមួយ ប៉ុន្តែភ្លេចទាញបញ្ហាទៅក្នុង JIRA ។ ជាការពិតណាស់ ប្រសិនបើអ្វីៗទាំងអស់នេះត្រូវបានធ្វើនៅកន្លែងតែមួយ វានឹងកាន់តែងាយស្រួល ប៉ុន្តែតាមពិតយើងសរសេរកូដនៅក្នុង IDE បញ្ចូលសាខាទៅក្នុង bitbucket ឬ GitHub ហើយបន្ទាប់មកអូសកិច្ចការទៅក្នុង Jira សម្រាប់ការនេះ យើងត្រូវបើក ​​windows ថ្មី។ ពេលខ្លះចូលម្តងទៀត និងល។ នៅពេលអ្នកចងចាំយ៉ាងល្អឥតខ្ចោះនូវអ្វីដែលអ្នកត្រូវធ្វើបន្ទាប់ នោះគ្មានចំណុចអ្វីក្នុងការបើកក្តារម្តងទៀតទេ។ ជាលទ្ធផល នៅពេលព្រឹកនៅពេលក្រោកឈរ អ្នកត្រូវចំណាយពេលធ្វើបច្ចុប្បន្នភាពផ្ទាំងកិច្ចការ។

GitHub ក៏នឹងជួយយើងក្នុងកិច្ចការទម្លាប់នេះផងដែរ សម្រាប់ការចាប់ផ្តើម យើងអាចទាញបញ្ហាដោយស្វ័យប្រវត្តិទៅក្នុងជួរឈរ code_review នៅពេលយើងដាក់សំណើទាញ។ អ្វីដែលអ្នកត្រូវធ្វើគឺធ្វើតាមអនុសញ្ញាដាក់ឈ្មោះសាខា៖

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

ឧទាហរណ៍ ប្រសិនបើកូនសោគម្រោង "GitHub Actions" គឺ GA នោះ GA-8-jira-bot អាចជាសាខាសម្រាប់អនុវត្តភារកិច្ច GA-8 ។

ការរួមបញ្ចូលជាមួយ JIRA ដំណើរការតាមរយៈសកម្មភាពពី Atlassian ពួកគេមិនល្អឥតខ្ចោះទេ ខ្ញុំត្រូវតែនិយាយថាពួកគេមួយចំនួនមិនដំណើរការសម្រាប់ខ្ញុំទាល់តែសោះ។ ប៉ុន្តែយើងនឹងពិភាក្សាតែអ្នកដែលពិតជាដំណើរការ និងត្រូវបានប្រើប្រាស់យ៉ាងសកម្ម។

ដំបូងអ្នកត្រូវចូលទៅ 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 អ្វីទាំងអស់ដែលវាត្រូវការគឺលេខសម្គាល់បញ្ហាដែលទទួលបានក្នុងជំហានមុន និងការអនុញ្ញាតក្នុង JIRA ដែលយើងបានធ្វើខាងលើ។

នៅក្នុងវិធីដូចគ្នានេះ អ្នកអាចអូសកិច្ចការនៅពេលបញ្ចូលទៅក្នុងមេ និងព្រឹត្តិការណ៍ផ្សេងទៀតពីលំហូរការងារ GitHub ។ ជាទូទៅ វាទាំងអស់គឺអាស្រ័យលើការស្រមើលស្រមៃ និងបំណងប្រាថ្នារបស់អ្នក ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មដំណើរការធម្មតា។

ការរកឃើញ

ប្រសិនបើអ្នកក្រឡេកមើលដ្យាក្រាម DEVOPS បុរាណ យើងបានគ្របដណ្តប់គ្រប់ដំណាក់កាលទាំងអស់ លើកលែងតែប្រតិបត្តិការ ខ្ញុំគិតថាប្រសិនបើអ្នកព្យាយាម អ្នកអាចស្វែងរកសកម្មភាពមួយចំនួននៅក្នុងទីផ្សារសម្រាប់ការរួមបញ្ចូលជាមួយប្រព័ន្ធជំនួយ ដូច្នេះយើងនឹងសន្មត់ថាបំពង់បង្ហូរប្រេងបានប្រែក្លាយ។ ឱ្យបានហ្មត់ចត់ ហើយការសន្និដ្ឋានអាចត្រូវបានទាញដោយផ្អែកលើការប្រើប្រាស់របស់វា។

ប្រុស:

• ទីផ្សារជាមួយនឹងសកម្មភាពដែលត្រៀមរួចជាស្រេចសម្រាប់គ្រប់ឱកាស នេះគឺពិតជាឡូយណាស់។ នៅក្នុងពួកគេភាគច្រើន អ្នកក៏អាចមើលកូដប្រភពដើម្បីយល់ពីរបៀបដោះស្រាយបញ្ហាស្រដៀងគ្នា ឬប្រកាសសំណើលក្ខណៈពិសេសទៅកាន់អ្នកនិពន្ធដោយផ្ទាល់នៅក្នុងឃ្លាំង GitHub ។
• ការជ្រើសរើសវេទិកាគោលដៅសម្រាប់ការជួបប្រជុំគ្នា៖ លីនុច, mac os, វីនដូគឺជាមុខងារគួរឱ្យចាប់អារម្មណ៍ណាស់។
• កញ្ចប់ Github គឺជារឿងដ៏អស្ចារ្យ វាងាយស្រួលក្នុងការរក្សាហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលនៅកន្លែងតែមួយ អ្នកមិនចាំបាច់រុករកតាមបង្អួចផ្សេងៗគ្នានោះទេ អ្វីគ្រប់យ៉ាងគឺស្ថិតនៅក្នុងកាំនៃការចុចកណ្ដុរមួយ ឬពីរ ហើយត្រូវបានរួមបញ្ចូលយ៉ាងល្អឥតខ្ចោះជាមួយសកម្មភាព GitHub ។ ការគាំទ្រការចុះបញ្ជី Docker នៅក្នុងកំណែឥតគិតថ្លៃក៏ជាអត្ថប្រយោជន៍ដ៏ល្អផងដែរ។
• GitHub លាក់អាថ៌កំបាំងនៅក្នុងកំណត់ហេតុបង្កើត ដូច្នេះការប្រើវាដើម្បីរក្សាទុកពាក្យសម្ងាត់ និងសញ្ញាសម្ងាត់គឺមិនគួរឱ្យខ្លាចនោះទេ។ ក្នុងអំឡុងពេលពិសោធន៍ទាំងអស់របស់ខ្ញុំ ខ្ញុំមិនអាចមើលឃើញអាថ៌កំបាំងនៅក្នុងទម្រង់ដ៏បរិសុទ្ធរបស់វានៅក្នុងកុងសូលនោះទេ។
• ឥតគិតថ្លៃសម្រាប់គម្រោងប្រភពបើកចំហ

គុណវិបត្តិ:

• YML អញ្ចឹងខ្ញុំមិនចូលចិត្តគាត់ទេ។ នៅពេលធ្វើការជាមួយលំហូរបែបនេះ សារដែលប្រើញឹកញាប់បំផុតដែលខ្ញុំមានគឺ "ជួសជុលទ្រង់ទ្រាយ yml" ពេលខ្លះអ្នកភ្លេចដាក់ផ្ទាំងនៅកន្លែងណាមួយ ជួនកាលអ្នកសរសេរវាខុស។ ជាទូទៅ ការអង្គុយនៅមុខអេក្រង់ជាមួយ protractor និងអ្នកគ្រប់គ្រង មិនមែនជាបទពិសោធន៍ដ៏រីករាយបំផុតនោះទេ។
• DEBUG ការកែកំហុសលំហូរជាមួយនឹងការប្រព្រឹត្ត ការដំណើរការការស្ថាបនាឡើងវិញ និងការបញ្ជូនទៅកាន់កុងសូលមិនតែងតែងាយស្រួលនោះទេ ប៉ុន្តែវាជាប្រភេទ "អ្នកហួសពេលហើយ" ច្រើនជាង។ អ្នកធ្លាប់ធ្វើការជាមួយ IDEA ដ៏ងាយស្រួល នៅពេលដែលអ្នកអាចបំបាត់កំហុសអ្វីមួយ។ .
• អ្នកអាចសរសេរសកម្មភាពរបស់អ្នកលើអ្វីក៏បាន ប្រសិនបើអ្នករុំវានៅក្នុង Docker ប៉ុន្តែមានតែ javascript ប៉ុណ្ណោះដែលត្រូវបានគាំទ្រ ជាការពិតនេះគឺជាបញ្ហានៃរសជាតិ ប៉ុន្តែខ្ញុំចូលចិត្តអ្វីផ្សេងទៀតជំនួសឱ្យ js ។

ខ្ញុំសូមរំលឹកអ្នកថា ឃ្លាំងដែលមានស្គ្រីបទាំងអស់គឺនៅទីនេះ៖ github.com/antkorwin/github-actions

សប្តាហ៍ក្រោយខ្ញុំនឹងសម្តែងជាមួយ របាយការណ៍ នៅក្នុងសន្និសីទ Heisenbug 2020 Piter ។ ខ្ញុំ​នឹង​ប្រាប់​អ្នក​មិន​ត្រឹម​តែ​របៀប​ជៀសវាង​កំហុស​ពេល​រៀបចំ​ទិន្នន័យ​តេស្ត​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​ចែករំលែក​អាថ៌កំបាំង​នៃ​ការ​ធ្វើ​ការ​ជាមួយ​សំណុំ​ទិន្នន័យ​ក្នុង​កម្មវិធី Java ផង​ដែរ!

ប្រភព: www.habr.com