「CI/CDビギナーのタケシくん」はどのように自動化を成功させたのか フィックスポイントが解説：「Cloud Operator Days Tokyo 2022」セミナーレポート＃7
Cloud Operator Days Tokyo 2022のセッション「目指せ！安心・安定のサービスリリース 〜CI/CD で立ち向かうタケシくんの奮闘記〜」にてフィックスポイントの當麻遼平氏は、自動化の取り組み方について初心者目線で解説した。
【訂正：2022年9月5日12時25分 サービス名が誤っていたため、修正いたしました。誤「Playwrite」→正「Playwright」】
「（サービスを）リリースしたら終わり」という時代はもう過去のものだ。現在は機能の追加やバグの修正などリリース後の改修作業が発生するのが当たり前で「リリースしてからが始まり」といえる。
頻繁に発生するリリース作業を毎回手作業で実施しては非効率だし、ミスが発生する可能性も高い。そこで「CI/CD」（継続的インテグレーション／継続的デリバリー）の仕組みを採用する企業も増えている。
だが、例えば「新卒1年目のエンジニア」など、これまでそういった仕組みを使ったことのないエンジニアにとって導入のハードルは高い。
フィックスポイントの當麻遼平氏（特別プロジェクト推進室 システムエンジニア）は、Cloud Operator Days Tokyo 2022のセッション「目指せ！安心・安定のサービスリリース 〜CI/CD で立ち向かうタケシくんの奮闘記〜」にてそうした“CI/CDビギナー”に向けて、「タケシくん」という架空の新人エンジニアを主人公にして、開発の各段階においてCI/CDをどのように活用すべきかについて紹介した。
「多少はあるかも」と思っていたバグが大量に発生
第1話は、未経験ながらもPoC（概念実証）を担当することになったタケシくんの苦悩から始まる。
PoCの担当者になったタケシくんは焦っていた。PoCプロジェクトの期限が迫っているのに、レビューや打ち合わせで開発の時間が取れない状態が続いていたからだ。何かしら成果を出さなければと考えたタケシくんは実装を急ぐあまり、テストやフォーマットの確認などを自分の感覚で行っていた。その結果、期限までに実装を終えることができたものの、QA（品質保証）チェックで大量のバグが見つかってしまった、といったストーリーだ。
「多少のバグはあるかもしれないけど大丈夫だろう、とタケシくんは高をくくっていた。しかし、結果として大量のバグが見つかり、しかもそれもほとんどが単純なバグばかりだった。タケシくんの経験やスキルの不足はあるかもしれないが、バグを見逃した大きな要因はフォーマットの修正やコードの検証（テストなど）を手動で実施していたことだ」
當麻氏は、手動でチェックしているとフォーマットにばらつきが出てしまい、結果として統一感のないコードになる可能性が高いと指摘する。
「フォーマットが異なるとレビュー項目や修正回数が増え、バグが生まれやすい環境になってしまう。テストを手動で実施しているとそもそも“テストのし忘れ”が発生する可能性もある。バグの修正も重要だが、開発するサービスの品質を高めるためには、こうした環境を改善する必要がある」
劇中のタケシくんはこの課題に対し、「GitHub Actions」を使うことにした。これを使えば、ymlファイルに記載するだけで確認作業（Lintチェック、単体テスト、マイグレーション検証、イメージビルドなど）を自動実行できる。それによってコードの変更（プッシュ）のたびに自動で静的解析とテストができるため、「タケシくんは本質的な部分に注力できるようになった」と當麻氏は語る。
「確認すべきこと」に追われる毎日
第2話は、次々に舞い込んでくる改善要望の対応に追われるタケシくんの話だ。
PoCを何とか乗り切ったタケシくんだが、今度は関係者からの改善要望で苦労していた。改善要望が来るということはサービスに期待しているということでもある。タケシくんは次々と修正とリリースを重ねていった。サービスの構成は複雑になっていき、やがて「1つの修正に対し、確認すべき項目」が増えていった。そのため、リリースをするまでの確認事項が「雪だるま式に増えていった」と當麻氏は解説する。
「タケシくんの場合、1つのリリースで500件を超える項目を確認しなければならなくなった。確認に追われてしまいリリース頻度は落ちてしまった」
とはいえ、リリース前の確認をおろそかにはできない。當麻氏はこの課題に有効な取り組みとして「E2Eテスト」（End to End Test）を挙げる。E2Eテストは文字通り初めから終わりまでを通してテストをすることだ。Webサービスで言えばユーザーがログインするところから始まり、サービスを利用してログアウトするまでの一連の流れを試すことになる。
「継続的にリリースを繰り返すようなサービスではE2Eテストが不可欠だ。だが、リリースのたびに手動でE2Eテストを実施するのは効率が悪い。重要なのはこのテストを自動化することだ」
早速、タケシくんはE2Eテストの自動化の準備に取り掛かった。GitHub Actionsを使い、プルリクエストなどの機能追加時と毎日決まった時間にE2Eテストを実行させる計画だ。E2Eテストの自動化はMicrosoftの「Playwright」というNode.jsのライブラリを使った。
當麻氏によると「テスト環境を構築するコストは確かにかかるが、大体4回以上のテストでペイできる」という。自動化のメリットは他にもあると當麻氏は続ける。
「テスト環境を使い続けていくと環境が壊れてしまう危険性があるが、『Kubernetes』でテストのたびに新しいテスト環境を立ち上げるようにすれば自動化と安定したテスト環境を両立させられる。また、プルリクエストや定期実行が容易になるため、修正について素早いフィードバックを得られる。このため、リリース時間の短縮につながる」
こうして劇中のタケシくんは大量の確認項目に追われる日々を終えることができた。
実は多くの工数取られていたマニュアルの更新作業
フォーマットやコード検証の自動化に続き、E2Eテストも自動化したタケシくんは「他に課題はないだろうか？」と課題解決に意欲を持つようになった。早速調べたところ、サービスリリースに関わる「部下くん」からこんな話を聞いた。
“リリース作業の中で実はマニュアルの更新に手間がかかっている。ただ更新するだけではなく、記述を変更した部分に誤字がないか確認する作業があるし、フロントエンドが変わった場合はマニュアルの画像を差し替える作業もある”
「この話を聞いたタケシくんはこの課題を自動化の仕組みで解決できるのでは、と考えた。例えば誤字をチェックしたいのであれば、文章を校正する『textlint』というツールを使えば解決できる。画像の更新についても、Playwrightのスクリーンショットを取る機能を使えば自動化できる。こうしてタケシくんは、これまで培ってきた自動化のノウハウを生かすことでマニュアル更新作業の効率化に成功した」
當麻氏はまとめとして「（自動化を）思い立ったが吉日」と言う。
「何事もそうだが、後回しにすればするほど面倒になるものだ。サービスの規模が大きくなるほど確認項目が増え、リリースの手間も増える。そこから自動化を始めるのは大変だ。安全性とスピードの“二兎（にと）”を追いたいのであれば、すぐにでも自動化に着手すべきだ」
Copyright © ITmedia, Inc. All Rights Reserved.