Taigaが判断を待つ箇所を選ぶ

四つの判断を分ける

架空の備品サービスには、四つの異なる判断があります。計画を受け入れる、buildを実行する、変更をマージする、デプロイするという判断です。一つのスイッチで、四つすべてが許可されると扱わないでください。

自律動作を変える前に、マージ後にリポジトリのパイプラインが何をするかを確認します。作業対象のブランチへのマージがデプロイを起動する場合、自動マージも、その既存のワークフローを起動できます。

計画を承認待ちにするか決める

ProductのBuild on its own by default設定は、完成した計画がbuildに進むか、承認を待つかを制御します。先に人の判断が必要な場合は、オフにします。

InitiativeのBuild on its own設定は、そのinitiativeだけの動作を変更できます。作業をQueueに入れる前に、デフォルト設定と個別の選択の両方を確認します。

Approveは、承認者の現在の権限に従い、その人を実行主体としてbuildを開始します。計画に失敗した場合、buildは始まりません。Buildの自動化だけでは、結果のpull requestのマージは許可されません。

マージ設定の階層を理解する

自律的なマージは別に制御され、有効にするまではオフです。文書化されている連携は、GitHub Enterpriseを含むGitHubに対応しています。

組織またはfactoryの上限が無効なら、下位で上書きできません。Productのデフォルトがオフの場合は異なります。上限が許可していれば、initiativeで個別にマージを有効にできます。

備品サービスでは、初期範囲を明確に保ちます。許可された境界内で、影響の小さいinitiativeと、従業員のアクセス制御を変えるinitiativeに、異なる選択を設定できます。

必須レビューを強制できるようにする

Taigaは、ソース管理の提供者に、そのpull requestをマージできるか確認します。必要なチェック、レビュー、その他の条件を定めるのは、ブランチ保護です。自律的なマージは、それらのルールを迂回しません。

自動レビューでマージを止める必要がある場合は、リポジトリが対応する設定を通じて、その結果を必須のstatus checkにします。助言的な結果は、期待しているだけで必須にはなりません。

必須の人による承認も確認します。成功したチェックは、ポリシーが求める承認の代わりにはなりません。実際の対象ブランチで、ルールを確認してください。

マージが停止した理由を読み取る

Initiativeに表示された理由を読みます。チェック待ち、承認不足、競合、未完了の計画では、それぞれ必要な対応が異なります。失敗したチェックを成功させるために、修正が判定基準を変えた場合も、Taigaは自律的なマージを停止します。その変更を直接レビューしてください。

進行を妨げているという理由だけで、必須チェックを削除しないでください。チェックが結果を返さない場合は、設定を修正するか、承認されたポリシー変更の手順を使います。修正の後は、現在のコミットを確認します。

デプロイの許可を別に保つ

自律的なマージはTaiga GitHub Appが実行し、マージした主体として記録されます。リポジトリのパイプラインは、既存のデプロイ動作を維持します。

このシナリオでは、マージするとstagingにデプロイされます。本番には、引き続き組織の本番用の判断と証拠が必要です。パイプラインがこの分離を強制することを確認してください。続いて、デリバリーのレビューを学んでください。