10

理想的な世界では、開発プロセスは完璧であり、実行中のアプリケーションを「ホットフィックス」する必要がないほど徹底的にテストされた定期的なリリースになります。

しかし、残念ながら、私たちは現実の世界に住んでおり、次のリリースでコーディングが忙しくなるまで、バグがすり抜けて醜い頭をもたげないことがあります。そして、バグを今すぐ修正する必要があります。次の予定されているリリースの一部としてではありません。今夜は交通量が減ったときではありません。 今。

このニーズにどのように対処しますか？これは、コードを優れた個別のクラスライブラリにリファクタリングするなど、優れた設計手法に反する可能性があります。

本番サーバーでマークアップとストアドプロシージャを手動で編集することは、災害のレシピになる可能性がありますが、災害を回避することもできます。

メンテナンスのニーズと優れたコーディング手法のバランスを見つけるための、アプリケーションの設計と展開の手法に関する優れた戦略は何ですか？

4

3 に答える 3

2

[リリースする前に多くのテストを行っていますが、]これは次のとおりです。

SVNは次のようになります。

/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3

これで、リリースするたびにタグを作成し、最終的に本番環境でチェックアウトします。本番環境を実行する前に、[サーバーは少ないですが]本番環境とほぼ同じステージングを実行します。

「タグ」を作成する理由には、本番コードでのアプリの設定の一部が「トランク」とはわずかに異なる（たとえば、エラーはメールで送信されないがログに記録される）ことが含まれるため、タグを作成してそれらの変更をコミットすることは理にかなっています。次に、本番クラスターでチェックアウトします。

これで、問題を修正する必要があるときはいつでも、最初にtags / xで修正し、次にタグから修正して問題svn updateありません。ステージングを実行することがありますが、いくつかの問題（たとえば、スペルなどのマイナー/些細な修正）でステージングをバイパスします。

覚えておくべき唯一のことは、からtags/xへのすべてのパッチを適用することtrunkです。

複数のサーバーがある場合、Capistranoはそれらすべての操作を実行するのに非常に役立ちます。

于 2008-09-27T15:42:32.437 に答える
0

1つの戦略は、さまざまなコンポーネントに宣言型の外部構成ファイルを多用することです。

この例：

  • IBatis/IBatis.NETなどのツールを介したデータベースアクセス/オブジェクトリレーショナルマッピング
  • JLog / NLogなどのツールを介したロギング
  • Spring / Spring.NETなどのツールを介した依存性注入

このようにして、多くの場合、主要なコンポーネントを個別の部分に分割し、再コンパイルせずに実行中のアプリケーションを修正し、ソース管理をシームレスに使用できます（特に、ソース管理に手動の作業が必要なストアドプロシージャと比較して）。

于 2008-09-27T15:51:03.150 に答える
0

コードをフレームワークコードとビジネスのカスタマイズに分割します。ビジネスカスタマイズクラスは、別のクラスローダーを使用してロードされ、本番環境の実行中のインスタンスに変更を送信するためのツールがあります。クラスで変更が必要な場合はいつでも、それを変更して実行中のインスタンスに送信します。実行中のインスタンスは古いクラスローダーを拒否し、新しいクラスローダーのインセンスを使用してクラスを再度ロードします。これは、EJBのJbossホットデプロイに似ています。

于 2008-09-27T16:18:13.567 に答える