タンプのリリースフローを公開します

こんにちは、プロダクト部・エンジニアの今井です。

タンプでは、新規機能の追加やパフォーマンスの向上のため、アプリケーションのリリースをほぼ毎日行なっています。私たちエンジニアにとってリリースは非常に身近な作業であり、そのフローを整備することは、開発者体験の向上をもたらすと考えています。今回はタンプのリリースフローについて紹介しようと思います。

リリースとブランチ運用について

メインブランチでリリースを行うことを基本としています。言語やフレームワークのバージョンアップなど、ブルーグリーンデプロイメントを行う場合などに限り、メインブランチ以外でのリリースが行われます。

ブランチ運用を含めた開発の進め方については、こちらの記事で詳しく紹介しています！

www.tanp-blog.com

リリースのトリガー

GitHubのReleaseの公開とタグ打ちをトリガーとしています。

メインブランチにPRがマージされると、以下の画像のようなReleaseがドラフト状態で作成されます。

この仕組みは、release-drafter/release-drafterを使用して実現しています。

画像の「パッチ適応」の部分のように、リリース前後に特別な作業を必要とするものはPRに特定のラベルを付与することで、視覚的に強調することができます。これによりイレギュラーな作業の見落としを軽減しています。

ドラフト状態のReleaseを公開することで、リリースの開始がエンジニアチームにアナウンスされます。この時Gitのタグも自動で打たれます。

この仕組みの導入により以下のメリットを実感しています。

プルリクエスト(実装)の進行状況が容易に把握できる

Release(note)があることで、リリース済みなのか、未リリースなのかといったステータスを確認することができます。また、何がいつリリースされたかも記録として残すことができます。加えて、リリースにまつわるブランチの操作もGitHub上で完結するため、証跡を確実に残すことができる点もメリットに感じています。

安定バージョンへのロールバックが容易

リリースごとにタグが打たれているので、安定バージョンへのロールバックも容易に実行が可能です。もしリリース内容のいずれかに不具合が含まれていた場合でも、迅速に以前のバージョンに戻すことができます。

ノイズの軽減

メインブランチへのマージとリリースのトリガーが分離しているので、Approveされているプルリクエストは、特別なケースを除いてサクサクとマージできる状態になっています。理由なくオープンしたままのプルリクエストを減らし、進行中の実装やプルリクエストへのノイズを減らすことができています。

リリースワークフロー

Slackにデプロイの開始が宣言され、AWS CodePiplineを使ったデプロイを実行します。リリース宣言のSlack通知はワークフローになっており、デプロイ完了後は特定のダッシュボードやメトリクスを確認するように促してくれます。

Datadogのダッシュボードを使用して、リリースしたバージョンでエラーや遅延が発生していないかを確認します。

ダッシュボードを活用して統一したチェックポイントを提供することで、確認作業の標準化を図っています。また、障害等に対しての常時のモニタリングは組まれているものの、リリース直後にポイントを絞ったダッシュボードの確認を促すことで、リリースを起因とした障害検知のリードタイムを短縮することにも役立てています。

全ての確認を完了すると作業を労ってくれます。嬉しいですね。