マルチサイドプロジェクトでバージョン管理をどのように処理しますか？

幅広い質問であることは承知しておりますので、できるだけ具体的にお話しさせていただきます。この質問は、技術的な質問よりも「組織的な」質問です。

これらの主なコンポーネントを持つマルチサイドプロジェクトがあります。

• コアビジネスロジック（データモデル）をホストするサーバー
• コアビジネスロジックを使用するクライアントのバックオフィス
• コアビジネスロジックも使用するアプリケーションAPI（REST）
• アプリケーションAPIを使用するスマートフォンアプリ（iOSおよびAndroid）があります。
• スマートフォンとは別のタブレットアプリ（android）があり、同じアプリAPIを使用しています。

すぐに、私はアクティブなクライアントで生産されます。そして、どんなプロジェクトでも、私はすべての異なるコンポーネントを長期にわたって維持する必要があります。つまり、以下のすべてをアップグレードできます。

• サーバーのコアビジネスロジックのコード（バックオフィス、API、および副作用としてモバイルアプリで使用）
• API自体（スマートフォンアプリとタブレットアプリの両方で使用）
• すべてのモバイルアプリ（appstore / googleplay経由）

もちろん、サーバー側の部分（コアビジネスロジックコードとAPIコード）は自分ですぐに変更できます。ただし、新しいモバイルアプリはappstore / googleplayでクライアントがダウンロードする必要があり、それらが最新であるかどうかはわかりません。

これらのアップグレードをスムーズに行い、クライアントにリスクを与えないようにするためのガイダンス、優れた実践のヒントを教えてください。

どのバージョンの「バージョン」を作成する必要がありますか？クライアントがモバイルアプリをアップグレードしなくても、すべてが確実に機能するようにするにはどうすればよいですか？私に仕事を楽にするために彼にアップグレードを強いるべきですか？

つまり、マルチサイドプロジェクトを長期にわたってライブにするには、どのように整理すればよいですか？

モバイルアプリを新しいリリースに更新するタイミングを制御できないため、少なくともREST APIをバージョン管理する必要があります。そうしないと、そのインターフェースに下位互換性のない変更を加えることができなくなります。

REST APIのほかに、ネットワークインターフェースを経由する他の通信インターフェースもバージョン管理することをお勧めします。このようにして、サーバーと同時にすべてのバックオフィスクライアントをアップグレードする必要がなくなり、「ベータテスト」期間の新しいバージョンへの段階的な移行を実装できます。

通信インターフェースのバージョン管理に加えて、可能な限り後方互換性のある変更を行うようにする必要もあります。理想的には、古いクライアントを完全にサポートする新しいインターフェイスバージョンをロールアウトして、変更されたことに気付かないようにすることができます。

この投稿はあなたの質問について興味深いポイントを作ります。

より実用的な方法で、3つのコンポーネントがある場合：

• 2消費者：フロントエンドとモバイルアプリ
• 1つのAPIプロバイダー：バックエンド

それぞれに典型的なMmp（Major.minor.patch）バージョン管理スキームを使用できますが、バックエンドURLには次のように指定できますhttp://youhost/M.m/resourceURI。

進化し、APIの変更がコンシューマとの契約に影響を与えないようM.mに、URL をそのまま維持します。バックエンドに変更を加えた瞬間から、コンシューマーに影響を与えます（動作の変更や異なるオブジェクトの変更など）はM.m+1、M+1.m+1またはを使用しますM+1.m。

ユーザーが新しいコンシューマーをインストールしている間に、新しいバックエンドを古いものと同時にデプロイして、古いAPIを徐々に停止することで、物事を継続して実行する方法です。

私よりもはるかに良い答えがここにあります： Stackoverflowでのバージョン管理REST API

継続的インテグレーションサーバーをインストールし、コードリポジトリとスナップショット/リリースリポジトリに接続して、ビルドを自動化することをお勧めします。これには多くの利点があります。

1. すべてのコンポーネントは、リリース時にバージョン管理されます。これには、低レベルのライブラリと最終製品が含まれます。
2. すべてのコードコミットは、スナップショットビルドをトリガーします。これは、ビルドを壊した犯人にメールを送信する機能を使用する場合は特に、開発者を正直に保つのに役立ちます。
3. すべてのビルドでユニットテストを実行できます。これにより、コードの品質が著しく向上します。
4. すべてのリリースにはタグが付けられるため、製品版の修正が必要な場合は、タグから分岐して修正を簡単に行うことができます。
5. 何らかの互換性レジスタを維持する必要があります。（たとえば、BackOffice 1.0.23はREST API 2.0.267などと互換性があります）。この分野で役立つツールを知りません。

私の経験は、オープンソースツール（SVN、Maven 2、Jenkins、Nexus）での経験ですが、これらすべての代替手段があります。

チームのスピードを上げるために、学習時間を過小評価しないでください。しかし、いったん速度が上がると、二度と戻ることはありません。

開発とデプロイメントの比較的小さなチームの場合、IBM Jazzで採用されているクライアントN-1互換モデルはかなりうまく機能する可能性があります

クライアントとサーバーを同じバージョン番号に保つようにしてください。[独立したバージョンとその互換性のマトリックスを管理する代わりに]

クライアントバージョンXyyがXyyより上でX + 2.0.0より前のすべてのサーバーバージョンで動作するようにポリシーを作成する

サーバーバージョン4.0の場合、理想的にはすべてのクライアントタイプにクライアントバージョン4.0が必要です。ただし、クライアントとサーバーのわずかに異なるバージョンを許可するように、互換性を維持する必要があります。

クライアントバージョン4.xは、サーバーバージョン4.x以上6.0未満のサーバーと互換性があるはずです。サーバー4.xは、バージョン3.0以上で4.x以下のすべてのクライアントと互換性がある必要があります。

このようにして、クライアントの新しいバージョンの即時リリースを心配することなく、サーバー上のバージョンを更新できますが、維持する互換性の明確に定義されたウィンドウしかありません。

参照：IBM Jazzモデル[ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

まず、問題を少し違った方法で組み立てることから始めましょう。「バージョン」を設定する必要があるソフトウェアを尋ねました。バージョンは、CSでの過負荷の用語であり、約100の異なることを意味する場合があります。私が見る主なものは次のとおりです。

1. バージョン管理-バージョン管理は、開発のスナップショットと履歴を追跡するのに役立つ構成管理ツールです。 すべてのコードは、バージョン管理下にある必要があります。binフォルダーに追加する便利なスクリプトだけだとしてもかまいません。作成に時間をかける価値のあるものはすべて、リビジョン管理ソフトウェアに2秒追加する価値があります。
2. 構成管理-ビルドの内容を制御するにはどうすればよいですか。すべてのソフトウェアには、ある程度の構成管理が必要です。バージョン管理は開発の履歴を追跡するためのツールにすぎないため、バージョン管理と構成管理の違いをマネージャーに説明したいのですが、構成管理は履歴を作成する方法、およびコードを決定する方法などのガイドラインですいいね。
3. ソフトウェアのバージョン管理-コードのリリースに名前を割り当てる。これは、「MineSweeper 7.1.29290149210」など、購入したものを見るのに慣れているため、多くの人が最初に問題を見つけたときにつかまっているものですが、正直なところ、これははるかに大きな問題の最も小さな部分です。正直に言うと、1によって生成されたハッシュを使用するだけで、人間が読めないことをそれほど気にしないでください。

だから、それは私にとって最も曖昧で最も興味深いものなので、2番目に焦点を当てます。構成管理に万能なCookieカッターソリューションはありません。2人または3人のチームでうまく機能するルールは、何百人もの労働者を必要とするプロジェクトで正気を保つにはあまりにも緩い場合があります。大きなチームで機能するルールは、小さなチームにとってあまりにも多くのオーバーヘッドを必要とする場合があります。ほとんどの場合、独自のものをまとめて何かをまとめる必要がありますが、構成管理システムの仕様を開発する方法として次のリストを使用します。

1. 市場でサポートしているバージョン（およびそれらに関連する問題）を追跡するにはどうすればよいですか？
2. プロダクションシステムにリリースする準備ができている開発パスをどのように決定しますか？（プロセスの他のステップの準備ができていることもあります）
3. 誰がシステムの構成を制御/管理する必要がありますか？他の開発者に配布するコードを追加するワークフローは何ですか？
4. 相互作用するパーツ間の相互作用をどのように制御しますか？部品を変更するとシステムの残りの部分が壊れるかどうかはどうすればわかりますか？
5. 時間の経過とともに、構成管理システムをどのように改善するか。

上記の質問に答えるのに助けが必要ですか？おそらくコンサルタントまたはソフトウェアエンジニアリングマネージャーを雇う必要があります...教科書を埋めることができ、このタイプのフォーラムの範囲外です。