web-dev-qa-db-ja.com

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

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

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

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

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

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

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

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

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

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

designarchitectureproject-managementdeploymentrelease-management
14
David D.

モバイルアプリを新しいリリースに更新するタイミングを制御できないため、少なくともREST APIをバージョンアップする必要があります。そうしないと、後方に作成することは不可能になります-そのインターフェースに対する互換性のない変更。

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

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

9
Bart van Ingen Schenau

この post は、あなたの質問について興味深い点を示しています。

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

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

それぞれに典型的なM.m.p（Major.minor.patch）バージョン管理スキームを使用できますが、バックエンドURLにhttp://youhost/M.m/resourceURIと置くことができます。

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

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

あなたは私よりもはるかに良い答えをここで見ることができます： Versioning REST Stackoverflow上のAPI

4
mimsugara

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

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

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

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

2
kiwiron

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

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

クライアントバージョンX.y.yがX.y.yより上で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] =

2
profaisal

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

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

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

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

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

1
IdeaHat