展開戦略を改善する

当社で開発したeコマースアプリがあります。その合理的な標準のLAMPアプリケーションは、約3年間オンとオフを繰り返してきました。テストドメインでアプリケーションを開発し、ここで新しい機能を追加してバグなどを修正します。バグの追跡と機能の開発はすべて、ホストされているSubversionソリューション（unfuddle.com）内で管理されます。バグが報告されると、テストドメインでこれらの修正を行い、バグが修正されたことに満足したらsvnに変更をコミットします。この同じ手順に従って、新しい機能を追加します。

サーバー全体のシステムとアプリケーションの一般的なアーキテクチャを指摘する価値があります。新しい機能が開発されるたびに、アプリケーション（常に制御するサーバー）を使用して、この更新をすべてのサイトに展開します。当社のシステムを使用する各サイトは、本質的にコードベースの95％でまったく同じファイルを使用しています。各サイト内には、そのサイト専用のファイル（cssファイル/イメージなど）を含むいくつかのフォルダーがあります。それ以外の各サイト間の違いは、各サイトデータベース内のさまざまな構成設定によって定義されます。

これは実際の展開そのものになります。ある種の更新を展開する準備ができたら、テストサイトが存在するサーバーでコマンドを実行します。これは、コピーコマンド（cp -fru / testsite / / othersite /）を実行し、変更された日付に基づいてファイルを更新する各vhost強制を通過します。ホストする各追加サーバーには、運用コードベースを再同期する仮想ホストがあり、そのサーバー上のすべてのサイトでコピー手順を繰り返します。このプロセス中に、上書きしたくないファイルを削除し、コピーが完了したら元に戻します。ロールアウトスクリプトは、SQLコマンドを適用して各データベースを変更したり、フィールドや新しいテーブルを追加するなど、他の多くの機能を実行します。

私たちのプロセスが十分に安定しておらず、フォールトトレラントではなく、少し強引な方法であるという懸念がますます高まっています。また、ブランチやタグを使用していないため、新しい機能に取り組むことで重要なバグ修正を展開できないという立場があるため、Subversionを最大限に活用していないことも認識しています。また、サーバー間でファイルの複製が非常に多いことも間違っているようです。また、ロールアウトしたばかりのロールバックを簡単に実行することもできません。各ロールアウトの前にdiffを実行して、変更されるファイルのリストを取得できるようにします。これにより、何が変更されたかを知ることができますが、ロールバックのプロセスにはまだ問題があります。データベースに関しては、潜在的なソリューションとしてdbdeployを検討し始めました。しかし、本当に必要なのは、ファイルの管理と展開を改善する方法に関する一般的なガイダンスです。理想的には、ファイル管理をリポジトリにより密接にリンクして、ロールアウト/ロールバックがsvnにより密接に接続されるようにします。exportコマンドを使用して、サイトファイルがレポファイルと同じであることを確認するようなもの。ただし、ソリューションがサーバー周辺のファイルレプリケーションも停止する可能性がある場合も良いでしょう。

現在の方法を無視すると、他の人がどのように同じ問題に取り組んでいるかを聞くことは本当に良いことです。

要約すると ...

• 複数のサーバー間でファイルをsvnと同期したままにする最良の方法は何ですか？
• ファイルの複製をどのように防ぐ必要がありますか？シンボリックリンク/他に何か？
• 新しい機能を開発して古い機能を修正できるように、リポジトリをどのように構成する必要がありますか？
• ロールアウト/ロールバックをトリガーするにはどうすればよいですか？

前もって感謝します

編集：

この種のタスクにPhingとCapistranoを使用することについて、最近多くの良いことを読みました。誰でも彼らについての情報と、彼らがこの種の仕事にどれほど良いかについての情報を提供できますか？

リリースを行うための私のアドバイスは、機能リリースとメンテナンスリリースを用意することです。機能リリースは、新しい機能を取得するリリースです。これらはSubversionトランクに追加されます。これらが完全な機能だと思うとき、あなたはこれらをリリースブランチにブランチします。QAプロセスがこのリリースに満足したら、リリースにタグを付け、サーバーにコードをデプロイします。

あなたはバグレポートを取得するときに今、あなたはブランチにこの修正をコミットし、トランクにポートこと。修正されたバグの数に満足したら、メンテナンスリリースにタグを付けて展開できます。

開発ブランチとは別のライブコードベースのブランチを持っている（またはライブリビジョンを知ることでブランチを作成できる）ことが重要です。そうすることで、ライブコードに修正を展開することができます。新機能またはテストされていないコードを展開します。

新しいコードをデプロイするには、ディストリビューションのネイティブパッケージシステムを使用することをお勧めします。すべてのコードベースを含むパッケージがある場合、すべてのコードが一種のアトミック操作でデプロイされていることがわかります。インストールされているバージョンが一目でわかり、パッケージのチェックサムを使用してコードベースを検証できます。ロールバックは、以前にインストールされたバージョンのパッケージをインストールする場合にすぎません。

これを実装しているあなたに見える唯一の障害は、単一のサーバーで実行しているさまざまな顧客のコードベースのコピーが複数あるように見えることです。すべての顧客が同じファイルを実行し、コピーを使用しないようにコードを調整しようとします。それがどれほど簡単かはわかりませんが、対処しなければならないコピーの数を減らすと、頭痛が大幅に軽減されます。

LAMPについて述べたように、コンパイルプロセスを必要としないPHPまたは別のスクリプト言語を使用していると想定しています。これはおそらく、継続的インテグレーションと呼ばれる素晴らしいプロセスを見逃していることを意味します。これが基本的に意味することは、コードが継続的にテストされて、リリース可能な状態にあることを確認することです。誰かが新しいコードをチェックインするたびに、プロセスがそれを取得し、ビルドおよびテストプロセスを実行します。コンパイルされた言語では、通常これを使用して、コードがまだコンパイルされていることを確認します。すべての言語で、ユニットテスト（コードはテスト可能なユニットになっていますよね）と統合テストを実行する必要があります。Webサイトの場合、統合テストをテストするための優れたツールはSeleniumです。Javaビルドでは、コードカバレッジとコードメトリックも測定して、時間の経過とともに進捗を確認します。Javaで見つかった最高のCIサーバーはHudsonですが、buildbotのようなものは他の言語でより適切に動作する可能性があります。CIサーバーを使用してパッケージをビルドできます。

Puppet（Reductive Labsの主力製品）の使用を開始しました。sys-adminジョブを自動化するためのRubyベースのフレームワークです。私は数週間前にpuppetcampにいましたが、ここにビデオリンクがあります：

ルークカニーズプレゼンティング-パペットイントロ

また、サンフランシスコのパペットキャンプで行われたすべてのプレゼンテーションをご覧になりたい場合は、次のリンクをご覧ください。

他の人がどのようにPuppetを使用したかについてのプレゼンテーション

楽しい。