これはなに

ざっと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にかける

2023年4月時点で、QAエンジニアにジョブチェンジして3ヶ月が経ちました。その際、会社のブログで「バックエンドエンジニアからQAエンジニアになって3ヶ月でやったこと」的なブログを書きました。

改めて振り返りをしたいのと、もう少し個人の思い的な部分も残しておきたく、個人ブログにも書こうと思います。

なぜQAエンジニアになったのか

開発エンジニアとして今の勤め先にジョインしたのですが、以下の課題を感じていました。

10年以上続いているサービスなのに仕様に関するドキュメントなどがあまり残っておらず、既存仕様の調査に多くの時間がかかりスムーズに開発できない
QAエンジニアがおらずプロジェクトメンバーで集まり動作確認する会を開発完了後のテストとしており、「テストは十分だっただろうか」と不安を感じた
上記のことなどもありチームメンバーが伸び伸びと働けていない部分もあるように感じ、チームが安心して働ける環境を作りたいと思った

そんなモヤモヤを抱えている中、QAエンジニアに興味を持った出来事が二つありました。

ひとつめは、知人の開発エンジニアと話していた時に「QAエンジニアがチームにいた時は開発がしやすかった」という話が出たことです。私はこれがきっかけでQAエンジニアという仕事を知りました。

ふたつめは、開発エンジニアとして参加した社外勉強会にQAエンジニアの方が登壇していたことです。その方の話を聞き"Three Amigos"という考えを知り、自分はどういう立場でプロダクト作りに関わりたいのか改めて考え直そうと思いました。

これらの出来事を受けQAの仕事について調べていくうちに「QAの活動は、企画職/開発職などプロダクトに関わるメンバーがよりプロダクトに向きあいやすくなることに、繋がるかも」と感じました。

また、以下のような自分の価値観ともマッチするかもと思いました。

様々な人と話し合いながら物事をチームで進めたい
自分の業務に線引きをしすぎず、自分のできることはなんでもやっていきたい。そのため要件検討の段階からリリース前のテストまで幅広い開発工程に関わりたい。

このような経緯で「開発に関わるメンバーが安心して素早くユーザーに価値ある製品を届けるサポートがしたい」と思いQAエンジニアになりました。

QAエンジニアになって3ヶ月で取り組んだこと

弊社では主に２つのプロダクトがあり、開発エンジニアとして携わっていたプロダクトとは別プロダクトのチームにQAとしてジョインすることになりました。

私がQAエンジニアにジョブチェンジする少し前に、弊社に１人目のQAエンジニアがジョインしていたのでメンターとしてついてもらいました。

既存テストケースの実行

まずは既存テストケースを全て実行することから始めました。

テストケース実行を通して得られたこととしては、

ざっくりと仕様を把握することができた。また、全体のボリュームが掴めた。
テストケースをどのように作っているのかぼんやり把握することができた。
不具合時の報告方法(チケットの起票方法)など、チームのルールを把握できた。
テストケース管理ツールに慣れることができた。(Qaseというツールを使っているのですが、シンプルで直感的に使えて良かったです)

などが挙げられます。個人的にはテストケースの実行から始めることは、最初の一歩としてのハードルが低く業務のイメージもつきやすく非常に良かったです。

他社さんがどのようにQAのオンボーディングを進めているのかとても興味があります。

テストプロセスを一通り経験

次に開発案件を通して、テストプロセスを一通り経験しました。

特に難しく感じたのは、「仕様書のレビュー」と「テストケースの作成」です。

弊社では、要件定義段階からQAチームが参画し、プロジェクトオーナーが書いた仕様書をレビューします。例えば、誤字脱字のチェック、既存仕様との矛盾のチェック、よりユーザーが使いやすくなるような提案などを行っています。最初の頃は、開発エンジニアの時の習慣が抜けず「どうやったらシステムとして実現できるか？」と考えがちでした。しかし、それ以前に「その仕様で本当にユーザーの課題を解決できるか」という目線を持つことが必要だなと感じました。

レビュー観点を広げる方法として、モブ作業を行って他のメンバーの観点を盗み身につけるということをしました。具体的には、仕様書をレビューするときにslackハドルなどで画面共有しながら、お互いに気になった箇所を述べていくということをしました。その際に、「なぜそこが気になったのか」「なぜその考えに至ったのか」などを聞くようにしました。そのおかげで、自分では気が付かなった指摘事項に関しても、導き出し方がわかるようになりよりレビュー観点が広がりました。

テストケースの作成に関しては、誰が見ても何をしたいかテストの意図がわかるものにすることが非常に難しいなと今でも頭を悩ませています。開発エンジニアをしていた時に、「自分の書いたコードをしばらく経ってから見返すとわからない」という事象に直面することが何度かありましたが、自然言語で記入しているテストケースでも同じことが起きるんだなと思いました。

わかりにくくなる理由としては、暗黙知が含まれていることなどが考えられると思いました。なので、他の人にテストケースをレビューしてもらい、暗黙知の排除につとめました。

また、社外の勉強会でテストケースの作成に関わるものがあれば積極的に参加しました。特に、JaSST’23 Tokyoでのテスト設計コンテスト U-30クラスのセッションは、テスト設計とはこんなに奥が深いものなのかと感銘を受けたのを今でも覚えています。

３ヶ月で得たこと・今後やっていきたいこと

個人としての一番の成果は、QAとしてテストプロセスを一通り経験できたことだと思っています。ただ、プロセスの各工程をさらに深掘りしていく必要があります(特にテスト設計など)。また、幅広いテストタイプに対応できるようになりたいですし、今はシステムテスト(E2Eテスト)を主に担当していますが他のテストレベルの知識も身につけていきたいと考えております。学べることが無限に広がっていてわくわくしますね。

チームの成果としては、QAチームに人が増えたことでライブラリアップデート・リファクタ時などにリグレッションテストを実施できるようになったことかと思っております。しかし、実行に時間がかなりかかっており、素早いデプロイのボトルネックになっているように感じます。必要な部分はテストを自動化するなりして、質とスピードを担保していきたいです。（※2023年10月現在自動化ツールを導入してチームで進めることになったので、実現したいこと第一歩は達成）

nagaminaの日記

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

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