17

私の経験から言えば、Web 開発プロセス中に遭遇する大きな問題の 1 つは、さまざまなサーバー間でさまざまなセットアップを最新の状態に保ち、安全に保つことです。

私の会社には独自の CMS があり、現在 100 以上のサーバーにインストールされています。現時点では、ハックっぽい FTP ベースのアプローチを使用し、特定の場所でアップグレード スクリプトを組み合わせて、すべての CMS セットアップをアップグレードしています。これらのセットアップを効率的に管理することは、複数のカスタム モジュールが関係している場合、ますます困難でリスクが高くなります。

  • Web アプリケーションの複数のセットアップを安全かつ最新の状態に保つ最善の方法は何ですか?
  • どのようにしますか？
  • クライアントに対する柔軟性を維持しながら、アプリケーションの複数の「ブランチ」を効率的に管理できるようにするために、アプリケーションのモジュール性に関する具体的なヒントはありますか?

いくつかのコンテキスト情報: 私たちは主に LAMP スタックで開発しています。CMS の販売に役立つ主な要因の 1 つは、クライアントが必要とするほとんどすべてのものをプラグインできることです。これは、10 行から 10,000 行のカスタム コードになる可能性があります。

多くのカスタム作業は、非常に小さなコードで構成されています。Subversion でこれらすべての小さなコードを管理するのは、非常に面倒で非効率的だと思います (毎週約 2 つの Web サイトを配信しているため、多くのブランチが発生することになります)。

何か見落としがある場合は、ぜひお聞かせください。

前もって感謝します。

まとめ:まず、すべての回答に感謝します。これらはすべて本当に役に立ちます。

私はおそらく SVN ベースのアプローチを使用します。これにより、benlumleyのソリューションが私が使用するものに最も近くなります。この質問への回答は、他のユースケースでは異なる可能性があるため、実行の最後に最も投票数の多い回答を受け入れます。

回答を調べて、最も付加価値があると思うものに投票してください。

4

13 に答える 13

8

バージョン管理システムを使用し、変更する必要のあるコードの一部を「分岐」することが、堅牢性と効率の点で最良のアプローチになる可能性があると思います。

分散バージョンシステムは、必要に応じていくつかの変更をローカルに保ちながら、さまざまな「ブランチ」で「コア」機能をシームレスに更新できるため、ニーズに最も適している可能性があります。

編集：分散バージョンシステムですべてを最新の状態に保つことは、あなたが期待しているものよりもはるかに面倒ではないと確信しています：ローカルの他の場所で必要になることはないと確信している変更を維持できます。分散アスペクトとは、デプロイされた各アプリケーションが実際には他のアプリケーションから独立しており、伝播しようとしている修正のみが伝播されることを意味します。

于 2009-02-02T15:17:52.473 に答える
6

アプリケーションのカスタマイズに多くの小さなコードの変更が含まれる場合、これはアプリケーションの設計に欠陥があることを示している可能性があります。アプリケーションには、一連の安定したコア コード、プラグインするカスタム ライブラリの拡張ポイント、テンプレートを使用して外観を変更する機能、構成ファイルを使用して動作を変更しプラグインをインストールする機能が必要です。このように、クライアントごとに個別の SVN ブランチは必要ありません。代わりに、コア コードと拡張プラグイン ライブラリを通常どおりソース管理に保管してください。別のリポジトリで、クライアントごとにフォルダーを作成し、すべてのテンプレートと構成ファイルをそこに保持します。

今のところ、SVN ブランチを作成することが、正気を保つのに役立つ唯一の解決策かもしれません。現在の状態では、間違いを犯してクライアントのサイトを台無しにすることはほぼ避けられません。少なくともブランチを使用すると、クライアントごとに安定したコード ベースが保証されます。SVN ブランチに関する唯一の問題は、ブランチ内のファイルを移動または名前変更した場合、その変更をトランクにマージすることができないことです (手動で行う必要があります)。

幸運を！

編集: 上記で概説したすべての原則を使用して適切に設計されたアプリケーションの例については、Magento E-Commerceを参照してください。Magento は、これまでに使用した中で最も強力で拡張性が高く、カスタマイズが容易な Web アプリケーションです。

于 2009-02-05T05:58:36.470 に答える
4

私は間違っているかもしれませんが、Aron が求めているのはバージョン管理ではないように思えます。バージョニングは優れており、彼らはすでにそれを使用していると確信していますが、何百ものカスタマイズされたインストールの更新を管理するには、別のものが必要です。

私は、専用のパッケージ システムに沿って何かを考えています。モジュールのすべてのバージョンで、個々の依存関係と「保証された互換性」を追跡し、この情報を使用して「安全な」モジュールのみを自動的に更新する必要があります。

たとえば、「Wiki」モジュールの新しいバージョン 3 を作成したとしましょう。アプリケーションを実行しているすべてのサーバーに新しいバージョンを反映させたいと考えていますが、バージョン 2 以降の Wiki モジュール内のインターフェイスの 1 つに変更を加えました。すべてのデフォルト インストールでは問題ありませんが、壊れる可能性があります。古いインターフェイスの上にカスタム拡張機能をインストールします。よく計画されたパッケージ システムがこれを処理します。

セキュリティの問題に対処するには、パッチでデジタル署名を使用することを検討する必要があります。公開鍵ベースの署名に利用できる優れたライブラリがたくさんあるので、選択したプラットフォームの標準と思われるものを使用してください。

于 2009-02-05T02:44:53.677 に答える
4

誰かがこれを言ったかどうかはわかりませんが、ここには長い応答がたくさんあり、すべてを読んでいません.

バージョン管理へのより良いアプローチは、CMS を独自のリポジトリに独自に配置し、各プロジェクトを独自に配置することだと思います。（または、これらすべてが1つのレポ内のサブフォルダーである可能性があります）

その後、そのトランク (または必要に応じて特定のブランチ/タグ) を、それを必要とする各プロジェクトで svn:external として使用できます。このようにして、CMS に加えた更新をそのリポジトリにコミットして戻すことができ、svn が更新されたとき (または外部が svn:switch されたとき) に他のプロジェクトに取り込まれます。

これを簡単にする一環として、svn externals が適切に機能するように、CMS とカスタム機能が異なるフォルダーにあることを確認する必要があります。

いいえ:

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(必要に応じて、www フォルダーの下に cms と lib を配置できます)

これにより、必要に応じて各プロジェクトを分岐/タグ付けできます。ブランチ/タグごとに svn:external の場所を切り替えることもできます。

変更をライブで取得するという点では、すぐに ftp を取り除き、rsync または svn checkout/exports を使用することをお勧めします。どちらもうまく機能します。選択はあなた次第です。

サーバーへのsvnエクスポートをrsyncするrsyncルートの経験が最も豊富です。このルートをたどる場合は、いくつかのシェル スクリプトを記述します。テスト シェル スクリプトを作成して、-n フラグを使用して、ファイルをアップロードせずにアップロードするファイルを表示できます。私は通常、環境ごとに 1 組のスクリプトを使用します。1 つはテスト用で、もう 1 つは実際に実行するためです。

アクセスを許可するサーバーの安全性によっては、アップロードを送信するためにパスワードを必要としない共有キー認証も役立つ場合があります。

一括アップグレードを行うための別のシェル スクリプトを維持することもできます。これは、アップグレードする各プロジェクトに関連するシェル スクリプトを呼び出すだけです。

于 2009-02-07T08:50:36.073 に答える
2

Drupalを見たことがありますか？いいえ、持っているものをデプロイして置き換えるのではなく、カスタマイズやサイト固有のモジュールをどのように処理するかを確認しますか？

基本的に、あなたがホストしているすべてのサイトのためのディレクトリを持っている「サイト」フォルダがあります。各フォルダー内には、異なるデータベースを指定できる個別のsettings.phpがあります。最後に、（オプションで）サイト内に「themes」および「modules」フォルダーを作成できます。

これにより、特定のモジュールのサイト固有のカスタマイズを実行し、特定のモジュールをそれらのサイトに制限することができます。その結果、すべての大部分が完全に同一であり、違いだけが複製されるサイトになります。それをアップグレードとアップデートを処理する方法と組み合わせると、実行可能なモデルが得られる可能性があります。

于 2009-02-02T12:34:49.683 に答える
2

自己更新プロセスをコードに組み込みます。
更新をチェックし、クライアント用に構成したとき/場所/方法で実行します。

ロールアウトの前に新しいビルドでテストする必要があるモジュールのある種のリスト（カスタムかどうか）を作成する必要があります。アップデートをデプロイするときは、これらが正しくテストおよび統合されていることを確認する必要があります。うまくいけば、あなたのデザインはこれを処理することができます。

更新は、理想的にはいくつかの重要なステップです。

  1. a）バックアップしてバックアウトできるようにします。いつでも更新全体を取り消すことができるはずです。つまり、最初にアプリケーションとデータベースのローカルアーカイブを作成することを意味します。

    b）監視プロセスの更新-CMSシステムの電話を自宅に置いて、新しいビルドを探します。

    c）可用性に関する更新のスケジュール-更新が利用可能になった2番目に更新を実行したくない場合があります。これは、深夜にシステム更新を自動的に行うために、ある種のcron/エージェントを作成する必要があることを意味します。週末または特定の日に更新するクライアントの要件を検討することもできます。また、更新のロールアウトをずらして、1日で1000のクライアントを更新せず、テクニカルサポートを取得することもできます。ある種の時差ロールアウトはあなたにとって有益かもしれません。

    d）メンテナンスモードを追加してサイトを更新します-サイトをメンテナンスモードにします。

    e）SVNチェックアウトまたはダウンロード可能なパッケージ-理想的には、svn checkoutを介してデプロイできます。そうでない場合は、svnで生成されたパッケージをクライアントサイトにデプロイできるアーカイブに配信するようにサーバーをセットアップします。

    f）DBスクリプトの展開-データベースをバックアップし、更新し、データを入力します

    g）サイトコードの更新-このすべてが1つのステップで機能します。

    h）いくつかのテストを実行します。 コードにセルフテストが組み込まれている場合は、それが理想的です。

于 2009-02-09T09:50:46.270 に答える
1

人々がすでに述べたように、バージョン管理（機能性のためにSubversionを好む）と分岐を使用することが最良のオプションです。Cruisecontrolと呼ばれるsourceforgeで利用可能な別のオープンソースソフトウェア。その驚くべきことに、コードの変更やサーバーに追加された新しいコードが自動的に認識され、ビルドされるように、subversionを使用してCruisecontrolを構成します。それはあなたの時間の地獄を節約します。

私は自分の会社でも同じことをしました。4つのプロジェクトがあり、そのプロジェクトを異なるサーバーにデプロイする必要があります。コードベースを変更すると自動ビルドがトリガーされるようにcruiseconrolを設定しました。別のスクリプトがそのビルドをサーバーにデプロイします。あなたは行ってもいいです。

于 2009-02-05T02:27:14.353 に答える
1

うーん、構成ファイルを追加するのはアイデアでしょうか? あなたは、たくさんの小さなスクリプトが何かをしていると書きました。それらをソースに組み込み、構成ファイルでそれらを操縦した場合、それは「簡単」ではありませんか?

一方、すべての顧客に支店を持つことは、指数関数的な成長のように思えます。そして、どの領域で何かを行ったかを「知り」、他のすべてのブランチでも変更を「行う」ことを忘れないようにするにはどうすればよいでしょうか。それは私にはかなり醜く見えます。

リビジョン管理、構成オプション、および/または展開レシートの組み合わせは、「良い」アイデアのようです.....

于 2009-02-07T08:58:05.123 に答える
1

Puppet (アプリの展開を含むシステム管理用) やCapistrano (RubyOnRails でのアプリの展開用ですが、これらに限定されません)などのツールを見たことがありますか?

于 2009-02-02T10:35:53.137 に答える
1

1 つのオプションは、読み取り専用のバージョン管理システム (Subversion) をセットアップすることです。リポジトリへのアクセスを CMS に統合し、メニューから更新を呼び出すか、ユーザーに更新に関する選択肢を与えたくない場合は自動的に呼び出すことができます (重要な場合があります)。バージョン管理システムを使用すると、さまざまなブランチを簡単に保持することもできます

于 2009-02-02T10:36:41.200 に答える