3

現在、私のワークフローは次のとおりです。

ローカルで、作業中の各Webサイトでgitリポジトリを維持しています。何かを公開するときは、フォルダーを圧縮し、この単一ファイルをssh経由で本番サーバーにアップロードしてから、解凍し、変更をテストして、変更を移動します。ライブフォルダーに移動すると、.gitフォルダーが削除されます。

ライブサーバーでgitリポジトリを使用するのは良い考えかと思いましたが、最初はそう思われますが、ローカル開発マシンと比較して本番サーバーで変更が同じように見えない場合は問題になる可能性があります...これにより火災が発生する可能性があります...本番サーバーのあるフォルダーにベアリポジトリを作成し、そこからパブリックフォルダーにクローンを作成して、ローカルマシンからベアリポジトリに更新をプッシュし、パブリックフォルダーのベアからプルするのはどうでしょうか。本番サーバーの...誰かがフィードバックを提供してくれるかもしれません。

後でcapistranohttp ://capify.orgについて読みましたが、このソフトウェアの使用経験はありません...

あなたの経験では、ウェブサイトの展開/更新を達成するためのベストプラクティス/方法論は何ですか？

事前に、そしてあなたのフィードバックに感謝します。

4

3 に答える 3

2

私たちの方法がベストプラクティスとは言えないと思いますが、それは私たちに役立っています。

アプリケーション用にいくつかの大規模なデータベース（20GB以上）があるため、各開発者のコ​​ンピューターでローカルコピーを維持することは実際には選択肢ではありませんでした。ライブデータベースに対して開発しなくても、データベースに対して開発を行う必要があります。それは可能な限り本物に近いです。

結果として、中央のWebサーバーも使用し、Subversionトランクの開発ブランチをそのサーバー上に保持します。通常、システムの同じ部分で一度に作業することはありませんが、それが必要な場合、または誰かが大幅な変更を行っている場合は、トランクを分岐して、開発サーバーに新しい仮想ホストを作成します。

また、運用サーバーでコードをチェックアウトしているため、テストが終了したら、運用サーバーでsvn更新を実行するだけです。sshを使用してすべてのサーバーでupdateコマンドを実行するスクリプトを実装しました。コードベースが大きく、アップロードに時間がかかるため、これは非常に便利です。Subversionは、実際に変更されたファイルのみをコピーするため、はるかに高速です。

これは私たちにとって非常にうまく機能しており、更新時に競合が発生する可能性があるため、本番サーバーに直接変更を加えることだけに注意する必要があります（もちろん最初からノーノーです）。

于 2009-03-21T00:00:35.273 に答える
0

キャピストラーノは素晴らしいです。デフォルトのレシピドキュメントはむらがありますが、メーリングリストはアクティブであり、セットアップは非常に簡単です。Railsを実行していますか？Railsアプリ用の優れた機能がいくつか組み込まれていますが、他の種類のWebアプリでもかなり頻繁に使用されます。

CapistranoをベースにしたWebistranoもありますが、Webフロントエンドがあります。自分で使ったことがない。少なくともRailsユーザーの間で、ある程度の注目を集めていると思われるもう1つのデプロイメントシステムは、VladtheDeployerです。

于 2009-03-21T00:21:30.120 に答える
0

サーバー上にリポジトリのコピーがあるとは考えもしませんでした。それを読んだ後、私はそれがクールかもしれないと思いました.しかし、テストせずにライブ環境でファイルを直接更新することは良い考えではありません.

ライブ環境 (Web サーバー + DB バージョン、存在する場合) と正確に一致するセカンダリ環境を常に更新し、そこでテストする必要があります。すべてがうまくいった場合は、ライブ サイトをメンテナンスし、ファイルを更新して、再びライブに移行します。

したがって、ライブ サイトをリポジトリのコピーにすることはしませんが、テスト環境で行うことはできます。SSH + 圧縮時間を節約でき、さらに、テストしたい特定のリビジョンをチェックアウトできます。

于 2009-03-20T23:53:01.373 に答える