今週は説明するだけでなく、実際に3つの経路すべてでビルドを本番公開してみました。というわけでこれはその記録です——何を実行したか、何が壊れたか、もう一度やるなら何を省くか。
1日目 午前——ワンクリックのサブドメイン
一番速い方法から始めました——公開ボタンを押すと、DNS設定もアカウント作成も費用もなしでyourname.buildmidas.comが手に入ります。かかった時間はせいぜい4秒。アイデアに誰かが興味を持つかどうかを確かめたいだけのときはこれが正解です——リンクを共有し、反応を見て、改善する。アプリがアカウント、データベース、WebSocketによるマルチプレイヤー層といった本格的なバックエンドを必要とした時点で壁にぶつかると半ば思っていましたが、そうではなく、そこもホスティングされ管理されていました。こちら側で設定することは何もありません。良い初日でした。
1日目 午後——SFTPデプロイを壊してみる
一番不安だった部分です。プロダクトがサブドメインの規模を超えて独自ドメインが必要になったら、ビルドページから直接SFTP経由でデプロイします。既に古いファイルが残っているウェブルートを持つサーバーに向けてデプロイし、上書きされることを半ば覚悟していました。ところが、デプロイエージェントはサーバーを調査して戦略を選び——そしてこれが重要な点ですが——何かに触れる前に既存のウェブルートをキャプチャしていました。それ以降にデプロイされたすべてのバージョンも保持され、ロールバックはワンクリックです。そのため、20分後にわざと壊れたビルドをデプロイしてテストしてみたところ、ロールバックにかかった時間はビルドが壊れていることに気づくまでの時間とほぼ同じでした。これがなぜ重要なのかについては「恐れずに反復する」でさらに書きましたが、要点を言えば、バージョン履歴によってデプロイが息を止める瞬間から何でもない出来事に変わるということです。
次回は省こうと思ったこと——変な入れ子のサブディレクトリ構造でシステムを騙そうと20分費やしましたが、要点はそもそもこれがあなたのサーバー、あなたのドメイン、あなたのファイルであり、このツールは慎重な運び屋であって門番ではないということでした。リスクでも何でもないものをテストするのに労力を無駄にしました。
2日目——ストア経由の方法、これはまだ終わっていません
実はこの部分は完了させていない。そしてそれこそが正直に言って一番参考になるポイントだ。ストアへの配布——AndroidならGoogle Play、拡張機能ならChrome ウェブストアやFirefox アドオンへ——は、自分自身のデベロッパーアカウントを通じて行われ、掲載情報やプライバシー宣言はエージェントが用意する。これは実際に可能だが、審査待ちという誰にもコントロールできない工程を含む、それ自体が数日がかりのプロセスでもある。だから私は掲載準備のステップで止めた。ストア配布を目指すなら、そのための予算は別枠で見積もっておくこと。全体の流れはプロンプトからアプリストアへに書いた。
その瞬間、どの道を選ぶかを決めていたもの
2日目には、選択はほぼ自然に決まっていた。
| やっていたこと | 選んだ道 |
|---|---|
| アイデアに手応えがあるか試す | サブドメインで、当日中に |
| 本物のブランドドメインが必要 | まずサブドメイン、その後自分のサーバーへSFTP |
| ストアで見つけてもらうべきユーティリティ | サブドメインのランディングページ＋アプリのストア配布 |
| クライアントのインフラ上のプロジェクト | クライアントのサーバーへSFTP、バージョン管理あり |
週末
金曜日には、自分のドメインにマーケティングサイトがあり、製品本体はサブドメインで公開され、ストア掲載も半分準備できていた——同じプロジェクトで3つの道すべてが同時に進行し、ずっと同じチャットから構築・反復されていた。どうやらこれが、本気の何かに対する普通の最終形態であって、例外ではないらしい。3つの道を別々の判断として扱うのではなく、初日からそれを前提にしておけばよかった。
