使用Git版本Microsoft Dynamics NAV？

Question

我是.NET开发人员，但在我们的组织中，我们还有几个Microsoft Dynamics NAV开发人员。 目前他们没有使用任何源代码控制。 我对NAV知之甚少，但据我了解，你可以编写NAV中的对象并从脚本中导入。

既然如此，是否有人使用GIT与NAV？ 你有没遇到任何陷阱？ 我想知道这是否是一个很好的解决方案，建议他们，以及管理是否比使用Git with .NET（我发现相当容易）更复杂。

Answer 1

是的，我们正在使用Git和Dynamics NAV取得巨大成功！

不好的是，在Git赋予意义之前，必须将所有对象导出到txt。 让我们希望微软能够创建一种更简单的方法来将对象导出到txt。 我们正在使用这个模型。 使用通用主服务器创建Git存储库，并为我们更改的每个对象创建一个分支。 所有源文件必须与分支顶级文件具有相同的名称，才能使Git跟踪差异。 以这种方式使用Git，我们永远不会将任何东西合并到master中。 在开始使用Git之后，更容易处理共享对象并跟踪其他NSC对代码所做的事情。 IT-Revision很高兴，因为所有代码都有详细记录，并且任何后备的方式都更容易。 我将全力支持使用Git和Dynamics NAV。

石油与能源行业的Navision顾问

Answer 2

我正在使用Dynamics NAV和Git，但不是在同一时间。 让我解释一下原因。

Git本身很酷（ GitHub变得更好），但是Windows端口很差，除非你不喜欢坚持使用类似unix的命令行，因为它是建议使用msysGit的方法 。 不幸的是，Windows上的GUI工具并不好。

对我来说很难让老板理解，为什么使用分布式版本控制比通常的TFS更好。 对于面向业务的人来说，一个大的中央存储库感觉更安全（因为它是我自己支付的服务器，我控制访问权限）和更强大（我雇用了一个将运行维护程序的系统管理员）。

我决定不反对这种意志。 我们使用分布式版本控制作为临时区域。 所有不稳定的更改都存储在此区域中，我们会在团队中进行测试。 完成稳定后，对象将合并到中央存储库中。 每个人都很开心。

关于Git：最近我切换到另一个分布式版本控件 - 化石由于以下原因：

• 它可以做Git所能做的一切;
• 它在Windows上的外观，感觉和行为;
• 它有一个Web界面内置，我可以轻松地将其作为本机Windows服务运行;
• 它集成了问题跟踪功能，因此我不再需要第三方工具;
• 存储库是一个单独的文件，因此我可以随身携带在我想要的任何地方的笔式驱动器上;

关于我们的NAV解决方案。 它超过1000个对象，大小超过20 MB。

编辑：经过半年多的编码后的一些更新。

我们换回了git。 由于它的自动合并是真棒 。 为了赢得赌注，我已经在4小时内将解决方案（修改过的标准对象和新标准对象）从NAV7CTP3移动到NAV7CTP5。 虽然由四名开发人员组成的团队取得了相同的成果，但需要将近三周的日常工作。

Git真的有所作为。 我相信其他分布式版本控制系统可以获得相同的结果。

原因是：Git和其他分布式系统在提交期间比TFS和SVN节省了更多信息。 在常规开发过程中并不是那么重要，但是当涉及到合并时，来自Git的所有这些“冗余”信息都会产生影响。

在合并期间，Git找到启动分支的通用修订版，然后逐步应用来自两个分支的更改 - 与开发人员更改代码的方式 - 应用于解决方案中的所有文件。

如果在两个分支中更改了相同的行，则表明存在冲突。 如果不是，它只是将文件保存到准备提交的工作文件夹中。

这里有一些统计：

• 在CTP3和CTP3代码库中处理的文件总数大约是四千个;
• 合并的解决方案对象的总数是1170;
• 冲突文件总数为140;
• 成功自动合并的比率约为88％（1170-140）/ 1170 * 100 = 88％;
• 大多数冲突都是对象版本的变化 - 微不足道;
• 大约20个文件中的重要冲突;
• 对所有合并对象进行了简单的查找和替换（修复RunFormOnRec - > RunPageOnRec等）;
• 结果是一组完全可导入的基于CTP5的最新解决方案对象;
• 导入后的编译错误数约为50;
• 大多数这些错误与从CTP3到CTP5完成的标准对象的变化有关;
• 断层物的发生率约为4％（50/1170 * 100％= 4％）;

Answer 3

我们正在使用带有Dynamics NAV的git并取得了巨大的成功。

但我不得不说，这并不容易。 Dynamics NAV（我们使用的是2013版）未针对git或基于文件的开发进行优化。 开发通常直接在开发环境（经典客户端）中完成，该环境将源代码直接保存到数据库中。

所以我们为git提供的支持是：我们构建了许多有用的PowerShell命令，帮助开发人员将NAV数据库与本地git文件夹同步。 我们有一个命令可以将带有修改标志的所有对象导出到本地git文件夹中 - 或者是一个导入git提交之间所有对象的命令。 我们甚至使用它来自动更新我们的测试数据库，在开发机器上使用git push 。

但这就是说：开发所有这些程序并构建脚本并不容易。

所以我建议你三思而后行使用git和Dynamics NAV的决定。 该软件不适用于git，所以你必须做很多工作 - 问题是你的老板是否愿意给你时间来建立必要的工具来顺利工作。

另请参阅对象管理器高级版 。 这是我们以前使用过的工具。 我曾经看过idyn （公司）的预览，他们用visual studio取代了经典的开发环境客户端！ 我们从Object Manager Advanced切换到git作为主要开发工具，因为它不适合我们的业务案例。 但是我们仍在使用fe for Where Used功能女巫很棒！ （电影来自旧的资产净值版本，对不起）

Answer 4

我一直在使用Git和Navision 2009（及更早版本），这非常值得。

由于没有本机Git支持，我将ID号区域中的Navision代码导出到一个大文本文件中。 （选择.txt格式进行导出）。 或者在我按日期更改的所有模块上设置分隔并导出。

我写了一个Python脚本，它接受这个文本文件，并将它分成每个Object（Form，Table，Codeunit）的单个文件，就像你手动保存所有内容一样。 它将它们保存到我在Git控制下的网络文件夹中。

虽然花了几天时间让这个过程完全运行，但现在整个过程每次更新只需要几分钟。 唯一的缺点是Navision本身不会导出谁做了更改，因此Git不会反映出这一点。

仍然很好，我可以完全控制我们的Navision源代码中的变化。 此外，如果您在一个记录不完整的Navision环境中工作，那么您可以搜索一个表单中的完整代码，这是一个巨大的计时器保护程序。 除了搜索代码库以查找错误消息文本之外，另一个优点是您可以编写脚本，该脚本将告诉您允许修改特定表的代码。 因此，如果您重构一个表，您将立即知道需要检查哪些代码...

对于Git本身，我使用了一些基本的命令行命令。 为了检查更改，我使用了当前Git版本支持的visual P4MERGE工具。