展開戦略を改善する
当社で開発したeコマースアプリがあります。これは、私たちが約3年間オンとオフで開発してきた、適度に標準的なLAMPアプリケーションです。テストドメインでアプリケーションを開発します。ここでは、新しい機能を追加し、バグなどを修正します。バグ追跡と機能開発はすべて、ホストされているSubversionソリューション（unfuddle.com）内で管理されます。バグが報告されたら、テストドメインでこれらの修正を行い、バグが修正されたことを確認したらsvnに変更をコミットします。新しい機能を追加して、これと同じ手順に従います。
サーバー全体のシステムとアプリケーションの一般的なアーキテクチャを指摘する価値があります。新しい機能が開発されるたびに、アプリケーション（常に制御するサーバー）を使用して、この更新をすべてのサイトに展開します。私たちのシステムを使用している各サイトは、基本的にコードベースの95％にまったく同じファイルを使用しています。各サイト内には、そのサイト専用のファイル（cssファイル/画像など）を含むフォルダーがいくつかあります。それ以外の場合、各サイト間の違いは、各サイトデータベース内のさまざまな構成設定によって定義されます。
これは実際の展開自体につながります。ある種の更新をロールアウトする準備ができたら、テストサイトが存在するサーバーでコマンドを実行します。これにより、コピーコマンド（cp -fru/testsite// othersite /）が実行され、各仮想ホストが変更された日付に基づいてファイルを更新します。ホストする追加の各サーバーには、本番コードベースをrsyncするvhostがあり、そのサーバー上のすべてのサイトでコピー手順を繰り返します。このプロセス中に、上書きしたくないファイルを移動し、コピーが完了したら元に戻します。ロールアウトスクリプトは、SQLコマンドを適用して各データベースを変更したり、フィールドや新しいテーブルを追加したりするなど、他の多くの機能を実行します。
私たちのプロセスは十分に安定しておらず、フォールトトレラントではなく、少し力ずくの方法でもあるという懸念が高まっています。また、ブランチやタグを使用していないため、新しい機能に取り組むと重要なバグ修正を展開できなくなる可能性があるため、Subversionを最大限に活用していないことも認識しています。また、サーバー間でファイルのレプリケーションが非常に多いことも間違っているようです。また、ロールアウトしたばかりのロールバックを簡単に実行することもできません。各ロールアウトの前に差分を実行して、変更されるファイルのリストを取得できるようにします。これにより、後に何が変更されたかを知ることができますが、ロールバックのプロセスには問題があります。データベースに関して、私は潜在的な解決策としてdbdeployを検討し始めました。しかし、私たちが本当に望んでいるのは、ファイルの管理と展開を改善する方法についての一般的なガイダンスです。理想的には、ファイル管理をリポジトリにさらに密接にリンクさせて、ロールアウト/ロールバックがsvnにさらに接続されるようにします。 exportコマンドを使用して、サイトファイルがリポジトリファイルと同じであることを確認するようなものです。ソリューションがサーバー周辺のファイルレプリケーションも停止する可能性がある場合は、それも良いでしょう。
私たちの現在の方法を無視すると、他の人が同じ問題にどのように取り組んでいるかを聞くのは本当に良いことです。
要約すると ...
- 複数のサーバー間でファイルをsvnと同期させ続けるための最良の方法は何ですか？
- ファイルの複製をどのように防ぐ必要がありますか？シンボリックリンク/何か他のもの？
- 新しい機能を開発して古い機能を修正できるように、リポジトリをどのように構成する必要がありますか？
- ロールアウト/ロールバックをどのようにトリガーする必要がありますか？
前もって感謝します
編集：
私は最近、これらの種類のタスクに Phing および Capistrano を使用することについて多くの良いことを読みました。誰かがそれらについて、そしてこの種のタスクにどれほど良いかについて、これ以上の情報を与えることができますか？
リリースを行うための私のアドバイスは、機能リリースとメンテナンスリリースを用意することです。機能リリースは、新しい機能を取得するリリースになります。これらはSubversionトランクに追加されます。これらが完全な機能であると思われる場合は、これらをリリースブランチに分岐します。 QAプロセスがこのリリースに満足したら、リリースにタグを付け、コードをサーバーにデプロイします。
バグレポートを受け取ったら、この修正をブランチにコミットしますそしてトランクに移植します。修正されたバグの数に満足したら、メンテナンスリリースにタグを付けて展開できます。
開発ブランチとは別のライブコードベースのブランチがある（またはライブリビジョンを知っていることでそれを作成できる）ことが重要です。そうすることで、ライブコードに修正をデプロイすることができます。新しい機能またはテストされていないコードをデプロイします。
新しいコードをデプロイするには、ディストリビューションのネイティブパッケージシステムを使用することをお勧めします。すべてのコードベースを含むパッケージがある場合、すべてのコードが一種のアトミック操作でデプロイされていることがわかり、インストールされているバージョンを一目で確認でき、パッケージのチェックサムを使用してコードベースを確認できます。ロールバックは、以前にインストールしたバージョンのパッケージをインストールする場合にすぎません。
これを実装する上で私が見ることができる唯一の障害は、単一のサーバーで実行されているさまざまな顧客のコードベースの複数のコピーがあるように見えることです。すべての顧客が同じファイルを実行し、コピーを使用しないようにコードを調整しようと思います。それがあなたにとってどれほど簡単かはわかりませんが、あなたが扱わなければならないコピーの数を減らすことはあなたの頭痛を大幅に減らすでしょう。
LAMPについておっしゃったように、PHPまたはコンパイルプロセスを必要としない別のスクリプト言語を使用していると思います。これは、おそらくすばらしいプロセスを見逃していることを意味します。継続的インテグレーションと呼ばれます。これは基本的に、コードがまだリリース可能な状態にあることを確認するためにコードが継続的にテストされていることを意味します。誰かが新しいコードをチェックインするたびに、プロセスがそれを受け取り、ビルドとテストのプロセスを実行します。コンパイルされた言語を使用します。通常、これを使用してコードがまだコンパイルされていることを確認します。すべての言語で、ユニットテスト（コードはテスト可能なユニットにありますね）と統合テストを実行する機会を利用する必要があります。Webサイトの場合、テスト統合テストはSeleniumです。Javaビルドでは、コードカバレッジとコードメトリックも測定して、時間の経過とともにどのように進行するかを確認します。JavaはHudsonですが、buildbotのようなものが他の言語でうまく機能する可能性があります。パッケージをビルドできます。 CIサーバーを使用します。
Puppet（ReductiveLabsの主力製品）を使い始めました。これは、sys-adminジョブを自動化するためのRubyベースのフレームワークです。私は数週間前にpuppetcampにいました、そしてここにビデオリンクがあります：
Luke Kanies Presenting --Puppet Intro
また、サンフランシスコのpuppetcampで行われたすべてのプレゼンテーションをご覧になりたい場合は、次のリンクをご覧ください。
他の人がPuppetをどのように使用したかについてのプレゼンテーション
楽しい。