毎日仕事もせずに何をやっているかと言えば・・・そうですね、個人的推論に則った改善活動といったところでしょうか。更新されたことでしょう。iOSアプリエンジニアの多くを混乱させたことでしょう。環境の構築も最低限終えたところでした。その日の朝、私は軽い改善を行おうとしていました。したのは妥当な理由があるのですが、ここでは割愛します)。ステップでエラーが発生しているようです。エラー内容は次のようになっています。インストールして利用するようにしていた為、このエラーログを見て何が起きているのか大体の察しがつきました。したものなので、前日は問題なくパスしていたコミットSHAの内容が突然失敗したことになります。なると、こちらの問題ではなくビルドスタック側に変更があったのは間違いありません。以前のビルドスタックも更新されているのか確認しました。ビルドスタックのみだろうと予想をつけました。系を利用している場合は確実に)、私の環境に限らず問題が起こることを確信しました。チャンネルが存在したため、そこで速報を打ち、同じ問題が発生する可能性があることを周知しました。これは同様の事象に遭遇した際のトラブルシューティング時間をへらす目的での情報共有です。状況を分析する次に、私はこの状況に対して一歩立ち止まって考えてみました。系に更新したのは意図的なものなのか?意図的であると仮定すると、不自然なことがあると気づきます。対応されたバージョンがリリースされました)。社内で適切な情報共有ができていなかった事を意味します。更新してしまったのであろうとほぼ判断しました。アップデートという大きな変更をするだろうか?少なくとも私であればやりません。対応できていない場合は同様にビルドエラーとなり、混乱することは目に見えています。これほど影響の大きい変更をする場合は、事前にユーザに一報し、それなりに準備期間を設けるのが自然でしょう。更新したのだと確信しました(なお、これが真実であったかどうかは分かりません)。次にこう考えてみました。取りうる手段として次の2つが思い浮かびました。更新したのがミスだったとしたら前者の方法が素直に見えます。しては、あまりこの方法は取りたくないだろうと考えました。信用を落とすのには十分だからです。対応がちょっと遅れちゃった。ごめんね!」という体裁が取れる、後者の手段を採用する可能性が高いと予想しました。側の動きを待ってから対応したほうが費用対効果が高いと判断しました。側はこの問題を把握するのにそれほど時間を要しないでしょうし、明日には問題を修正してリリースするでしょう。側の動向を待つことにしました。回していたところで大きな問題は発生しません。個人的な考えとして見解を共有しました。この問題への対応優先度はプロジェクトや状況によって異なるのは当然ですが、この情報が役に立つこともあるだろうという判断からです。側が問題に対処した場合に、すぐに検知できる仕組みが欲しいと考えました。別に急いでいるわけではないですが、簡単に自動で監視できる仕組みが用意できれば、それに越したことはありません。環境ではデイリーで実行する、いわゆる『Nightly』なビルドワークフローは用意していない状況でした。Latest』にして常に最新が利用されるようにしたワークフローを組み立て、それを毎朝4:00に実行されるようにしました。『ビルドスタック側』か『公式ステップ側』のどちらを修正して対処したとしても、対応が完了した時点で、グリーンのビルド結果通知が得られるはずです。系に戻った?ここで予想以上に早い変化が起きたことを、CIのビルド結果から知ることになります。ビルドされているログが確認できたのです。これはミスだったから戻した系かな。最初は急いでビルドスタックを切り戻したのかなと思いました。こちらの手段を取るのはちょっと意外だと感じましたが、まぁそういう『誠意的』な判断をしたのだろうと予想しました。系が利用されるケースの両方が存在することをビルドログから知ります。系に戻ってたんですが・・・全体のビルドVMへの反映が済んでおらず、『ビルドVMガチャ』みたいな状態になっているという認識でよきですか?ところで偶然ですが、『CI』も『ガチャ』も回すっていいますね。2020年1月15日あぁ、これはビルドVM全体への反映が済んでおらず、いわゆる『ビルドマシンガチャ』の状態になっていると判断しました。系に切り戻したところで、その変更が即座にビルドVMクラスタ全体に反映されるとは思いませんでした。系が重ね合わせの状態、すなわち我々が観測者だとすると『量子力学的ビルド』が発生しているのだと判断できました。ビルド開始時に収束するようになってしまっている。2020年1月15日はい、量子力学的ってのはただ言いたかっただけです(たぶん流行らない)。最終判断をするすでに現状でエネルギーを割いて対処するのは費用対効果が高くないと判断していましたが、『量子力学的ビルド』(まだ言う)が発生していることで、ますます今日はやる価値がないと考えを強めました。『量子力学的ビルド』が改善しないうちは、もはや無駄な試行錯誤を繰り返すだけだと考えたためです。Latest』なワークフローのビルド通知がグリーンになっていました。対応した旨が書かれていました。ケースに対応した模様。意図的なのかはさておき、どちらにせよ「やらかしポイント」贈呈です。2020年1月15日これで事態は一見落着かと思いきや、実は『量子力学的ビルド』はまだ続いていることに気づきます。私は考えるのをやめました。ビルドスタックを利用し続けることにしました。手軽さの影でトラブルシューティングの難しさの本質は、その問題がどこのどのレイヤで起こっているのかを推測しなければならないことです。終了した時などの問題に遭遇した時、私達は自分が当該領域について『思ったほど詳しくなかった』ことに気づきます。それ自体は問題ではありません。現代のソフトウェアにおいて全てを把握することは不可能に近いですし、トレードオフに従って優先度の高いものから学習するのは、とても理にかなった方法といえます。内部的にどのようなことが起こっているのか、ざっくりでも把握しておくのは有効と私は感じます。すべて行えますし、シンプルなワークフローであれば、ステップを組み合わせて必要な項目を入力するだけで完成します。それは単に『抽象化』が行われているだけであって、(当たり前のことを、と思うかもしれませんが)内部的にはxcodebuildなどのコマンドが利用されてビルドが実行されています。ステップという魔法によってビルドされているのではありません。ステップの実装まで見る必要はありませんが、内部的にどういった処理によってビルドが実現されているのか、気が向いたときにでもビルドログを眺めてみるのも面白いかもしれません。導入して自身のバージョンを固定するようになっています。自動テストの教科書』でも脚注で明記しています。単行本(ソフトカバー)Rubyにくわしい方はBundlerを利用してインストールすべきだと思うかもしれません。最初からBundlerをインストールしても構いませんが、後述の導入手順にしたがってセットアップを進めれば、最終的にGemfileが生成されてfastlaneのバージョンは固定されます。ついて殆ど理解せずとも導入できてしまうという諸刃の件でもあります。ついて何も理解していなかったことに気づくかもしれません。最後に今回起こったことは、結果だけ見ればたった一文で表現できます。対応していないステップまたはスクリプトがあった場合は対応が必要ほとんどの問題の解決策は、エラーメッセージをコピペしてググれば大体すぐに調べられます。問題を解決するまでに至るアプローチについては共有されないことが殆どだと思います。私はこの分野のプロフェッショナルではありませんが、今回の問題に対して、比較的短時間で推測を巡らせ、概ね妥当な判断・対応ができたと思います。この記事は何かを解決するものではありませんが、世の中の誰かの知恵につながればと思い、記事にしてみました。アップデート問題について私がどう考えて調査・対応したか。Go言語を学び始めた話(中編)以下の記事の続きです。試すこの素晴らしきビルドシステムに祝福を。アップデート問題について私がどう考えて調査・対応したか。『iOSテスト全書』の報酬の30%を分配した話。制作を支えた人々について。〜つばさドメイン〜『iOSテスト全書』を共著した話。『教科書本』との違い。(1)検索このブログについて技術をこよなく愛するエンジニア集団が在住するペンギン村から、世界へ役立つ(かもしれない)技術情報を発信する技術系ブログです。某アラレちゃんが済む村とは一切関係ありません。ウィジェットはてなブログをはじめよう!penginmuratechさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。