Zenn
ThinkingsテックブログPublicationへの投稿
🔖

年間リリース数200超のSaaSを支えるオンタイムリリースフロー

TigRig
2024/07/09に公開
Git
deploy
Jenkins
release
フロー
tech

Thinkings株式会社 では採用管理システム sonar ATS を提供しています。

sonar ATS は、日々小さな修正から新機能の追加まで頻繁に更新が行われており、年間リリース数は200を超えます[1]。

本記事ではそんな sonar ATS を支える毎日のリリース作業について紹介したいと思います。

リリースの種類

リリース対象物には、新機能、不具合修正、要望改善など様々なものがあります。その規模についても大小の差があったり、優先度も異なります。

また弊社には複数の開発チームがあり、リリース要求が常に複数箇所から発生します。

これらを取りまとめるため、以下2つのパイプラインを設けて運用しています。

  • メンテナンスリリース（月一回）
    • 大規模機能リリース、DBスキーマ変更を伴うリリースなど
    • 一時的にシステムを止めて安全に適用する必要があるリリース
  • オンタイムリリース（毎日）
    • 不具合修正、小規模な要望改善など
    • システムを止める必要がなく、早めに適用したいリリース

このようにパイプラインを切り分けることで、不具合修正や新機能など、いち早くユーザーに届けたい価値を迅速に提供できるようにしています。

本記事では、毎日の価値提供を実現しているオンタイムリリースのフローについて紹介します。

オンタイムリリースフロー概略

使用しているツール
  • Git
    • バージョン管理ツール
  • Jenkins
    • CIツール

※様々な事情があって GitHub のようなプラットフォームは現在使用していません（直近で導入予定！）

オンタイムリリースフローのポイント

複数の検査フェーズを設けている

「素早く価値を提供する」という目的のオンタイムリリースですが、たとえ素早くとも不具合を増やしては本末転倒です。

しっかりと安全性を担保できるチェック機構を設けて運用しています。

デプロイ担当という役割を設けている

弊社では開発者が直接デプロイしたり、マネージャーがデプロイ管理するのではなく、別途デプロイ担当という役割のメンバーを設けて、デプロイ作業を運用しています。

デプロイ業務に精通した担当者が進行管理をすることで、オンタイムリリースをスピーディかつ安全に行えるようにしています。

開発途中の内容や不要なリリース物を混入させないブランチ戦略

弊社では、 git-flow に近い独自のブランチ戦略を採用しています。

ブランチ運用図

  • master
    • 本番環境ブランチ（ここにマージした開発物が本番環境に反映される）
  • release
    • デフォルトブランチ
  • feature-xxx
    • 開発ブランチ
    • ※図では1本だが、実際は複数の開発ブランチが存在する
  • dev
    • 開発環境ブランチ（ここにマージした開発物が開発環境に反映される）

dev ブランチを用意することで、本番リリースせずとも、開発途中の内容がクラウド環境上で正しく動くか確認できるようにしています。

dev で動作確認を終えた開発ブランチは、 release にマージすることでオンタイムリリースフローに乗ります。開発者としては自身の開発ブランチを release にマージするだけなので、シンプルでミスが発生しにくいです。

hotfix(緊急不具合修正)ブランチ運用図

時には緊急修正が必要な場合もあるので、上図のような hotfix ブランチも活用しています。

hotfix は master から生やすことで他のリリース物の影響を受けずに本番適用できるようにしています。

オンタイムリリースフローの詳細

1. 開発内容をリリース準備ブランチへマージ

開発者は自身の開発物を release ブランチにマージします。

※下図の四角形で表示されている箇所が対象のマージコミットです。

2. リリース内容の検査

15時までに release (リリース準備ブランチ) にマージされた成果物は、 『リリース対象コミット一覧』として Teams に通知されます。 (Jenkins にて「毎日15時に release の変更差分ログを Teams 通知する」というジョブを用意しています)

このスレッドにて、開発者はマネージャーへリリース物のレビュー依頼を行います。

※レビューにて《リリース不可》と判断されたものは差戻扱いとして、開発者の方で release へのマージコミットを revert しています。

3. リリース準備ブランチをリリースブランチへマージ

全ての リリース内容検査 が終わったら、デプロイ担当者はデプロイ作業を進めます。

まずはじめに、リリース物がマージされている release ブランチを master (リリース用ブランチ) にマージします。

※下図の四角形で表示されている箇所が対象のマージコミットです。

4. マージログ確認

master へのマージ後、master にリリース対象物が過不足なく入っていることを必ず確認します。

具体的な方法としては、 master ブランチ上で以下のコマンドを実行し、

# 前回リリース時～最新状態までのコミットログを出力するコマンド
# (Jenkinsで自動実行している『リリース対象コミット一覧』の出力も同様のコマンドを使用している)
git --no-pager log --no-merges @^..@ --pretty=format:'[%cn] %s (%h)'

コマンド実行結果と『リリース対象コミット一覧』の内容(2. リリース内容の検査で示したTeams通知される内容)を比較し、差分がないことを確認しています。

もし差分が出た場合は、対象コミット者と連携し、適切なリリース物のみが master に入るよう調整します。

5. ビルド実行

適切なリリース物のみが master に入っていることが確認できたら、ビルドを実行します。

実作業としては、ビルド用の Jenkins ジョブをキックするだけです。

6. ビルド結果の確認

ビルドが完了したら、 Jenkins のビルドジョブ結果を以下の観点で確認します。

  • ビルドが正しく完了しているか
  • リリース物がビルド対象に含まれているか

ビルドが正しく完了しているかについて、実際に確認するのは前述の「ある特定の警告が出ていないか」のみです。(ビルドそのものが成功したかどうかは、 Jenkins のジョブ実行結果が Success になっているかどうかで判断します)

リリース物がビルド対象として含まれているかについては、Jenkins の『変更履歴(Changes)』ページで、前回実行時との差分コミットログを確認できるため、こちらの内容が2. リリース内容の検査に掲載の『リリース対象コミット一覧』と一致しているかを確認します。

7. デプロイ実行

ビルド結果に問題がなければ、デプロイを実行します。

実作業としては、デプロイ用の Jenkins ジョブをキックするだけです。

8. デプロイ成功確認

Jenkins のデプロイジョブが完了したら、正しくデプロイが完了しているか確認します。

デプロイ完了をいち早く認知できるデプロイ担当者が確認を行うことで、問題発生時、迅速に対応できるようにしています。

プロジェクトごとに確認事項は異なりますが、例えば以下のような確認を行っています。

  • Azure Cloud Service の対象サービスページ上で、『デプロイラベル』という欄に記載されているデプロイ実行時刻が更新されていることを確認
    • ※過去に、 Jenkins のデプロイジョブは完了しているが、 Azure Cloud Service 上には正しくデプロイされていなかった、という事象があったため確認している
  • デプロイしたサービスにアクセスしてみて、正しくログインできることを確認
    • ※リリース物によってサービス全体が止まるような大規模な問題が発生していないかを確認している

デプロイ成功を確認できたら、デプロイ担当者は開発者へデプロイ完了の旨を通達し、下記9. 本番動作確認の実施を依頼します。

9. 本番動作確認

最後に、開発者が自身のリリース物の動作確認を行います。

この本番動作確認を最後の工程として、全てのリリース作業が完了となります。

今後の展望

以上が sonar ATS 開発におけるオンタイムリリースフローです。

また今後の展望として、以下のような改善を検討しています。

定型的な作業の自動化

現行のフローには、全体的に手動で行う作業がまだ多く残っています。

安全のために自動化しないほうがよい場合もありますが、例えば 8. デプロイ成功確認 等の定型的な作業は、自動化することで効率化でき、さらに人的ミス（確認忘れ等）も防げると考えています。

具体的な例として、「デプロイ完了後、自動的に Autify のテストを実行する」という仕組みを検討しています。

手動で動作確認する手間が省ける上、確認をし忘れてしまったり、誤って関係のない動作確認をしてしまうといった、人的ミスの懸念も解消できるため、ぜひ実現していきたいです。

レビュー工程に GitHub PullRequest を活用

2024年7月現在、開発業務全体における改善の一環として、GitHub 導入を進めています。GitHub 導入後は PullRequest を活用したレビューフローに切り替えていく予定です。

GitHub PullRequest を活用することで、現行の 1. 開発内容をリリース準備ブランチへマージ ～ 4. マージログ確認 までの工程をまとめることが可能となります。

現行では、他の日のリリース物が混入しないよう『release へのマージは 13:00 - 15:00 に限定する』という規則がありますが、PullRequest の仕組みによって release へのマージが不要となるため、開発者の好きなタイミングでレビュー依頼出来るようになることも大きなメリットだと考えています。

おわりに

本記事では、Thinkings の sonar ATS 開発におけるオンタイムリリースフローを紹介しました。

この度フローを書き起こしてみて、比較的手動で手間をかけている部分が多いのだと改めて感じました。定型化している作業や、ツールの事情で致し方なく非効率的なままになっている部分については、今後の展望に記載のとおり改善に取り組んでいきたいです。

ただ安全のためには必要な手間もあるかと思うので、効率化に囚われすぎず、『安全なリリース』という観点を今後も変わらず大切にしていきたいと思います。

以上、一企業の運用事例として参考になれば幸いです！

脚注

  1. 年間リリース数200超は2023年度の実績です。 ↩︎

Thinkingsテックブログ
ThinkingsテックブログPublication

sonar ATSで採用担当者の皆さまを支援する、Thinkings株式会社のエンジニアによるテックブログです。

Discussion