How to develop Microsoft Dynamics NAV 2009 using Git
Hi there!
It’s 10 years from NAV 2009 was delivered, but we still use this solution in making business better and we still have topics to talk about:)
How do we solve a problem with parallel development NAV 2009? Someone develop code in one database then test code in another one, someone develops in different databases but then each developer merge their code with other pieces of code. Some of us assigned all merge work to one of the developers. Some of us moved further and use third-party solutions to manage development, but the real problem still exists: we use our databases as a place to store code and code changes and we do not use tools which are aimed at this particular goal: keep code changes like Git, SVN and etc.
The reasons, in my opinion, are we don’t have a widespread approach on how to solve the problem, the NAV world has developed apart of developing a dev-tools world.
When I asked my colleagues, why don’t we use Git as the version control system, they answered me: 1. Why is it better; 2. NAV 2009 is not integrated with Git. So the first question is an issue to discuss (it could be hard to break the ice between common process understanding and readiness to change), but for the second I can an answer.
When we talk about “integrating NAV 2009 with Git” we really talk about a tool which will take code from a database and put it into your repository and vice versa. I made a simple tool which does these things (thanks to Konstantin for ideas).
We tested the tool in a small development team and after month work we delivered all changed object to a pre-production database without problems.
It can:
1. Export as FOB;
2. Export as TXT;
3. Import from TXT;
4. Compile imported objects (only imported objects or import a piece of objects and then compile all).
Also, the tool works with objects in your license only so you will not have problems with skipping not licensed objects.
So firstly you need to instal it general way on your NAV 2009 database. Then you should prepare your repository.
Create a repo general way in your repo-server. Then pull it on a local folder. In the repo create a folder to store iconv.exe file. it will convert your objects from cp866 to utf-8 and back. PLace iconv files in the folder. You can download files here.
Your folder should look like ../iconv/
/iconv.exe/libcharset1.dll/libiconv2.dll/libintl3.dll
Then run the form “Object Manager” and set values for “App Folder Path” — a path where you store your objects in .txt, “FOB Folder Path” (optional) — a path where you store your objects in .fob, “Iconv File Path” — a path where the iconv.exe is located, “Compilation Strategy” — a method how will you compile imported objects. Export all your objects to “../application files” folder, you specified the path in “App Folder Path” value. Sync your repo with “origin” (git push). That’s your initial commit.
In our team, we tested the tool using “Git flow”, you can read more detailed about this workflow here and here. We had a master branch, a development branch and feature/task branches. So it was easy to link tasks and pull-requests (if you use Atlassian stack, it make all these for you), to comment collaborate on pull-requests and prevent some errors/not good enough solutions, know all about what we changed that month. I think it is a good base to make the development process easier (no more manual merge from lots of different databases), share knowledge and practices, control all is going on the project and start making automated tests.
If you still develop a NAV 2009 project, you could use it, you are welcome.
