機能 › 開発の管理メニュー：開発の管理 › レビュー › 公開と反映
公開と反映
BeesBuild は、リポジトリごとに「どこまで自動で進めてよいか」をモードで決めます。どのモードでも、本番は人が押します。
開発の段階の 3 つのモード
| 実験モード | 試す人ありモード | 運用モード | |
|---|---|---|---|
| 使う時 | ゼロから作る。客はいない | 旗を試す人に開けた後。まだ客はいない | 客がいる。本番に出ている今のシステム |
| 例 | 新しいリポジトリで作る新しいサービス、BeesBuild 自身 | 試す人に出し始めた新しいサービス | 本番に出ている今のリポジトリ、客ができた後のサービス |
| マージ | 自動マージの決まりに合う PR を、コアが GitHub App の名前でマージ。除く物は人 | 自動でマージするのは、持ち場だけ・旗がオフ・危なくない PR だけ。試す人に開けた機能に触る PR と、除く物は人 | エンジニアがマージの机で 1 本ずつ押す。本人の名前で記録 |
| ステージング | マージの後に自動でデプロイ（30 分ごとか 10 本ごとにまとめる。案） | 同じ | マージの後に自動でデプロイ（ステージングがあるリポジトリ） |
| 動作確認 | ゴールごとの自動の確認（スモークと E2E） | 同じ＋試す人に開けた機能の通し試験 | 同じ＋人のテスト |
| 本番 | 人が押す | 人が押す | 人が押す |
| 壊れた時 | 列を止め、戻す PR を自動でマージし、作ったスレッドへ返す | 同じ。試す人に開けた機能が壊れたら、旗を閉じるカードも出す | 戻す PR を作り、エンジニアがマージする |
自動マージの条件と除く物は、PR の地図とマージにあります。
main を守るルールセット
| モード | ルールセットの中身 |
|---|---|
| 実験モード | PR を通す・必須の CI・force push を止める。承認の数は 0 |
| 試す人ありモード | 実験モードと同じ形に、旗がオフかを見る check を必須に足す（案） |
| 運用モード | PR を通す・承認 1 以上・code owners の承認・最新の push の承認・会話の解決・必須の CI・順の check（beesbuild/order）・force push を止める |
運用モードのルールセットは、BeesBuild が案（JSON）を作り、人が GitHub の画面で入れます。BeesBuild は入った物を読んで確かめます。GitHub App に、リポジトリの管理の権限を持たせないためです。
モードの切り替え
| 切り替え | 合図 | 押す人 |
|---|---|---|
| 実験 → 試す人あり | 公開の門で、旗を「試す人」に開ける前。プレイテストでゴールがステージングで動いた時 | 持ち主（確認のカード） |
| 試す人あり → 運用 | 旗を「だれでも」に開ける前・外の人の初めての登録・初めての支払いのどれか | 持ち主（確認のカード） |
| 前のモードへ戻す | 持ち主が要ると決めた時 | 持ち主だけ。理由を記録する |
切り替えの合図は BeesBuild が見つけ、確認のカードを出します。押すのは持ち主です（作る段と並行の段）。
リポジトリの扱いの決まり
どのリポジトリをどのモードで扱うかは、利用者が決まりとして作れます。
| 欄 | 中身 |
|---|---|
| リポジトリの組 | 組織・名前の形・本番に出る枝 |
| モード | 3 つのどれか |
| 自動の行き先 | どの枝まで自動でマージしてよいか |
| 統合の枝 | 本番の枝とは別に、自動でマージしてよい枝を持つか |
| ステージング | ステージングの有無と、用意を頼む先 |
| 依頼と理由 | 用意をほかへ頼むか。そう決めた理由 |
- 新しいリポジトリを足した時は、合う決まりを当てて、確認のカードで見せます。
- 本番の枝への push でそのまま本番に出る既存のリポジトリは、旗がオフでも、マージが本番へのデプロイになります。運用モードにします。
- その中で新しいサービスを速く回したい時は、統合の枝とステージングを用意してもらい、統合の枝まで自動にします。用意ができるまでは、反映を推定で見せます。この形は雛形として選べます。
公開の門
機能は旗で開けます。開ける順は、社内 → 試す人 → だれでもです（提供の予定と範囲）。
旗を開ける前には門があり、次の 4 つがそろうまで開けません。
- セキュリティの監査で、重さ「高」の指摘が残っていない。
- AI のテストで「壊れ」（動かない所）が 0 件。
- main の CI が通っている。
- 作り手が了承している。
公開の画面には、旗ごとの段（社内・試す人・全員）と、公開の記録（版・段・日付・中身）が並びます。リリースノートは AI が下書きします。先に作る 4 つや説明のページを外に出す前には、規約とポリシーに照らします（規約の線とライセンス）。
ステージングと本番への反映
| 物 | 中身 |
|---|---|
| 反映の先 | リポジトリごとに、プレビュー（PR ごと。任意）・ステージング・本番（提供先ごと）。どのホスト名がどの反映の先かもつなぐ（クラウドとドメイン） |
| デプロイの記録 | 反映の先・sha・時刻・状態・入った PR・確定か推定か |
確定と推定
| リポジトリ | 読み方 | 印 |
|---|---|---|
| 新しいリポジトリ | デプロイの job に environment を書き、GitHub の deployments の記録と状態を読む | 確定 |
| 記録の無い既存のリポジトリ | デプロイの workflow の成功した実行の sha を読み、前の成功との間の commit を比べ、commit から PR を引く | 推定 |
新しいリポジトリは、デプロイの job に次の 1 行を必ず書きます。どの sha がどの環境に出たかと元の PR が、GitHub の Deployments のページにも残ります。
jobs:
deploy:
environment: production
- 本番の環境は、main（かリリースのタグ）からだけデプロイしてよい、にします（デプロイしてよい枝の決まり）。
- 提供先ごとの本番の枝は、main と同じ流れとは限りません。枝ごとに見ます。
- 推定のリポジトリも、デプロイの job に environment の 1 行を足せば確定になります。
反映の表
| 所 | 中身 |
|---|---|
| 表 | 行＝ゴール（開くと PR）、列＝反映の先、升＝入った時刻・まだ・推定 |
| マージ済みで本番にまだの PR | 3 日を超えたら琥珀 |
| ステージングで確認待ち | 人の確認を待っている物 |
| 失敗したデプロイ | 失敗した反映の先と sha |
本番へ出す・戻す
- 確認のカード：何を、どの反映の先へ出すかを読んで押します。
- 手動で起こす実行：本人の GitHub のログインで、デプロイの workflow を
workflow_dispatchで起こします。 - 名簿の確認：workflow の最初で、押した人が名簿にいるかを確かめます。いなければ止まります。
- デプロイ：本番へ出します。
- 記録：デプロイの記録に残します。
- 戻す時は、前に成功した sha で同じ workflow を起こします。前の版へ 1 回で戻せます。
- GitHub Team のプランの非公開のリポジトリでは、環境の人の承認と待ち時間が使えません。そのため、確認のカードと名簿の確認で、本番の前の人の承認を作っています。
- BeesBuild は本番へ直に出しません。出すのは、人が起こした workflow です。
通知と週次レポート
- 通知はゴールの単位で出します。ゴールがステージングで動いた・本番に出た・デプロイか動作確認が失敗した・列が止まった・週次レポートができた、の時だけです。PR 1 本ずつの知らせは、週次レポートにまとめます（通知の決まり）。
- GitHub の様子は 15 分ごとに読みます。もっと早くしたい時のために、GitHub App の Webhook の受け口を後で足します。ベータ版の後
- 週次レポートは、毎週月曜 9:00（日本時間）に自動で作ります（開発の速さ）。
エンジニアへの引き渡し
ゼロから作ったサービスを、エンジニアが作り切って運用に移すまでに、次の物をそろえます。
| そろえる物 | 中身 |
|---|---|
| 手元で動かす手順 | 範囲の引き継ぎに、clone・install・試すデータの投入・起動・試験の命令と、.env.example（秘密を入れない雛形）を付ける |
| ステージングの用意 | 新しいハイブを作る時に、ステージングと本番の環境と、デプロイの workflow の雛形を PR で出す。.github/ に触るので人がマージする |
| 直しの流れ | ステージングで見つけた不具合 → 仕事の札 → 元のスレッド → 直しの PR → 同じゴールに入る |
| 戻す | ステージングは、実験モードなら戻す PR を自動でマージ。本番は前の版へ 1 回で戻す |
| 引き渡し | 運用モードへの切り替え・CODEOWNERS をエンジニアのチームへ・運用の手順書・見張り・ブロックごとの引き継ぎ |
| BeesBuild なしの道 | Projects の見方・PR の説明の 1 行・Markdown の資料・Undam（旧 Xroid Work）の週次レポート |
| 最後の 20 本 | 残りが 20 本以下になったら、最後の詰めのモードへ（仕上げの管制） |
BeesBuild 自身の開発
BeesBuild のリポジトリは実験モードで作っています。旗を試す人に開ける時に、試す人ありモードへ切り替えます。
- T9 の決まりに合う PR は、毎回の了承なしでマージします。マージするのは AI のスレッドではなく、人が一度入れた GitHub Actions のマージの workflow です（PR の地図とマージ）。
- ステージングは、main から作る夜の試しの版と、通し試験です。
データの形
| 型 | 中身 |
|---|---|
HbDevStageMode | 開発の段階のモード（ハイブ × リポジトリ・3 つのモード・切り替えの記録と合図） |
HbRepoRule | リポジトリの扱いの決まり（リポジトリの組・モード・自動の行き先・統合の枝・ステージング・依頼と理由） |
HbRelease | 公開（旗の段・版・中身） |
HbEnvironment | 反映の先（リポジトリ・名前・種類・デプロイの枝・デプロイの workflow・URL・確定か推定か） |
HbDeployRecord | デプロイの記録（反映の先・sha・時刻・状態・入った PR・確定か推定か） |