Start using Git with Dynamics NAV dev team

Hi team!

Primarily the article is dedicated to Dynamics NAV developers which are aware of Git but still don’t know how to start. I think the article will be also useful for different types of developers and users.

In the previous article, I described how to convince your team to use Git. Here I will try to describe the easiest way to start.

Onboarding

First of all, you need someplace where you will store all the information for team members. It could be Confluence space, OneNote book or even a shared folder. You start collecting and creating a knowledge base which will be populated step by step. Maybe some of your team members will assist you later.

Remember, all colleagues have a different level of knowledge and interest. They will need some references and you should provide your colleagues with them.

Prepare an environment and a minimal list of tools

You need tools to maintain Git repo and your Dynamics NAV environment: where to see commits and history, how to handle conflicts, how to control your code and changes. My set is here:

1. Git;
2. PowerShell (version 5 and higher) + poshGit — Dynamics NAV scripts and Git client in PowerShell;
3. VS Code + GitLens extension— maintain code, see differences and changes;
4. Source Tree — the same as VS Code, somebody could find it more convenient;
5. Beyond Compare — solve code conflicts, merge files.

Also, you need an origin repository. In my case it is Bitbucket.

Set up all these tools, test whether is all ok.

Education and materials

You have your tools and information tool — it’s time to combine. Publish information about how to use the tool.

In my case, it was two spaces: learning materials and guides.

Learning materials include typical scenarios, learning materials (how-tos) and small tasks to try manually tools. List:

1. How to clone repository;
2. Adding commits;
3. Pushing code to the remote repository;
4. How to work with internal dev tool (applicable for 2009 only);
5. How to solve conflicts (two ways).

Guides include the following:

1. List of tools;
2. Setting up;
3. Working with the internal tool;
4. How to sync the Dynamics NAV database with the local repo;
5. Working with Git (typical actions);
6. Solving conflicts;
7. Pull-requests;
8. Working with history;
9. Gitflow branching model;
10. Preparing releases.

Explain all your scenarios. Not so carefully, later you will have more time for it and also you will have a team.

Once having materials you can prepare all your team members. Again and again. Go through learning materials with your team, ensure everyone has a clear understanding of what is Git, why you need it and how to use it.

Probation period

This is the most difficult stage. You should be absolutely confident in everything: team, tools, supervisors, tools and environment. All tools have to be prepared beforehand while learning stage. All team members have to be honest with you and you too.

You should have a contingency plan.

In case something goes wrong, there should be an opportunity to fix details. If somebody failed with Git routine, you have to be near. It’s better to have somebody to back you.

If something is wrong with the release, you should have a plan on how to produce a release according to previous before-Git model and continue Git-project. The best way is to duplicate the process this time: work via Git and send files (.FOB or text) as you work before.

Make a goal. For example, work via Git some period of time. After the time passed you would be able to draw conclusions, analyse and react.

Then just work!

Free flight

So you have a confident trained team, tool and better process. You have time to breathe out. Good work!

Nothing could be perfect, so go further: think of automated builds and tests, automated deploys and all these DevOps things. You have lots of work to be done. Good luck!

More inspiring stories and useful insights here.