최초의 CI

CI 소개

Continuus Integration의 약칭입니다.
지속적 포인트
이른바 적분
종합, 통일, 융합, 일체화, 집적 등의 뜻이 있는 영어 단어.여러 가지 다른 요소를 하나로 조합하거나 하나로 조정한다.일반적인 외래어로는 정착되지 않고 다양한 전문 분야에서 영어 전문 용어의 일부로 많이 쓰인다.
CI는 다음과 같은 방법입니다.

코드의 변경을 창고에 통합

정기적이고 자동화된 구축 테스트

코드의 변경 사항을 창고에 자주 통합하고 정기적으로 자동으로 구축 테스트를 하는 방법입니다.빈번한 창고 합병을 통해 여러 사람의 업무 중의 충돌과 충돌을 조속히 발견할 수 있고 자동화를 통해 발표 시간을 단축할 수 있다.CI라고도 부른다.
정기적이고 자동적으로 구축되는 메커니즘을 구축함으로써 구축 오류가 발생하더라도 알아차릴 수 있다.
참고 자료
CI란?
지속적 포인트·지속적 배송 –'젊은 엔지니어를 위한 DevOps 입문'벚꽃 해설

CI 서비스의 분류

여기는 비교 없이 서비스의 종류만 소개합니다.

CircleCI

TravisCI

GitLabCI

GitHubActions

AWSCodeBuild

GoogleCloudBuild

Jenkins

Concourse

Drone

모바일 특화

Bitrise

참고 자료
CI 엔지니어가 CI 서비스(도구)에 대한 분류, 비교 및 선택 방법, 학습 방법

GiitHub Action을 사용한 Ci 설치 예

GiitHub Action에서 많이 나오는 단어.

모르는 단어가 많이 나와서 기본적인 걸 찾아봤어요.

작업흐름

창고에 추가하는 자동화 프로그램을 가리킨다.
GiitHub Actions를 실행하려면 workflows 디렉토리에 yaml 파일을 설정해야 합니다.

Project名/.github/workflows/

기본적으로 작업 흐름을 집행하기 위해서는 시간표나 이벤트를 지정해야 한다.
※ 시간표는 시간을 지정한다는 뜻
다음은 작업 절차의 샘플입니다.
GiitHub Actions php 템플릿을 지정할 때 생성됩니다.

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Validate composer.json and composer.lock
      run: composer validate --strict

    - name: Cache Composer packages
      id: composer-cache
      uses: actions/cache@v2
      with:
        path: vendor
        key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}
        restore-keys: |
          ${{ runner.os }}-php-

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress

    # Add a test script to composer.json, for instance: "test": "vendor/bin/phpunit"
    # Docs: https://getcomposer.org/doc/articles/scripts.md

    # - name: Run test suite
    #   run: composer run-script test

이벤트

활동은 워크플로우를 트리거하는 특정 활동입니다.예를 들어 제출을 창고로 미루거나 Issue를 만들거나 요청을 종료하면 GiitHub에서 이벤트를 생성할 수 있습니다.창고 분리기 웹훅을 사용하여 외부 이벤트가 발생할 때 작업 절차를 터치할 수도 있습니다.워크플로우를 트리거할 수 있는 이벤트의 전체 목록은 워크플로우를 트리거하는 이벤트를 참조하십시오.
실행 워크플로우를 트리거합니다.
자주 쓰는 건...

일정

예

매일 0시

재설정 요청

예

취소 요청이 생성된 경우

당김 요청을 편집한 경우

issues

예

issue 제작 시

issue 편집 시

다음은yaml의 기술 예이다

on:
  ## mainブランチにPushした時
  push:
    branches: [ main ]
  ## mainブランチに対してプルリクエストを作成した時
  pull_request:
    branches: [ main ]

과업

가상 환경에서 작업보의 집합을 수행합니다.
모든 작업은 새로운 실례에서 가상 환경을 실행합니다.
임무의 내용은 다음과 같이 구성된다.

작업

단계

동작

단계
임무에서 수행된 작업을 취합합니다.
임무 중에는 하나 이상의 절차가 필요하다.
액션
단계 내에서 수행되는 임무를 나타냅니다.
동작은 다음과 같은 세 가지가 있다.

GiitHub에서 제공하는 작업

GiitHub Marketplace에서 공개된 동작입니다.

슬랙과 AWS 같은 외부 서비스의 조작은 기본적으로 여기에 공개된다

독립적으로 정의된 동작

상기 두 가지 요구 사항이 없는 상황에서 스스로 정의하고 사용할 수 있다

정의된 방법

JavaScript 작업 만들기

Docker 컨테이너 만들기 작업

상술한 상황에 따라 아래의 견본 템플릿을 해독해 보았다.
composier의test 작업 절차를 실행할 수 있는지 설명합니다.
명령
캐시 종속성 워크플로우

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]


jobs:
  ##ジョブの名前
  build:
  
    ##ジョブが実行される環境
    runs-on: ubuntu-latest

    steps:
    ## GitHubから提供されているアクションを使えるようになる
    - uses: actions/checkout@v2

    ## composer.jsonが有効化をチェックする
    - name: Validate composer.json and composer.lock
      run: composer validate --strict

    ## ワークフローの実行時間を早くするために依存関係をキャッシュする
    - name: Cache Composer packages
      id: composer-cache
      ## https://github.com/actions/cache/blob/main/examples.md#php---composer
      uses: actions/cache@v2
      with:
        path: vendor
        key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}
        restore-keys: |
          ${{ runner.os }}-php-

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress

기본적인 GiitHub Action 사용 방법은 다음과 같습니다.
설정 방법이 많기 때문에 하고 싶은 일이 명확하면 공식 문서에서 검색하면 기본적으로 찾을 수 있습니다!
CI 아저씨가 되겠습니다.