はじめてのCI

CIとはなにか

Continuous Integrationの略。
翻訳すると「継続的インテグレーション」

インテグレーションとは

統合、統一、融合、一体化、集積などの意味を持つ英単語。複数の異なる要素を組み合わせて一つにしたり、一体として機能するよう調整すること。一般的な外来語としては定着しておらず、様々な専門分野で英語の専門用語の訳語の一部として用いられることが多い。

CIとは以下を行う手法である。

1. コードの変更をリポジトリにマージする
2. 定期的・自動的にビルド・テストする

コードの変更を(中央の)リポジトリに頻繁にマージし、かつ「定期的・自動的」に「ビルド・テスト」を行うという手法です。リポジトリに頻繁にマージすることで複数人での作業の衝突や競合を早期に発見し、自動化しておくことでリリースまでの時間を短縮できるといった効果があります。CI(continuous integration)と略して呼ばれることも多いです。

定期的・自動的にビルドする仕組みを作っておくことで、ビルドエラーになっても気付けるようになる。

参考

CI(継続的インテグレーション)とは？

継続的インテグレーション・継続的デリバリー – 「若手エンジニアのためのDevOps入門」 さくらのナレッジ

CIサービスの分類

ここでは比較ではなく、サービスの種類の紹介だけする。

• CircleCI
• TravisCI
• GitLabCI
• GitHubActions
• AWSCodeBuild
• GoogleCloudBuild
• Jenkins
• Concourse
• Drone
• モバイル特化
  • Bitrise

参考

CI 大好きエンジニアによる CI サービス (ツール) の分類・比較と選定方法・学習方法

GitHub Actionsを使ったCi実装例

GitHub Actionsでよく出る単語

ハンズオンの前に知らない単語がいっぱい出てきたので、基本的なものを調べた。

ワークフロー

リポジトリに追加する自動化された手順の事を指す。
GitHub Actionsを実行するにはworkflowsディレクトリ配下にyamlファイルを設置する必要がある。

Project名/.github/workflows/

基本的にワークフローを実行するためにはスケジュールかイベントの指定をする必要がある。
※スケジュールはそのまんまの意味で指定した時間の事を指す

以下はワークフローのサンプルです。
GitHub 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もしくはプルリクエストが作成された場合、GitHubからアクティビティを発生させることができます。 リポジトリディスパッチ webhook を使用して、外部イベントが発生したときにワークフローをトリガーすることもできます。 ワークフローのトリガーに使用できるイベントの完全なリストについては、ワークフローをトリガーするイベントを参照してください。

ワークフローを実行するためのトリガー。
よく使いそうなのは

• スケジュール
  • 例
    • 毎日0時
• プルリクエスト
  • 例
    • プルリクエストを作成した時
    • プルリクエストを編集した時
• issues
  • 例
    • issueを作成した時
    • issueを編集した時

以下はyamlへの記述例

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

ジョブ

ジョブが仮想環境上で実行されるステップの集合体。
仮想環境はジョブごとに新しいインスタンスで実行される。

ジョブの中身は以下の構成で出来ている。

• ジョブ
  • ステップ
    • アクション

ステップ
ジョブの中で実行されるアクションを束ねたものです。
ジョブの中にはステップが1つ以上必要。

アクション
ステップ内で実行するタスクの事を指す。

アクションには以下3種類があります。

• GitHubが提供するアクション
• GitHub Marketplaceで公開されたアクション
  • SlackやAWSのような外部サービスのアクションは大体ここに公開されている
• 独自で定義したアクション
  • 上記2つに求めるアクションがない場合は自分で定義して使用することが可能である
    • 定義する方法
      • JavaScript アクションを作成する
      • Docker コンテナのアクションを作成する

上記の事をふまえて、次のサンプルテンプレートを読み解いてみた。
composerが実行できるかのtestをするワークフローと解釈しました。

composer validateコマンド

依存関係をキャッシュしてワークフローを高速化-GitHubDocs

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

基本的なGitHub Actionsの使い方は以上です。
設定方法は多くあるため、やりたいことが明確であれば公式ドキュメントで検索すればだいたいは見つかると思います！

CIおじさんになるぜ〜