Tag Archives: GIT

Dynamics NAV & GIT

In this post I introduced Visual Studio Online as a tool to do source control for Dynamics NAV.

Another option is to use GIT. Visual Studio also conects to GIT and many developers love it.

It looks a lot less sexy than VSO but it is extremely powerfull and command line based. Try it out, it is fun.

Kamil Sazec, a good friend and NAV MVP has publised a script on codeplex for using GIT and NAV.

Here is what he says on his blog:

PowerShell–Strong tool for MS Dynamics NAV Developers

After long time, I have found some time to write this article.

Last few months was full of “Crete” testing including the PowerShell scripts to merge NAV Objects. And I must say, I have started to love PowerShell. Things, you needed to do manually or you needed to use some “hack” to do automatically (like using ROT), you can do now using PowerShell. And I started to create some scripts for things, I just needed actually do. You can find the scripts on the NAVScripts codeplex project, which is open for you and if you want, you can contribute. I want to have this project to store different scripts “made by NAV developers for NAV developers”.

Actually you can find these scripts there:

Merge-NAVGIT

this script takes two branches in GIT repository and merge the objects in them. You can solve the conflicts in kdiff3 or araxis merge (or any other tool if you want). This way you can “work around” standard GIT merge mechanism. I have merged the Rollup Update 9 to our Addon database in just 5 minutes! Merge of the updated addon to our customer customized database – another 3 minutes of work! In this way, you get the nice “train station plan” (my internal naming) like this:

image

Compile-NAVTxt2Fob

another script, which you can use after you merge the objects. This script is doing these steps for you automatically:

  1. Create new NAV database from .BAK file (e.g. from Cronus demo db backup)
  2. Create new NST instance for this database
  3. Import NAV license to the server (to have enough permissions to create objects etc.)
  4. Import selected .FOB file to the database (e.g. FOB with latest Rollup Update to update the database objects)
  5. Import selected .txt files to the database one by one (to see where is problem)
  6. Compile the objects imported in step 5 one by one (you can see the problems)
  7. Run NAV client for manual check of possible problems (could be skipped, could send email to you when ready for manual check)
  8. Export all objects to .FOB file
  9. Remove NST
  10. Drop database

As you can see, result should be FOB file with compiled objects ready for import to target database. It is something like “Automatic build process”. You can easily add part to run automatic testing…

 

Other functions

In the scripts there are many functions you can use for own scripts. You can export/import/compile objects to e.g. update the files in repository, update you database from the repository, merge version lists etc.

 

I hope that you will find these scripts usefull and you will be able to extend them as you will need. All is available from the codeplex here:

https://navscripts.codeplex.com

You can even fork/clone the GIT repository and contribute… Mrkající veselý obličej

Conclusion

Every NAV developer should learn powershell, because it could save big chunk of time for us. And with the accent to the up-to-date customers, we will need to press the upgrade cost down. And you cannot do that without automating the upgrade process. Correctly written scripts are good tool to do your work. They will never replace you, because still there are exceptions which needs some human brain to solve, but it is not 100% of the process now, but e.g. 10%.

Merge of our new version of addon to some customer database was 1-2 days in some cases. Now, with the script support, it is just 2-3 hours, in which the 1.5-2.5 hours are automatized and only 0.5 hour is “conflict solving”.

You can find many sources for beginning with powershell, but one for all: https://www.youtube.com/watch?v=MnWKPdkGFSU

Advertisements

Visual Studio Online | Welcome Cloud Development

It was not until recently that I was introduced to the term ALM. Application Lifecycle management. No idea when this Three Letter Abbreviation was invented but the problem it describes are much older, and familiar to a lot of Dynamics NAV developers.

About three years ago I wrote this article, that caused quite some stirr in the NAV Channel, unintended, but typical for our community I think.

So what is the problem definition.

Keeping track of Development History. Why did What happen and When.

After writing the article I dropped the subject. We started the Partner Ready Software initiative and ALM is/was not part of our initial primairy focus. When presenting our vision on Dynamics NAV development I use these slides:

2014-04-06_21-29-58

What we tried…

2014-04-06_21-30-22

What we need…

And from a pure software quality concept this is true.

But that does not take away the fact that ALM is quite cool too. And a recent development caught my attention that might be of interest to all Dynamics Partners, but especially the smaller ones or the ones who still do customer based development.

Until recently TFS had to be installed on premisse and it is “something to maintain” for IT guys.

When Waldo and I were in Redmond (WA) last year for MVP Summit I went to a session about ALM where Visual Studio Online was presented, as Luc van Vugt also mentions in one of his posts.

On first thoughts you might think this allows you to code C# in the cloud, and yes, you can do that if you want. But a better naming would be TFS Online since it allows a Team Foundation Server to run in the Cloud for free without any hassle or cost. How cool is that!

This is definately something that brings ALM back into my area’s of interest and I have already spent some time exploring it.

You can setup different projects in the tool and it allows you to define work items and sprints to work scrum. You can define team members and do planning and even do visual kanban planning. Really super cool!

The first downside I found is that it is still required to use an on site tool to check in and check out objects. You can use Team Exporer which is free.

PowerShell

But TFS also allows you to use PowerShell to check in and check out objects which means it can be integrated with existing Dynamics NAV PowerShell scripts. This would be very interesting to NAV Partners and we won’t need all these third party tools to integrate.

2014-04-07_19-39-54

GIT & Microsft Dynamics NAV

Another concept that I stumbled on while exploring VSO is GIT. I am not quite sure yet how to combine these two concepts in NAV but the way I look at it is that GIT helps while doing development and work is still unfinished, and when you check in objects in TFS they are ready to be tested.

TFS is integrated with GIT and I am going to spend some time investigating what the options are and how they can work together.