SVNからWebアプリケーションを実稼働環境に直接展開することは許容されますか

質問

SVNを運用展開に使用しない正当な理由がありますか、それとも単に個人的な好みのケースであり、SVNに対する実際のケースはありませんか？

バックグラウンド

私の職場には、SVNでリリースにタグを付けてから、それらのリリースをさまざまなWebサーバーに直接デプロイするsvn coかsvn switch、本番環境に直接組み込むという文化があります。

ビルドおよびデプロイスクリプトまたは何らかのフォームまたは自動デプロイを使用しないと、ドキュメント化されていないため統合環境設定が失われると考えているため、個人的にこれに問題があります。しかし、それ以上に、見過ごされていること、そのheadい頭をまだ育てていないことをすることには隠れた危険があるかもしれないという直感を持っています。

私は、さまざまな環境（ステージング、プリプロダクション、プロダクション）などにコードをデプロイする責任がある運用スタッフに懸念を提起しました。

編集：

ビルドとデプロイの意味：

たとえば、開発者が特定の環境にweb.config設定を追加する必要がある場合。通常、Web.configはsvnに保持されないため、これらのファイルは、自動ビルドスクリプトの形式なしで手動で更新されます。そのため、それらが失われたり、OPSがリリースのweb.configにフィールドを追加するのを忘れると、問題が発生します。

XMLPokeを使用して特定の環境に適したweb.configを自動的に生成するというビルドスクリプトは、各環境に必要なすべての変更を文書化するバージョン管理可能なスクリプトがあるという点で理想的です。

現在のビルドおよびデプロイ方法

問題のプロジェクトの場合、開発者は手動でリリースをビルドしますが、他のプロジェクトではビルド手順がNANTまたはMSBuildで自動化されています。

ほとんどのプロジェクトのデータベース移行は、DBスクリプト、移行スクリプト（Migrator.NET）、またはCMSパッケージを介して行われます。

CIは通常、チェックインごとにTeam Cityによって行われます。すべてのチケットはブランチで行われ、トランクにチェックインする前に検証と正確性/品質についてピアレビューされるコードレビュープロセスがあります（うまく機能します）。

ただし、実際のコードの展開は、タグ付きリリースのチェックアウトまたはより一般的にはSVNスイッチのいずれかを介して、ほとんど常にSVNを介して行われます。これは、リポジトリをデプロイプロセスの一部として使用しているという点で奇妙に思えます。

通常、構成はあまり頻繁に変更されず、構成ファイルに含まれるのは環境固有の情報のみです。それ以外はすべてデータベースにあります。

これがうまくいくと誤解しないでください。ただし、自動化されたビルドとデプロイを試してみてください。これをRailsとCapistranoで使用し、Cygwin、Nant、SSHを使用した個人プロジェクトにも使用しました。

さらに重要なことは、自動化されたビルドとデプロイを使用するように同僚を変更するには、非常に具体的な有効な引数が必要だということです。

それとも、SVNを使用して本番環境にデプロイすることに対して実際に有効な引数はありませんか？

私の経験から、利点と欠点の両方があります。

長所：

• 本番サーバーで緊急のホットフィックスを作成した後、そこから直接チェックインできる場合があります。（理論的には、セキュリティ上の理由から、本番サーバーからレポへの読み取り専用アクセスを使用することは常に良い考えです。）

• シンプルさ：すぐに配信できますが、ここで他の人が述べたように、更新スクリプトスキームへの切り替えは簡単です。

短所：

• svn upDBの更新中にシステムが不安定になる可能性があります。トラフィックの多いサイトの場合、これは一部のユーザーがせいぜいエラーメッセージ、破損したページ、または空のページにヒットすることを意味します。まあ、それは私たちがさまざまな社会サービスで頻繁に見ているものです。ただし、優れたサービスは、更新中にシステムをメンテナンスモードにするという意味で「原子的に」実行します。（あなたはredditを破った！）

• 競合：プロダクションサーバーでの突然の競合を解決するのはひどい考えです。ここでも、修正中にサービスが不安定になります。

• 実稼働サーバー上の無関係なファイル。これはユーザーに属している場合もそうでない場合もありますが、もちろんリポジトリ内の適切なサブツリーをチェックアウトすることで回避できます。

• セキュリティ：本番サーバーにアクセスしたかどうかにかかわらず、合法かどうかに関係なく、レポジトリ、場合によっては他の製品にもアクセスできます。書き込みアクセスも可能です。全体的に内部SVNサーバーを外部に開放することは悪い考えです。ソースリポジトリは、会社のファイアウォールの背後にある必要があります。

• とにかく、たとえばDB構造の更新、cronジョブの管理などの更新スクリプトがあるので、すべてを実行するスクリプトがないのはなぜですか。-つまり、事前にパッケージ化された最新リリースの取得、メンテナンスモードへの切り替え、ソースの更新、リリース固有のスクリプトの実行など。

編集：まだSVNスキームを使用している場合は、Apacheの設定でこれを忘れないでください：

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

職場でCIサーバーをセットアップしました。CIサーバーは、ユニットテストが正常に合格したと仮定して、インストーラーを自動的に作成します。約1日の作業で、セットアップしてからそれ以上のことができました。

リリース/インストーラー/運用Webサイトの構成に手動プロセスがある場合、常に自分自身と会社の時間を節約できます。質問から、セットアッププロセスには手動の構成手順があるように見えるため、これは適切です。

参考として、シングルクリックビルドプロセスが短期から中期にどのようにあなたを救うかについて、ジョエル自身が語っています。

SVNに適切なチェックインコントロールがあることを確認します。たとえば、これを考慮してください-

• 機能はリリースのためにチェックインされます
• コードがステージングに展開され、QAが仕事をする
• バグが修正され、テストの別のラウンドが行われます（ただし、チームで機能します）
• 前製品の同上
• 本番にデプロイする

pre-prodステージの後に誰かが誤ってチェックインを行った場合、何かを壊すリスクがあります。これが制御されている場合-バグ修正を除いて事前生産中に許可されていないチェックインのように-私はリスクを見ません。

更新：構成ファイルをチェックインしないと、問題が発生するのを待っています。「お願いします、早く！」以外、これに関するアドバイスは本当にできません。

リポジトリの外に何もない限り、問題ないようです。実際、プロジェクトの最初の数か月間は、展開ツールに時間を費やすべきではないと考えています。原因はデプロイメントが多すぎて、正式なリリースプロセスについて悩むのに十分な顧客がいないためです。

しかし、プロジェクトが1年ほど経過すると、展開ツールへの投資を検討する価値があります。単純な理由は

• ビジネスが成長するため、複数のサーバーでホストする予定です
• 特定の環境にバグがある可能性があり、バグを再現する場所がありません。tar-untar-forget_about_home_for_a_weekプロセスを使用せずにセットアップする簡単な方法はありません。
• 誰かがビルドを壊す可能性があります。誰がビルドを壊した

説得したい場合は、内部テストまたはQA用に別のサーバーをセットアップするよう依頼してください。