使用Git版本Microsoft Dynamics NAV？

Question

I'm a .NET developer, but in our organization we also have a couple of Microsoft Dynamics NAV developers. Currently they're not using any source control. I know very little about NAV, but as I understand it, you can script out objects from NAV and import back in from the scripts.

That being the case, is anyone using Git with NAV? Have you run into any gotchas along the way? I'm wondering if this is a good solution to suggest to them, and whether it's any more complicated to manage than using Git with .NET (which I've found reasonably easy).

Answer 1

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

Answer 2

I'm using Dynamics NAV and Git, however not at the same time. Let me explain why.

The Git itself is cool (with GitHub it gets even better), but the Windows port is poor, unless you don't like to stick to unix-like command line, since it's the recommended way to setup msysGit . The GUI tools on Windows are no good, unfortunately.

For me it was hard to make my boss understand, why using distributed version control is better than the usual TFS. For business-oriented guys one big central repository feels more secure (because it's my own server I pay for, I control access to) and more robust (I hired a system administrator who will run maintenance procedures).

I decided not to fight against this will. We're using distributed version control as a staging area. All unstable changes are stored in this area and we do testing within our team. After finishing stabilization, objects are merged into the central repository. Everybody looks happy.

Regarding Git: Recently I switched to another distributed version control — fossil due to following reasons:

• It can do everything that Git can;
• It looks, feels and acts native on Windows;
• It has a web-interface build-in and I can easily make it run as a native Windows service;
• It has integrated issue-tracking, so I don't need third-party tools any more;
• The Repository is a single file, so I can take it with me on a pen drive everywhere I want;

Regarding our NAV solution. It's more than 1000 objects, size over 20 MB.

EDIT: Some updates after more than half year of coding.

We switched back to git. Since its automatic merge is AWESOME . Just to win the bet I've moved a solution (modified standard objects and new ones) from NAV7CTP3 to NAV7CTP5 in 4 hours. While a team of four developers achieved the same result needing almost three weeks of everyday work.

Git really makes a difference. I believe the same results are possible with other distributed version control systems.

The reason is: Git and other distributed systems save a lot more information during a commit than ie TFS and SVN. It is not so important during regular development, but when it comes to merging, all this 'redundant' information from Git makes the difference.

During the merge Git finds the common revision which started a branch and then applies changes from both branches step by step - in the same way as the developer changed the code - to all files in solution.

If the same line was changed in both branches it shows the conflict. If not it just saves the files into the working folder ready for commit.

Here some statistics:

• The Total number of files processed in both CTP3 and CTP3 codebases is around four thousand each;
• The Total number of the solution's objects merged is 1170;
• The Total number of conflicting files is 140;
• The rate of successful automatic merge is about 88% (1170 – 140) / 1170 * 100 = 88%;
• Most conflicts are changes in the object's versions — trivial;
• None-trivial conflicts in about 20 files;
• Trivial find and replace was done on all merged objects (to fix RunFormOnRec -> RunPageOnRec, etc.);
• The result is a fully importable set of the most recent solution objects based on CTP5;
• The Number of compile errors after import is about 50;
• Most of these errors relate to changes in standard objects done from CTP3 to CTP5;
• The rate of faulting objects is around 4% (50 / 1170 * 100% = 4%);

Answer 3

We are using git with Dynamics NAV with great success.

But I have to say, it was not easy. Dynamics NAV (we use version 2013) is not optimized for git or file-based development. The developing is usually done directly in the development environment (classic client) that saves the source code directly into the database.

So what we did to support git is: We build a lot of useful PowerShell commands that are helping developers to synchronize a NAV DB with a local git folder. Fe we have a command that exports all objects with a modified flag into the local git folder - or a command that imports all objects between to git commits. We even use that to automatically update our test database with a git push on the development machine.

But that's to saying: It wasn't easy to develop all these procedures and build scripts.

So I would recommend you to think twice about the decision of using git with Dynamics NAV. The software is not build to work with git, so you will have to do a lot of work - and the question is if your boss is willing to give you the time to build the necessary tools to work smoothly.

Take a look also at Object Manager Advanced . That is a tool that we used before. I saw once a preview from idyn (Company) where they replaced the classic development environment client with visual studio! We switched from Object Manager Advanced to git as main development tool because it was not fitting for our business cases. But we are still using it fe for the Where Used function witch is great! (Movie is from an old NAV version, sorry)

Answer 4

I've been using Git and and Navision 2009 (and older) for a long time and it's so worth it.

As there's no native Git support, I export Navision code in the ID Number area that we're allowed to program in into a big text file. (select .txt format for export). Or set a delimitation on all the modules I changed by date and export this.

I wrote a Python script that takes this text file and splits it into a single file per Object (Form, Table, Codeunit), just like if you would save everything manually. It saves them to a network folder I have under Git control.

While it took a few days to get the process working fully, now the whole process only takes a few minutes per update. The only disadvantage of this is that Navision itself doesn't export who did changes, so the Git will not reflect that.

Still it's great that I can control what has been changing in our Navision source code fully. Also, if you are working in a poorly documented Navision environment, having the complete code in a form, that you can search, is a huge timer saver. Apart from grepping the codebase to locate error message texts, another advantage is that you can then write a script, that will tell you what code is allowed to modify a specific table. So that if you refactor a table, you will instantly know what code needs checking...

For Git itself, I use a few basic command line commands. To examine changes, I use the visual P4MERGE tool that is natively supported by current Git version.