ボード上に多くのネットワークデバイスがあるデバイスのソフトウェアバージョン管理の編成のバリエーション

バージョン管理システムでリポジトリを整理することについて、いくつかのアイデアを共有したいと思います。 明確にするために：水星を使用しますが、これはそれほど重要ではありません。



タスクについて簡単に説明します。 同時に、いくつかのプロジェクトが進行中です。 プロジェクトは、ネットワークに接続されたボード上のデジタルデバイス（多数のデバイス）を備えたデバイスです。 これは、バージョン管理システムを使用して追跡する必要があるオンボードデバイスソフトウェアに関するものです。



さまざまなデバイスで同じオンボードデバイスがありますが、特定のデバイスがあります。 デバイスはさまざまな開発者がプロ​​グラムでき、一部のデバイスは請負業者がプログラムします。 オンボードデバイスのプロセッサ（コントローラ）のブランドは異なります。 異なるデバイスは同じライブラリを使用できます：ドライバー、数学など。



開発者は出張（試用）に多くの時間を費やします。そこでは、コードを変更し、インターネットで更新を交換する必要があります。



現在、そのような作業がバージョン管理システムなしで実行されたことは驚くべきことです。 おそらく、これは、それほど多くのプロジェクトがなく、開発者が2人しかいなかったために可能でした。 しかし、物事はもはやこのように進むことができません。



バージョン管理の概念を形成し、この概念に沿ってプロジェクトをリファクタリングし始めています。 私たちは旅の始まりにいますが、私たちは見つけた解決策が好きですが、おそらくすべての落とし穴が見当たらないため、将来的には支払うことができます。 読者の推奨が、エラーを修正するのに役立つことを願っています。





それで、まさに制御の概念について。 分散バージョン管理システムを使用することは基本です（上記の頻繁で長時間の出張を参照してください）。 いくつかの理由で、選択は水星に落ちましたが、Geetはおそらく降りてきたでしょう。



リポジトリは1つではなく、それら全体（ツリー、構造）で使用されます。 リポジトリは相互接続され、特定の順序でフォルダに配布されます。 さらに、このようなストレージのセットをリポジトリツリーと呼びます。



1つのストレージツリーがサーバーでホストされます。 彼のクローンは地元のPC開発者にあります。 開発者は、ローカルツリーまたはその個々のブランチを必要に応じて複製します。



ストレージツリーテンプレートは次のとおりです。

Repositories | +–.CrossplatformLib1 | +–.CrossplatformLib2 | +–... | +–Platform1 | | | +–.Platform1Lib1 | | | +–.Platform1Lib2 | | | +–... | +–Platform2 | | | +–.Platform2Lib1 | | | +–.Platform2Lib2 | | | +–... | +–... | +–Devices | | | +–.Device1 | | | +–.Device2 | | | +–... | +–Vehicles | +–Vehicle1 | +–Vehicle2 | +–...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前の先頭にあるドットは、リポジトリを示します（例：.Device1）。 ドットのない名前は、デバイスなどの通常のフォルダーです。



ツリーのルート（Repositoriesフォルダーのルート）には、クロスプラットフォームライブラリ（数学、アルゴリズムなど）を含む.CrossplatformLibXリポジトリがあります。



PlatformXフォルダーは同じレベルにあり、PlatformXプラットフォーム固有のライブラリーを含む.PlatformXLibYリポジトリーがあります。 たとえば、Windowsのネットワークドライバー。



最上位の[デバイス]フォルダーには、さまざまなデバイスで使用できるオンボードデバイス用の.DeviceXソフトウェアのリポジトリがあります。



最後の最上位フォルダーはVehiclesです。 さまざまなVehicleXデバイスのプロジェクトが含まれています。



また、特定のVehicleXデバイスのプロジェクトは、リポジトリまたはリポジトリのセットにすることができます。 これはそれほど重要ではないので、後で詳しく説明します。





考慮された構造は、相互のストレージの場所を示しています。 次に、ストレージ自体の配置方法を見てみましょう。



ストレージメカニズムは実質的に使用されます（私が理解しているように、最新のバージョン管理システムにはすべてこのような機会があります）。



たとえば、いくつかのDevices \ .DeviceXデバイスを考えます。 デバイスXがクロスプラットフォームライブラリYとプラットフォームZ専用のライブラリを使用するとします。次に、Devices \ .DeviceXフォルダーのレベルで、.CrossplatformLibYとPlatformZ \ .PlatformZLibNのストレージクローンが作成されます。

 Repositories | +–Devices | +–.DeviceX | +–.CrossplatformLibY | +–.PlatformZLibN | +–DeviceXSpecificFolder1 | +–...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.CrossplatformLibYおよび.PlatformZLibNリポジトリと共に、フォルダーには、DeviceXSpecificFolderMなどのフォルダー内のデバイスX固有のソースコードファイルが含まれます。



相対パスはコンパイラ設定ファイルで使用され、これらのファイル自体はバージョン管理システムによって追跡されます。 .DeviceXプロジェクトを別のコンピューターに転送する必要がある場合、たとえば、ラップトップにコピーして出張で持ち歩く場合は、.DeviceXフォルダーのみをコピーするだけで十分です。コンパイルに必要なすべての情報が含まれています。 コピーされた.DeviceXフォルダーへのパスを変更しないでおく必要はまったくありません。





次に、多くのネットワークデバイス.DeviceYを含むVehicleXのプロジェクトに戻ります。 最も単純なケースでは、すべてのオンボードデバイスがネットワーク内のスレーブサブスクライバーであり、そのうちの1つがマスターです。 それをマスターと呼びましょう。 主要なサブスクライバーはシステム統合の中心です。彼はすべてのメッセージのフォーマットを知っており、リクエストを送信し、回答を受け取ります。対応する.VehicleXストレージは次の構造を持つことができます。

 Repositories | +–Vehicles | +–.VehicleX | +–.DeviceY | +–.DeviceZ | +–DeviceM | +–... | +–Master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネットワークデバイスは、ユニバーサル（異なるデバイスで使用）または特定のいずれかです。 最初の場合、対応するストア（.DeviceYとする）は、Devices \ .DeviceYストアのクローンです。 2番目のケースでは、デバイスプロジェクトを個別のリポジトリ（.DeviceZ）として制御したり、.VehicleXストレージの個別のサブフォルダーとして編成したりできます（たとえば、これは.VehicleX \ DeviceMです）。 ストレージを備えたバリアントは、プロジェクトから（クローニングによって）分離しやすいという点で、より便利です。



問題は。 ユニバーサルデバイス.DeviceYのすべてのソースを.VehicleXストレージに保存する必要がありますか？ 実際、主要なマスターサブスクライバーを開発するには、ユニバーサルデバイスのインターフェイス（最も単純な場合はメッセージの形式）を知るだけで十分です。 これらの形式は一般に安定しており、ほとんど変更されません。 同時に、デバイスの実装は定期的に変更されます。少なくとも開発の初期段階では、インターフェースよりもはるかに頻繁に変更されます。



.VehicleXプロジェクトと.DeviceYプロジェクトを強力に接続するのはなぜですか？ ネットワークデバイスの実装の内部詳細を変更するときに、システムインテグレーター（マスター開発者）がこれらのプロジェクトを理解して同期する必要があるのはなぜですか？



デバイスプロジェクト全体ではなく、インターフェイスのみを同期すると、上記の問題は解決されます。 インターフェイスを追跡するための1つのオプションは、これかもしれません。 別のリポジトリ.Interfaceでデバイスインターフェイスファイル.DeviceYを選択します。

 Repositories | +–Devices | +–.DeviceY | +–.Interface | | + +- device_y.h | +–Source | +–...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.Interfaceリポジトリは、単一のdevice_y.hヘッダーファイルで構成されることがよくあります。



これで、.VehicleXデバイスのリポジトリで、.DeviceYプロジェクト全体ではなく、その.DeviceY \ .Interfaceインターフェイスのみを追跡できます。 そのクローンは、リポジトリ.VehicleX \ Devices \ .DeviceYに配置できます。

 Repositories | +–Vehicles | +–.VehicleX | +–Devices | | + +-.DeviceY | | + +-... | +–... | +–Master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.VehicleX \ Devicesフォルダーには、他のネットワークデバイスのインターフェイスを配置できます。 ネットワークデバイス.VehicleX \ Devices \ .DeviceYのインターフェイスの各ストアへのパスをマスターコンパイラの設定に指定しないようにするには、.VehicleX \ Devicesフォルダーに#includeを使用してdevice_y.hファイルを配置できます。 その後、マスターコンパイラの場合、パス.. \ Devicesのみを登録するだけで十分です。



請負業者がネットワークデバイスを開発している場合、インターフェイスを使用して考慮される手法は特に便利です。 この場合、デバイスのソースコードは利用できない可能性がありますが、たとえば、技術的なタスクの形成段階で、インターフェイスファイルは一貫している必要があります。



それはすべて一般的な用語です。 ただし、すべての質問がここに記載されているわけではありません。 たとえば、実行可能ファイル（バイナリ）のバージョンを制御する方法はまだ決定していません。 ストレージが膨張しないように、バージョンシステムの制御下に置くことは本当に望ましくありません。 そして、各プロジェクトが多くの実行可能ファイルで構成されていることを考慮すると、「dllの悪夢」が予想されます。