6

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

既然如此，有人在使用带有 NAV 的 Git 吗？您在此过程中遇到任何问题吗？我想知道这是否是向他们建议的一个好的解决方案，以及管理它是否比使用带有 .NET 的 Git 更复杂（我发现这相当容易）。

4

4 回答 4

5

Yes we are using Git together with Dynamics NAV with great success!

The bad thing is that all objects must be exported to txt before Git gives meaning. Let's hope that Microsoft will create an easier approach to exporting objects to txt. We are using this model. Create a Git repository with a general master, and a branch for each object we change. All source files must have the same name as the branch top file to make Git track differences. Using Git in this way, we never merge anything into master. After starting using Git it's much easier to work on shared objects and track what other NSC's have done with the code. And IT-Revision is happy because all code is well documented and the way to any fallback is much easier. I'll give my full endorsement to use Git with Dynamics NAV.

Navision Consultant, in Oil & Energy Industry

于 2011-09-17T14:39:25.670 回答
4

我正在使用 Dynamics NAV 和 Git，但不是同时使用。让我解释一下为什么。

Git 本身很酷（使用GitHub会更好），但 Windows 端口很差，除非您不喜欢坚持使用类似 unix 的命令行，因为这是设置msysGit的推荐方法。不幸的是，Windows 上的 GUI 工具并不好。

对我来说，很难让我的老板理解，为什么使用分布式版本控制比通常的 TFS 更好。对于面向业务的人来说，一个大型中央存储库感觉更安全（因为这是我自己付费购买的服务器，我可以控制访问）并且更健壮（我聘请了一名系统管理员来运行维护程序）。

我决定不与这个意志抗争。我们使用分布式版本控制作为暂存区。所有不稳定的更改都存储在该区域中，我们在团队内部进行测试。完成稳定后，对象将合并到中央存储库中。每个人看起来都很开心。

关于Git：最近我切换到另一个分布式版本控制——fossil，原因如下：

  • 它可以做 Git 能做的一切；
  • 它在 Windows 上的外观、感觉和行为都是原生的；
  • 它有一个内置的网络界面，我可以很容易地让它作为原生 Windows 服务运行；
  • 它集成了问题跟踪，因此我不再需要第三方工具；
  • Repository 是一个单一的文件，所以我可以随身携带它到随身携带的笔式驱动器上；

关于我们的资产净值解决方案。它有 1000 多个对象，大小超过 20 MB。

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

我们切换回 git。因为它的自动合并是AWESOME。为了赢得赌注，我在 4 小时内将解决方案（修改后的标准对象和新对象）从 NAV7CTP3 移至 NAV7CTP5。而一个由四名开发人员组成的团队需要近三周的日常工作才能获得相同的结果。

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

我们使用 git 和 Dynamics NAV 取得了巨大成功。

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

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

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

因此，我建议您在决定将 git 与 Dynamics NAV 一起使用时三思而后行。该软件不是为与 git 一起工作而构建的，因此您将不得不做很多工作 - 问题是您的老板是否愿意给您时间来构建必要的工具以顺利工作。

还请查看高级对象管理器。那是我们以前使用的工具。我曾经看过 idyn（公司）的预览，他们用 Visual Studio 替换了经典的开发环境客户端！我们从高级对象管理器切换到 git 作为主要开发工具，因为它不适合我们的业务案例。但是我们仍然将它用于Where Used功能，女巫很棒！（电影来自旧的 NAV 版本，抱歉）

于 2016-12-02T19:19:52.160 回答
0

我已经使用 Git 和 Navision 2009（及更早版本）很长时间了，非常值得。

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

我编写了一个Python脚本，该脚本获取该文本文件并将其拆分为每个对象（表单、表格、代码单元）的单个文件，就像您手动保存所有内容一样。它将它们保存到我在 Git 控制下的网络文件夹中。

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

仍然很高兴我可以完全控制 Navision 源代码中发生的变化。此外，如果您在记录不充分的 Navision 环境中工作，那么将完整的代码保存在一个可以搜索的表单中，可以节省大量时间。除了 grepping 代码库来定位错误消息文本之外，另一个优点是您可以编写一个脚本，它会告诉您允许哪些代码修改特定表。因此，如果您重构一个表，您将立即知道需要检查哪些代码......

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

于 2018-09-30T12:41:58.663 回答