1

Web アプリケーションを複数のサービスに分割しようとしています。それぞれが独自のリポジトリです。scm として git を使用していますが、scm (この場合は git) のワークフローに関する推奨事項があるかどうか疑問に思っています。

現在、ここに示されているものと同様のワークフローを使用しています: http://nvie.com/posts/a-successful-git-branching-model/ .

Github の仕組みなど、より単純なモデルに移行したいと思います: http://scottchacon.com/2011/08/31/github-flow.html。これは SOA の開発に適していますか?

誰かがこれについて意見を持っているかどうかに興味があります。ありがとう。

4

2 に答える 2

1

Github フローは機能ブランチを 1 つの製品に関連付けますが、実装できない理由はありません。ワークフロー オプションは、アプリケーションのデプロイ方法によって異なります。次の 3 つのコンポーネント サービスを持つ "MyApp" について考えてみましょう。

MyApp
|- ServiceA
|- ServiceB
|- ServiceC

とからServiceA独立してデプロイでき、さらに重要なことに、MyApp に含まれているがどのリポジトリにも存在しないコードとは無関係にそれらすべてをデプロイできる場合は、好みのワークフローである Github フローを各リポジトリとチームに適用するだけです。ServiceBServiceCService*

サービスが非常に絡み合っていて、デプロイServiceAに必ず のデプロイが必要な場合、ServiceBまたはさらに重要なことに、レポジトリMyAppの 1 つが進むたびに進めなければならないかなりの量の足場コードまたはルーティング コードを表す場合は、 submoduleやsubtreeServices*のようなものが必要になる場合があります。そのモデルでは、1 つの Github フローと、#4 と #5 の間に追加のステップ、つまりデプロイ前にサービスへのサブモジュール (またはサブツリー) の更新を収集します。あなた (およびあなたのチーム) が git を非常によく知っている場合を除き、サブツリーまたはサブモジュールなしでリポジトリをネストすることは避けます。

以上のことをすべて書きましたが、アプリケーションを分割する動機を深く検討することをお勧めします。これには利点とワークフローの成功がありますが、コストがかかります。履歴の「全体像」を把握することはより困難です。特定の状況では、次のようなツールを使用してデバッグするのが難しくなる可能性がありますgit bisect。新しい開発者はそれぞれ、コードベースを快適に操作できるようになる前に、git インフラストラクチャを学習する必要があります。これらは計画を放棄する理由ではなく、考える材料にすぎません。

于 2012-08-07T15:22:06.853 に答える
0

各サービスのリポジトリには、メッセージまたはコントラクトのリポジトリを指すサブモジュールが必要です。このレポは、追加のみのモデルを強制します。これは、メッセージまたはコントラクトが公開されると、それを消去できないことを意味します。新しいバージョンのマッサージを追加して、古いバージョンの使用をやめるだけです。これにより、段階的なロールアウトが可能になります。

于 2012-08-07T04:40:33.473 に答える