これはなに

ざっとCircle CIに入門したので自分用のメモ

動機

CI/CDがある環境でデプロイしたことあるけど、CI/CDがなんたるかを自分の言葉でうまく説明できないなと思った
開発プロセスに関わることだしQAエンジニアも知っておくべきでは？と思った

ゴール

自分の言葉でCI/CDやその必要性ついて説明できる
CI/CDツール（Circle CI）を触ってみる
Circle CIの設定ファイル（config.yml）に書かれていることがなんとなくわかる

Circle CIを選んだのは会社で使っていたから

CI/CDとは

CI（継続的インテグレーション）
- 開発者がこまめ(継続的)に作業ブランチをコミットし、masterマージする前に自動でビルド・静的解析・テストが実行されること
CD（継続的デプロイメント）
- 新しい変更を自動的に本番環境に反映すること。CIをさらに拡張したもの
導入すると何が嬉しいの？
- コミット時点で静的解析・テスト実行することでより早く不具合が見つかる
- ビルド・リリースが自動化され開発者の手作業が減る
- このような特徴から、短期間で何度もリリースを行うアジャイル開発と相性が良い

CI/CDの仕組み

開発に必要なステップを自動化したものを”CI/CDパイプライン”と呼ぶ
CIが動くきっかけは、コード管理ツール(GitHubなど)にプッシュした時
CDが動くきっかけは、CIが全て通ってmasterマージした時。最終的に本番にデプロイするかは人間が判断する
ビルド＝Dockerイメージのpull、依存パッケージのインストール(bundle install)、コンパイルなど
テスト＝ユニットテスト、静的解析(Rubocop)など
デプロイ＝本番環境や検証環境にリリースすること
（感想）今までCI/CDの差をそこまで意識してなかったけど、開発時に行うステップ＝インテグレーション・本番にデプロイするステップ＝継続的デプロイメントって区別なんだね

参考：https://circleci.com/ja/blog/what-is-ci-cd

CI/CDツール

メジャーどころをいくつかあげてみる

Jenkins

オープンソース
Jenkins用のサーバーを自分で建てる必要がある
Jenkinsおじさんが有名（？）

Circle CI

SaaSなのでサーバー建てる必要なし

GitHub Actions

SaaSなのでサーバー建てる必要なし
安い

Cicle CI

とりあえず触ってみる

下準備

なんか適当なリポジトリ用意してGitHubにプッシュする（雑すぎる説明）

とりあえず何かしらのメソッドとそれをテストするものがあれば良さげなので、Rubyで以下のようなものを用意した

こんにちはするメソッド

class Sample
  def hello
    'Hello, world!'
  end
end

こんにちはするメソッドのテスト

require './sample'
require 'test/unit'

class SampleTest < Test::Unit::TestCase
  def test_greeting
    sample = Sample.new
    assert_equal 'Hello, world!', sample.hello
  end
end

Circle CIで色々する

UI上の説明が丁寧なのでそれに従って進めればOK

Circle CIのアカウント作ります
GitHubなどと連携します
Circle CIでCreate Projectボタン押す
- GitHub上のリポジトリを選ぶ画面が出てくるので、下準備で作ったリポジトリを選ぶ
- Circle CIからGit HubにSSHできるようにキー発行する
「GitにPush」みたいなボタンが現れる(多分)ので押す
- GitHubでプッシュされた内容確認すると.circleciディレクトリが生成されてる。そこにconfig.ymlがある。
CIが走る

デフォルトのconfig.ymlままだとテストが動かないので、以下の「ここを直した」の部分を修正してプッシュする

docker image
jobs > test > steps > runのcommand

  # Couldn't automatically generate a config from your source code.
  # This is a generic template to serve as a base for your custom config
  # See: https://circleci.com/docs/configuration-reference
  version: 2.1
  jobs:
    test:
      docker:
        # ここを直した
        - image: cimg/ruby:3.3
      steps:
        - checkout
        # Replace this with a real test runner invocation
        - run:
            name: Run tests
            # ここを直した
            command: ruby sample01_test.rb
            # command: echo 'replace me with real tests!' && false
    build:
      docker:
        - image: cimg/ruby:3.3
      steps:
        - checkout
        # Replace this with steps to build a package, or executable
        - run:
            name: Build an artifact
            command: touch example.txt
        - store_artifacts:
            path: example.txt
    deploy:
      docker:
        - image: cimg/ruby:3.3
      steps:
        # Replace this with steps to deploy to users
        - run:
            name: deploy
            # ここを直した
            command: echo 'deploy'
            # command: '#e.g. ./deploy.sh'

CIが走る。pipelineのStatusがSuccessになった🙌

config.yml

yamlファイルで利用するキーについてのざっくり理解メモ。詳しいことは公式ドキュメントを参照

Version、Job、workflowが基本的な（オーソドックスな？よく使う？）キーっぽい
Jobs > job名 > コンテナのイメージ指定 / ( job内で行う処理の定義 > step > 各処理のコマンド) みたいな構成になっている
workflowsは、jobをどのように実行するか定義（オーケストレーション）するもの
- 「前提として、このjobが終わってる必要があるよ」（シーケンシャル）や「何時に実行するよ」（スケジューリング）などさまざまな方法を指定できる
なんとなくのイメージ図
executors
- docker imageなどの実行環境をjobごとに何度も同じ内容で定義するのは非効率なので、executorsで定義することでDRYにかける

nagaminaの日記

QAエンジニアです〜。学んだことなどの備忘録

QAエンジニアがCircle CIに入門してみた