レビュー効率化、コード品質管理、DevSecOpsの実践――GMOペパボ内のCI/CD実践例：GMOペパボに学ぶ「CI/CD」活用術（2）（1/3 ページ）

GMOペパボにおけるCI/CD活用事例を紹介する本連載。第2回はGMOペパボ社内のさまざまな開発現場におけるCI/CDの実践例を紹介します。

[小山 健一郎，GMOペパボ]

　本連載第1回では、CI/CD（継続的インテグレーション／継続的デリバリー）の概要と重要性を紹介しました。「開発、統合、デリバリー」のサイクルを高頻度で回すためには、「開発、統合、デリバリー」プロセスのさまざまな要素を自動化、効率化することが重要になります。今回は、GMOペパボ社内のさまざまな開発現場におけるCI/CDの実践例を紹介します。

前置き：GitHub Actionsの設定例について

　GMOペパボではGitHub Enterprise Server（以下、GHES）を広く活用しています。GHESにもGitHub Actionsは存在しており、社内のCI/CDの基盤として活用されています（一部、GitHub.comで動いているGitHub Actionsと仕様が異なる部分があります）。

　本稿では、GitHub Actionsの設定の記述例をできるだけGitHub.comのGitHub Actionsでも動く形に置き換えて紹介します。ただ、GMOペパボのGHESはCI/CDのコードを実行するRunnerも含め他と隔離されたプライベートな環境で稼働しており、一部のコードはそれを前提としています。GitHub.comのGitHub Actionsでそのまま運用するとセキュリティ上の懸念が発生する場合がありますのでご注意ください。

CI/CDに取り組む前にやっておきたい「ステップの細分化」とは

　第1回では、「テスト」と「デプロイやリリース」の自動化をCI/CDの例として挙げましたが、「開発、統合、デリバリー」のプロセスは他にもさまざまなステップで成り立っています。

　Webアプリケーションの機能修正からテスト、そして本番環境にデプロイするまでのプロセスを例に見ると、ぱっと思い付くだけでも、以下のようなステップがあります。

• Issue作成
• ブランチでのテスト
• Issue/Pull Requestのラベリング
• レビュアーのアサイン
• コードレビュー
• コードレビューのフィードバック結果の修正
• メインブランチへのコードの統合
• 検証環境へのデプロイ
• 本番環境へのデプロイ
• Issueのクローズ

　上記以外にも他のステップがあったり、1つのステップをもう少し細かく分解したりできるかもしれません。これらは開発フローごとに異なってきます。プロセスを細分化できれば、自動化や効率化の適用箇所を見定めることができるようになります。

　本項以降では、CI/CDの事例としてGMOペパボが「開発、統合、デリバリー」のプロセスのさまざまなステップで取り組んでいる自動化や効率化を紹介します。

コードレビューの効率化

　コードレビューは多くのソフトウェア開発の現場で実践されているでしょう。テストコードだけでは確認できないさまざまな要素を確認するフェーズです。GitHub（GHES）では、多くの場合「Pull Request」の形で統合前のコードがレビュープロセスに載ることになります。

　レビュアーは「追加コードで実現している機能や設計」をはじめ多くの観点でレビューしますが、全ての確認をレビュアーに任せるのは非常にコストがかかるため、多くを自動化して効率を高めていくのがよいでしょう。

Linterやフォーマッタによるチェックの自動化、効率化

　コーディング規約違反や単純なタイプミスのチェックはテストコードと同様に自動化が可能です。

　Linterやフォーマッタは各プログラミング言語で使われているものをそのまま使うとよいでしょう。Goの場合、Linterの統合環境を提供する「golangci-lint」が有名です。

　golangci-lintをインストールしたActionsの環境で以下のようなstepを追加することでgolangci-lintの実施が可能です。

- name: Lint
  run: golangci-lint run ./...

　上記の場合、golangci-lintのチェックに失敗するとPull Requestのステータスエリアで失敗が分かるようになります。

　これによりレビュアーによるレビュー前にgolangci-lintの警告に気が付けるようになりました。一方で、上記の状態では、Pull Requestのgolangci-lintにおけるどのルールのチェックに失敗したかはActionsの実行結果を見てみないと分かりません。

　この仕組みにreviewdogを組み合わせることでPull Requestのページ上でLinterのチェック結果を確認できるようになります。今回はaction-golangci-lintを利用します。

　stepの設定は以下のようになります。

- name: Lint
  uses: reviewdog/action-golangci-lint@v2
  with:
    reporter: github-pr-review
    fail_on_error: true

　実行するとPull Requestの指定の行にコメントを付けてくれるようになります。

　このようにgolangci-lintを直接実行するのではなく、reviewdogを活用することでPull Requestのページで何が問題なのか確認できるようになり効率を高められます。