標準のWebプロジェクトでは、コードアセットとしてサーバーサイドコード、サーバーページ、JavaScriptおよびCSSファイルがあります。サーバー側のコードでは、コードをコンパイル/パッケージ化/デプロイするためのテストスイートとスクリプト化されたビルドプロセスを用意するのがかなり標準的な方法です。ビルドは通常、QA環境でコードがテストおよび検証された後、スケジュールに従って実行されます。
反対に、プレゼンテーション層のコードアセットを自由にプッシュできるようにする必要があることがよくあります。コンパイルや再起動を必要としないため、これは実行可能ですが、このコードはサーバー側のコードに結合されており、壊れた場合はサイト全体が破壊される可能性が高いと思います。したがって、ビルドサイクルの外にプッシュしないでください。
このためのベストプラクティスと見なされるものは何ですか?
番号!
私たちは仕事でC#+ ASP.netを使用していますが、その理由は次のとおりです(他の技術にも適用されますが、少し異なる形式で想像します)。
UIが存在しないコントロールを参照している場合はどうなりますか?
-Big Yellow Exception.
UIが存在しないアセンブリを参照している場合はどうなりますか?
-Big Yellow Exception.
JSファイルに、そこにない特定のDOM要素を参照するコードがある場合はどうなりますか?
-JavaScript Exception.
ここでパターンを見ることができます!
とにかく、なぜ部分的なデプロイをしたいのですか? CIサーバー(TeamCity)を使用して、デプロイ用のビルドアーティファクトを生成します。つまり、完全にプリコンパイルされた自己完結型のWebサイトを、古いWebサイトの上に単純に抽出されたZipファイルに生成します。そうすれば、config/js/css/images/whateverへの変更はバージョン管理を経由する必要があるため、問題が発生する可能性はさらに低くなります。
コード/テンプレート/画像/何が会話のどちら側にあるかは気にしません。それがシステムの一部である場合、それはシステムの一部であり、他のすべてと同様に管理および展開する必要があります。
注:これは、システムでサポートされているユーザー生成コンテンツとは異なります。これもバージョン管理されている可能性がありますが、システムコンポーネントとは異なる次元に存在します。
番号。
それにもかかわらず、プレゼンテーションコードはコードです。コンパイルされるのではなく解釈されるからといって、ビルドプロセスをダックするためのフリーパスが必要であるとは限りません。
開発者がソース管理内でこれらの変更を複製することをどのように保証しますか?ライブ環境は、ソース管理からリリースされたコードと一致する必要があります。
これらの小さな無害な変更を行う習慣がある場合、バグが発生し始めます。