JIRAとGitHub Actionsを活用した複数環境へのデプロイトレーサビリティ向上の取り組み

はじめに

愛車をリフォーム・アップグレードできるサービスKINTO FACTORYプロジェクトに参画している金谷です。今回は、JIRAとGitHub Actionsを活用し、複数環境へのデプロイのトレーサビリティを向上した取り組みを紹介します。
なお前回は、決済チームでリモートモブプログラミングに関する記事を書きました。

背景と課題

私はKINTO FACTORYプロジェクトの開発工程の後半から参画しました。プロジェクトのうちECサイトのフロントエンドチームリーダーを担当することになりましたが、担当する中で以下の課題があると考えました。

1. GitHub issues, JIRA, Excelがタスク管理に使われており進捗が管理しにくい
2. どのタスクがどの環境にデプロイされているか分かりにくい
3. テスト環境へのデプロイ時のリリースノート作成が面倒

ExcelのWBS+ガントチャートの例

はじめに進捗の管理のしにくさですが、私が参画した時点では、タスクの管理ツールはGitHub issues, JIRA, ExcelのWBS+ガントチャートの3種類が存在し、どれも使っている、という状態でした。そのために、必要な情報を一元管理できていないことで、スケジュールやタスクの管理が難しくなっていました。
次に、どのタスクがどの環境にデプロイされているか分かりにくい問題です。開発中では、デプロイの対象環境が2つあり(開発環境とテスト環境)、開発中のタスクがどの環境にデプロイ済みなのかを把握することが難しくなっていました。
最後に、テスト環境へのデプロイ時のリリースノート作成が面倒問題です。テスト環境には、我々エンジニアだけでなく、品質保証を担当するQAチームの方々もテストに使っていたため、いつどの内容をテスト環境にデプロイしたのかを連絡する必要がありました。連絡方法としてリリースノートを作る運用にしていたのですが、このリリースノート作成に毎回5分程度は時間を取られており、非常にストレスに感じていました。

これらの課題に対して、デプロイのトレーサビリティを上げることを目標としました。少なくとも、課題の2と3 (環境ごとのデプロイ管理問題、リリースノート生成問題)は解消されることが期待されます。また、後述の仕事の仕方の変化により、課題の1(進捗管理が難しい問題)の解消も狙っていきます。

デプロイのトレーサビリティを上げる方針

まずトレーサビリティですが、DevOps 技術: バージョン管理 | DevOpsの能力には以下のよう書かれております。このうち複数環境の差分を出さない、または出てもすぐに確認ができることが求められます。なお、全ての依存関係のバージョン管理は、フロントエンドの場合に npm の package.json, package-lock.json で管理できるため、本記事では省略します。

どの環境を選んでも、その環境を作成するために使用するすべての依存関係のバージョンをすばやく正確に判断できなければなりません。
また、環境の 2 つのバージョンを比較し、その環境間の変更点を理解する必要があります。

どのタスクがどの環境にデプロイされているかを管理できるようにする、トレーサビリティを上げる方針として、以下を行いました。

1. JIRAでタスクやデプロイを全部管理する
2. リリースノートは自動生成に頼る

JIRAでタスクやデプロイを全部管理する

JIRAには、課題の開発情報を見る機能があります。コードの状況、レビュー状況、ビルド、デプロイの状況が分かるため、開発に必要な情報をすべてJIRAに集約することにしました。

JIRAとGitHubの連携には、以下の作業を行う必要があります。

1. JIRAとGitHubを連携する設定を行う
2. JIRAのチケットとGitHubのプルリクエストを紐付けるためにブランチ名にJIRAチケット番号を含める
3. GitHub Actionsでデプロイする際に環境を設定する

このうち2.については、エンジニア各人の作業に委ねられる部分でした。エンジニア各人にJIRAチケット番号を含めていただくにあたり、GitHub issuesとExcelの利用を廃止し、JIRAに統一することにしました。JIRAに統一することで、エンジニア各人もタスク管理がしやすくなり、進捗管理する側も、JIRAのロードマップを使うことで一元管理できるようになりました。

JIRAロードマップの例

3.については、 environment パラメータを渡してデプロイすることで、 environment に渡したデプロイ状況がJIRAにも連携されます。
参考までに我々が使用しているGitHub Actionsによるデプロイの一部コードを掲載します。 environment パラメータにて、更に $${ inputs.env }} を渡しており、環境ごとのキーが作られるようになります。 $${ inputs.env } にデプロイ先の環境名が入るため、デプロイ先がJIRAに連携されるようになります。

  DeployToECS:
    needs: [createTagName, ecr-image-check]
    if: ${{ needs.createTagName.outputs.TAG_NAME != '' && needs.ecr-image-check.outputs.output1 != '' }}
    runs-on: ubuntu-latest
    environment: ${{ inputs.env }}-factory-frontend
    steps:
      - 具体的な処理

結果として、開発状況はJIRAのロードマップとチケットで管理し、各チケットを見ることで、レビュー中なのか、マージ済みだが未デプロイなのか、どの環境までデプロイできているのかが管理できるようになりました。

JIRAの各チケットに記載されるステータス

また各チケットではなく、チケット全体を通してデプロイ状況を見える化することもできます。各チケットがいつどの環境にデプロイされたのかを見ることができて便利です。

各環境へのデプロイ状況の見える化

リリースノートは自動生成に頼る

リリースノートの自動生成は、GitHubの自動生成リリースノート機能を使うことにしました。リリースノート自動生成は、GitHubのリリース機能のうち、リリースノート部分をプルリクエストのタイトルとリンクを一覧表示する機能です。リリースノート自動生成は、いくつかのルールを設定することで、よりよい対応ができます。こちらを紹介します。

リリース内容のカテゴリを決める

リリースノートに列挙されるプルリクエスト一覧は、デフォルトではカテゴリ分類されておらず、非常に見にくくなります。カテゴリ分類を使うことで、リリースノートが整理されて見やすくなります。
カテゴリはラベルで表現されます。今回は、特に主要な変更と不具合修正をリリースノートのカテゴリとして表示したかったため、それぞれを表現するラベル(enhancement, bug)を作成しました。
また、対象リポジトリに .github/release.yml というファイルを作り、以下の内容を書くことで、カテゴリごとのプルリクエストタイトル一覧を生成できます。

changelog:
  categories:
    - title: 主要な変更
      labels:
        - 'enhancement'
    - title: 不具合修正
      labels:
        - 'bug'
    - title: その他
      labels:
        - '*'

生成されたリリースノートのイメージは以下の通りです。enhancementラベルが付いているプルリクエストのタイトルが「主要な変更」に、bugラベルが付いている場合は「不具合修正」にそれぞれ分類されるようになりました。enhancement, bugラベルが付いていないプルリクエストは、すべて「その他」に分類されます。

プルリクのレビュー時点でカテゴリ仕分けやタイトル修正を行う

リリースノートを生成してから手動で仕分けることもできますが、リリースノートを生成した時点では、記憶を取り戻して仕分けをする必要があり、大変です。そのため、プルリクエストのレビュー時点で、カテゴリに相当するラベルを付けることで運用しています。合わせてタイトルも、修正内容に合ったタイトルかどうか見ています。
細かいtipsとして、ラベルの付け忘れを防ぐために、リファクタリングなどに対しては、 others ラベルを付与しています。これにより、レビューしてカテゴリ仕分け済みであることが分かるようにしています。

結果

以上の取り組みにより、抱えていた課題は無事に解決できました。また、特にJIRAロードマップは他のチームでも参照され、今はKINTO FACTORYプロジェクト全体で使われるようになっています。

• GitHub issues, JIRA, Excelがタスク管理に使われており進捗が管理しにくい → JIRAのチケットとロードマップに集約され一元管理できるようになった
• どのタスクがどの環境にデプロイされているか分かりにくい → チケットに環境ごとのデプロイ状況が見えるようになった
• テスト環境へのデプロイ時のリリースノート作成が面倒 → 2〜3分かかっていた作業が10秒に激減した

今後の展開

本番環境へのデプロイによって、DevOps Four Keysのうち速度に関する2つがJIRAで計測できます。デプロイ頻度や変更のリードタイムについて、現状と目指すべき指標をチーム内ですり合わせて、継続改善を行っていきます。

• 本番環境へのデプロイ頻度
• マージから本番環境へのデプロイまでのリードタイム

KINTO FACTORYプロジェクトでは、サービス成長を一緒に実現してくれるチームメンバーを募集しています。この記事やKINTO FACTORYに興味を持った方は、ぜひ以下の求人一覧もご覧ください！

• 【KINTO FACTORYフルスタックエンジニア】KINTO FACTORY開発PJT／東京
• 【KINTO FACTORYバックエンドエンジニア】KINTO FACTORY開発PJT／東京
• 【KINTO FACTORYフロントエンドエンジニア】KINTO FACTORY開発PJT／東京