Git with NAV
It’s been a veeeeery long time since my last post. I was so busy at work and had to deal with some personal issues (health) and didn’t bother about blogging that much…
Anyway lot’s of things happend, I gave up (at least for now) on the compare tool i was creating, it was soo time consuming and almost ate up all of my spare time, and since we got the Application Merge Utilities from Microsoft, the need for this is not that strong as it used to be.
But eventually i will use it (or parts of it) in other projects.
But for now the big topic is Git!! I’am not the first one blogging about it, git and source control in general (TFSVC for Example) was all over the place. And I for myself wanted to use a SCM (Source Control Management) for quite some time. So this year we finally had time to do so.
After lots of thinking and testing and analyzing of our workflows we decided to use Git as our source control system and Team Foundation Server for Project Management. The reason for this was mainly the complexity of NAV versions that inherit from each other (W1 -> Local -> Local ISV -> Customer Solution) We can separate these in Repositories while still maintaining their links through remotes.
For different Versions of ISV Solutions (NAV2009, NAV2013, NAV2013R2, NAV2015, …) we will be using different branches. This however might change, if anybody has another idea or can think of an issue with this, please tell me about it!
I could think of having these in separate repos too, but I’am not sure if this would be overkill.
For Interacting with NAV (Importing/Exporting source code, tracking changes, etc) I extended our tool that we use internally.
This tool is used to manage all NAV versions in use (similar to existing tools such as DynamicsNAV protocol handler) but advanced in its behavior and built with around a central sharepoint list of databases. Very cool tool that handles protocol requests, register com interface for flawless page opening (not opening second client) and many other things to ensure a true multi-client handling.
The management tool was extended around the git idea, added with some simple git tasks like commit, pull, push, and some basic TFS tasks like adding workitems to commits, setting the state of them at commit, a workitem-query browser, object tracking based on sql triggers on the object-table, import/export trough NAV’s hidden COM Interface…
Lots of things going on to make the life of our developers easy.
We still need Visual Studio & git bash for certain tasks, but everyday NAV developer business is easy to manage.
Up to this point I’am very happy we took the time and switched to git/TFS for development, and I hope more people will follow and eventually some day even the NAV team will support this out of the box 😉
deV.ch - man vs. code 
Hey devhc,
Could please write more about your experience integrating git withing NAV development processes? How does it look. Do you use branches or just central branch.
I’m trying to use git with NAV as well? I don’t have automated import/export as you describe in the article but just run powershell scripts manually. Would you mind to share your code for object import/export?
We are still in the process of working some things out. Currently we use just one central branch where everyone works on. We would like to change this to a more “gitish” workflow.
It takes time and experience to find the best branching methods etc. And I think it is better to introduce these topics in portions. It was a huge change for the dev team to switch to git. Since essentially nobody knew much about using a source control managament system (including me).
Currently the plan is to use these Branches:
With the option to use feature branches for large long running development tasks. This may only take place locally (using powershell scripts to create backup-restore NAV-DB localy and install a NST for them)
Unfortunately I cannot share the code for the tool, we may commercially sell the tool to the public in the future. But I could write a blog post about how it works in theory.
In Short: It’s a .net application that used to manage all our customer versions (from NAV2.0 up to 2016), i extended it to track changes in NAV Database and automaticly export .txt files to the local git repo. I created a Sync Process to detect changes in both the db and the local repo and supply the user some sort of “Import Worksheet” as when you would import a fob file.
There was much more involved such as blocking changes in the db for non-git users to avoid untracked changes etc.
I have also “created” a git-merge driver for using the Merge-NAVApplication cmdlet in the git merge process. This helps auto-resolving git conflicts.
To speed up the update process of our customer implementations i create clones of our ISV repo before customer implenetation starts. Therefore we can just “Pull” the newest changes from the ISV Repo and mostly auto-merge them to the customer. This is an awesome feature! Once set up correctly it saves a lot of time and you can be sure nothing is missing.
Hey devch,
Thanks for the explanation. If you are planning to sell your product later on, please contact me as well.
I got few more questions:
Do you do anything special in case of field renaming? I found that the best approach is to export all objects. Then you can catch all these small codes changes in related objects. But export function is not as fast as we would like it to be 🙂 Perhaps you know the smarter way to track these changes caused by field renaming?
Why would you create git-merge driver? We are using standard git merge toolkit and we are pretty happy with it. If there’s merge conflict, usually its very minor conflict related to the date/time/version.
Regarding customer implementations we have it our agenda as well. At the moment we are just merging upstream(MS & LS Retail hotfixes) changes to our develop branch once a month. We are planning to start working with customers branches once they migrate to NAV 2016.
Best Regards,
Gintautas