ホストされた Web アプリの新しいバージョンをリリースするための最良のアプローチは何ですか? また、通常はどのくらいの頻度でリリースしますか? 毎週、毎月など任意の日付を選択して、蓄積された一連の修正プログラムを展開しますか (おそらくJoel の出荷日へのアプローチと同様のアプローチを使用します)。それよりもはるかに長く待機すると、ホストされたアプリの主な利点の一部が損なわれるようです. 一方で、ユーザーを混乱させる可能性のある新機能を常にロールアウトすることは望ましくありません (つまり、ユーザーがログインするたびに何かが異なる場合)。
最近まで、私の経験は主にインストール済みのサーバーベースまたはデスクトップ アプリでした。ホスト型アプリで人々がどのようなタイプのリリース管理を使用しているかを知りたいです。
Google のアプローチはおそらくエンド ユーザーにとって最適ですが、複雑さを犠牲にしています。
新しいバージョン (場合によっては個々の変更のみ) をかなり定期的に (プロジェクトによっては毎日のように) ロールアウトします。しかし、ここで肝心な点があります。新しいバージョンが与えられるのはごく一部のユーザーだけです。
Google には大きな製品のユーザーが多数いるため、「ユーザーの 5% がこの機能を表示する必要がある」などのルールを設定するのが現実的です。
その後、結果を分析し、おそらくユーザー人口のさらに 15% を対象とした次のリリースを計画できます。
エンジニアが生きるためのルーチンを定義したいのと同じように、それは実際にはシステムの背後にあるビジネス上の要求によって推進されます。また、更新の性質などにも依存します...
コンテンツとHTMLの更新は、大したことではありません。アプリケーションの変更は大きな問題である必要があり、ライブにプッシュする前に、プレビューサイトで確立されたテストルーチンを実行する必要があります。
確かなことの1つは、変更をデプロイ（およびアンデプロイ）するための非常に「クリーンな」方法が必要であることです。また、変更を公開する前に、変更を確認および監査するための「簡単な」方法も必要です。
「git」と「rsync」を組み合わせて使用すると、プロセスを完全に制御できます。プロジェクトへのすべての変更は、「Production」ブランチから分岐したブランチで開発されます。変更を公開する前に、「本番」ブランチを完全にマージする必要があります。公開するという行為は、適切なブランチを「本番」にマージし、ライブサーバーに同期することです。Gitはこれを本当に簡単にします。
これにより、実行中の変更が進行中の他の変更と競合する可能性がなくなります。
このシステムを採用して以来、私たちの展開ルーチンは効率と明確さを劇的に向上させました。ちなみに、私たちの展開は1日に複数回から数か月に1回までの範囲です。それはすべて異なります。アクティブなプロジェクトでは、週に1〜2回のリリースを希望します。
早期かつ頻繁にリリースすることは、私が行っていることであり、私たちが働いている場所で行っていることです。また、更新を行うたびに、ブログで更新について説明します。すべての更新を一度に 1 つの更新にまとめると (QA のため、ロールバックする必要がある場合など)、できる限り簡単になります。ユーザーの観点からは、アップデートがたくさんあっても問題はないと思います。悪いアップデートでない限り。1 年または 6 か月待って、すべての更新を 1 つの大きなリリースにまとめると、問題があると思います。それが、私が以前取り組んでいたプロジェクト (おそらく聞いたことがある人気のフィードリーダー) を殺したものです。人々は私たちが死んだと思っていましたが、知覚が現実になりました。私たちは見捨てられました。だから、私はファイアホースのリリーススケジュールに大賛成です。
2 週間ごとで十分ですが、これは市場によって大きく異なります。
Planbox (Web ベースのアジャイル プロジェクト管理 SaaS) では、毎日リリースしています。これが可能なのは、ほとんどのアプリケーション ロジックとすべてのプレゼンテーション ロジックがフロントエンド (Javascript) にあるためです。HTML も、テンプレート エンジンを使用して Javascript 経由で生成されます。しかし、バックエンド (PHP) とその REST API はめったに変更されません。これにより、互換性を損なうことなく、いつでも新しいバージョンのクライアントをプッシュできます。
このようなアーキテクチャに移行できれば、時間を大幅に節約し、効率を大幅に向上させることができます。