ブランチ戦略（GitHub Flow）を見直してステージング環境の運用を改善しました

こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確

[kota65535]

うちでもラベル付けたら動作確認用の環境作成するのやってるな〜わかる

[dorapon2000]

“この仕組みにより、デプロイブランチは「最新のメインブランチに deploy/*ラベルが付与されたプルリクエストを全て取り込んだ状態」が維持されます。”

[tkmkg8m]

最新のメインブランチから切ったブランチを用意し、 deploy/dev ラベルが付与されたオープンなプルリクエストのブランチをそこへすべてマージする。できあがったブランチをデプロイする。なるほど。

[poad1010]

この記事をおすすめしました

[mak_in]

ブランチ戦略≒開発チームの業務フロー定義、とも言えると考えてるので、プロジェクトの立ち上げや改善のタイミングでブランチ戦略を真面目に考えるんだけど、微妙な開発チームに限って、？？？のリアクションで困る

[fa11enprince]

ふむふむ

[NetPenguin]

早い段階でコンフリクトが見つかるの、良いな。

[hirorinya]

みてね使ってる