6

私は .NET 開発者ですが、私たちの組織には Microsoft Dynamics NAV の開発者も何人かいます。現在、彼らはソース管理を使用していません。私は NAV についてほとんど知りませんが、NAV からオブジェクトをスクリプト化し、スクリプトからインポートし直すことができることは理解しています。

では、NAV で Git を使用している人はいますか? 途中で困ったことはありませんか？これが彼らに提案する良い解決策であるかどうか、また、.NET で Git を使用するよりも管理が複雑ではないかどうか疑問に思っています (これはかなり簡単だと思います)。

4

4 に答える 4

5

はい、Git を Dynamics NAV と一緒に使用して大成功を収めています!

悪い点は、Git が意味を与える前に、すべてのオブジェクトを txt にエクスポートする必要があることです。Microsoft が、オブジェクトを txt にエクスポートするためのより簡単なアプローチを作成することを期待しましょう。このモデルを使用しています。一般的なマスターを使用して Git リポジトリを作成し、変更する各オブジェクトのブランチを作成します。Git が違いを追跡できるようにするには、すべてのソース ファイルがブランチ トップ ファイルと同じ名前である必要があります。このように Git を使用すると、何も master にマージすることはありません。Git の使用を開始した後は、共有オブジェクトで作業し、他の NSC がコードで行ったことを追跡することがはるかに簡単になります。また、IT-Revision は満足しています。すべてのコードが適切に文書化されており、フォールバックへの道がはるかに簡単だからです。Dynamics NAV で Git を使用することを全面的に支持します。

Navision コンサルタント、石油およびエネルギー産業

于 2011-09-17T14:39:25.670 に答える
4

Dynamics NAVとGitを使用していますが、同時には使用していません。その理由を説明させてください。

Git自体はかっこいいですが（GitHubを使用するとさらに良くなります）、UNIXのようなコマンドラインに固執したくない場合を除いて、Windowsポートは貧弱です。これはmsysGitをセットアップするための推奨される方法だからです。残念ながら、WindowsのGUIツールは良くありません。

私にとって、上司に理解させるのは困難でした。分散バージョン管理を使用する方が通常のTFSよりも優れている理由です。ビジネス志向の人にとって、1つの大きな中央リポジトリはより安全で（私が支払う自分のサーバーであるため、アクセスを制御します）、より堅牢です（メンテナンス手順を実行するシステム管理者を雇いました）。

私はこの意志と戦わないことに決めました。ステージング領域として分散バージョン管理を使用しています。不安定な変更はすべてこの領域に保存され、チーム内でテストを行います。安定化が完了すると、オブジェクトは中央リポジトリにマージされます。みんな幸せそうです。

Gitについて：最近、次の理由により、別の分散バージョン管理に切り替えました—化石。

  • Gitができることはすべて実行できます。
  • 見た目、感触、動作はWindowsでネイティブです。
  • Webインターフェイスが組み込まれており、ネイティブのWindowsサービスとして簡単に実行できます。
  • 問題追跡が統合されているので、サードパーティのツールはもう必要ありません。
  • リポジトリは単一のファイルなので、どこにでもペンドライブに入れて持ち運ぶことができます。

NAVソリューションについて。1000を超えるオブジェクト、サイズは20MBを超えます。

編集：コーディングの半年以上後のいくつかの更新。

gitに切り替えました。その自動マージは素晴らしいので。賭けに勝つために、私は4時間でソリューション（変更された標準オブジェクトと新しいオブジェクト）をNAV7CTP3からNAV7CTP5に移動しました。4人の開発者のチームが同じ結果を達成しましたが、ほぼ3週間の日常作業が必要でした。

Gitは本当に違いを生みます。他の分散バージョン管理システムでも同じ結果が得られると思います。

その理由は次のとおりです。Gitやその他の分散システムは、コミット中にTFSやSVNよりもはるかに多くの情報を保存します。通常の開発ではそれほど重要ではありませんが、マージに関しては、Gitからのこの「冗長な」情報すべてが違いを生みます。

マージ中に、Gitはブランチを開始した共通のリビジョンを見つけ、開発者がコードを変更したのと同じ方法で、両方のブランチからの変更をソリューション内のすべてのファイルに段階的に適用します。

両方のブランチで同じ行が変更された場合は、競合が表示されます。そうでない場合は、ファイルを作業フォルダーに保存して、コミットできるようにします。

ここにいくつかの統計があります：

  • CTP3とCTP3の両方のコードベースで処理されるファイルの総数はそれぞれ約4000です。
  • マージされたソリューションのオブジェクトの総数は1170です。
  • 競合するファイルの総数は140です。
  • 自動マージの成功率は約88％（1170 – 140）/ 1170 * 100 = 88％です。
  • ほとんどの競合は、オブジェクトのバージョンの変更です—些細なことです。
  • なし-約20個のファイルでの些細な競合。
  • マージされたすべてのオブジェクトで簡単な検索と置換が行われました（RunFormOnRec-> RunPageOnRecなどを修正するため）。
  • その結果、CTP5に基づく最新のソリューションオブジェクトの完全にインポート可能なセットが作成されます。
  • インポート後のコンパイルエラーの数は約50です。
  • これらのエラーのほとんどは、CTP3からCTP5に行われた標準オブジェクトの変更に関連しています。
  • 障害のあるオブジェクトの割合は約4％（50/1170 * 100％= 4％）です。
于 2011-11-23T15:15:54.583 に答える
1

Dynamics NAV で git を使用して大きな成功を収めています。

しかし、それは簡単ではなかったと言わざるを得ません。Dynamics NAV (バージョン 2013 を使用) は、git またはファイル ベースの開発用に最適化されていません。開発は通常、ソース コードをデータベースに直接保存する開発環境 (クラシック クライアント) で直接行われます。

git をサポートするために私たちが行ったことは、開発者が NAV DB をローカルの git フォルダーと同期するのに役立つ、多くの便利な PowerShell コマンドを作成することです。変更されたフラグを持つすべてのオブジェクトをローカルの git フォルダーにエクスポートするコマンド、または git コミットの間ですべてのオブジェクトをインポートするコマンドがあります。git pushこれを使用して、開発マシンでテスト データベースを自動的に更新します。

しかし、これはつまり、これらすべての手順を開発してスクリプトを作成するのは容易ではなかったということです。

そのため、Dynamics NAV で git を使用するという決定についてよく考えることをお勧めします。ソフトウェアは git で動作するように構築されていないため、多くの作業を行う必要があります。問題は、スムーズに動作するために必要なツールを構築する時間を上司が喜んで与えるかどうかです。

Object Manager Advancedもご覧ください。以前使用していたツールです。idyn (Company)のプレビューで、従来の開発環境クライアントを Visual Studio に置き換えたのを見たことがあります。私たちのビジネスケースに合わなかったため、Object Manager Advanced から git にメインの開発ツールとして切り替えました。しかし、 Where Used関数のためにまだ使用しています。（動画は古いNAV版のものです、すみません）

于 2016-12-02T19:19:52.160 に答える