6

大規模な SOA プログラムの一環として、Oracle Service Bus で多くの Web サービスを開発しています。現在、これらは SVN で管理されています。SVN を使用すると、個々のフォルダー レベルでタグとブランチを作成できるため、個々のサービスのバージョン管理を管理できます。以下は、私たちが従う典型的な構造です。


+- Services
   |
   +- Service1
   |   |
   |   +- tags
   |   |
   |   +- branch1
   |   |
   |   +- trunk
   |       |
   |       +- artefacts
   |
   +- Service2
   |   |
   |   +- tags
   |   |
   |   +- branch1
   |   |
   |   +- trunk
   |       |
   |       +- artefacts
   |
   +- service N
Git では、フォルダー レベルでのバージョン管理は絶対に許可されていません。150 以上の Web サービスがあり、それぞれに独自の開発サイクルがあり、デプロイ可能なものに組み込むことができます。私たちの現在の戦略を Git に直接マッピングすると、各サービスを git リポジトリとして保持し、git の原則にも従いますが、150 を超える git リポジトリを持つことになります。

このアプローチは正しいですか？より良いアプローチはありますか？多数のWebサービスの開発で同様のユースケースを持っている人はいますか?

また、ある種の論理グループを作成し、グループの git リポジトリを作成することも検討しましたが、個々のサービスのバージョン管理とタグ付けがうまくいかないため、それは間違った戦略だと思います。この種のグループ化を管理できる git の他の方法はありますか?

4

1 に答える 1

9

サブモジュールとレポ管理

必要に応じて、それらをサブモジュールで再帰的にグループ化できます。ProGitの本はこれを非常によく説明しています。gitoliteを使用すると、非常に多数のリポジトリを非常に簡単に管理できます。ユーザーがアクセスできるリポジトリと、そのリポジトリ内のブランチに至るまでです。

機能ごとの分岐

標準の SVN 分岐戦略の良い代替案については、「Branch per Feature」をグーグルで検索すると、この正確なテーマに関する私の記事が表示されるはずです。私たちが思いついた戦略は、部分的には多数のリポジトリを扱うことによるものでした。

あなたは Oracle を使用しているので、誰にとっても明らかなことを指摘しておく必要があります。データベースで統合しないでください。もしそうなら、ここで読むのをやめてください。ご冥福をお祈りいたします。

建築用接着剤

SOA に従って、コントラクトまたはバージョン管理されたメッセージを保持する 1 つのリポジトリを指定します。バージョン管理されているとは、同じメッセージの複数のバージョンをサポートすることを意味します (通常は 3: 現在、非推奨、および特定の例外 - 以前のものはすべて未処理の例外を発生させる必要があります)。クライアント/サーバーおよびパブリッシュ/サブスクライブの関係を処理する際に、スケールアウトされたサービスの新しいバージョンをアウトし、ゼロ ダウンタイムのデプロイ中に古いクライアントと新しいクライアントをサポートします。このリポジトリは、統合のエンドポイントを持つすべてのリポジトリのサブモジュールです。

フック

このリポジトリにフックを追加して、アーキテクチャ レベルでOCP (Open Close Principle)を具体化する変更のみを転送できるようにします。公開されたクラスの更新を許可しないだけです。公開されたら、それをサポートする必要があります。Gitolite を使用すると、フックをリモートで簡単に管理できます。それ自体がそれらを使用して、機能を透過的に追加します。

コントラクトの移行

さらに、イベント ソーシング状態を使用すると、メッセージ バージョンの移行が特に簡単になります。これは CQRS (Command Query Responsibility Segregation) のサブセットです。マイクロソフトでさえそれを行っており、私はそれに関与できて幸運でした. サービス外に存在するメッセージとサービス内で使用されるメッセージの管理に関しては、 DDD (ドメイン駆動設計)のコンテキスト マップと腐敗防止レイヤーが関連しています。これに関するさらなるガイドラインは、ユビキタス言語 (これも DDD から) およびドメイン固有言語 (Martin Fowler の記事はこちら) にあります。

実装

他の「メッセージ バス」アイデアの潜在的に大きな技術フットプリントを回避するために、配信には0MQ (ZeroMQ)を検討してください。これにより、永続的なキューイングの責任が肩にかかり、全体的により堅牢な戦略が追い出されます。それがどのように達成されるかの手がかりについては、前の段落を参照してください。Windows 環境で WCF に直面している場合は、サービス スタックを検討してください。テクノロジーに含まれるマジック/自動生成コードが少なければ少ないほど、競合解決のシナリオ、展開、テストなどで発生する困難な問題が少なくなります。

于 2012-10-12T17:41:07.907 に答える