Tag: C/Side Code

In our past videos we have seen how to install and configure AdvaniaGIT.  We have also seen how to create localization and solution branches.

Now it is time to start development in C/AL.

Out next question is, how can be develop in AL using VS Code and AL Extension.  We will look at that soon…

Most of us are not just starting working with NAV.  But again not all of us have been able to apply Source Control Management (SCM) to our daily work.

In the previous posts we have installed and prepared our development environment and we are now ready to start working on our solution in the SCM way.

Our first step is to create a branch for our solution.

Now we should look at the options we have to import our solution into our branch.  We can have our solution in different formats.

All these file formats can be imported into our solution branch with the tools that AdvaniaGIT delivers.  Let’s start with the SQL backup, 2016-DAA_WineApp.bak.  AdvaniaGIT will search for backups using these patterns.

    $FilePatterns = @(
        "$($SetupParameters.navRelease)-$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.navVersion)/$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)-$($SetupParameters.navSolution).bak"
        "$($SetupParameters.navRelease)/$($SetupParameters.navVersion)/$($SetupParameters.navSolution).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.navSolution).bak")

In this example the values are:

    $FilePatterns = @(
        "2016-WineSolution.bak",
        "2016/9.0.46045.0/WineSolution.bak",
        "2016/WineSolution.bak",
        "2016-NA.bak"
        "2016/9.0.46045.0/NA.bak",
        "2016/NA.bak")

The module first searches the local drive (default = C:\AdvaniaGIT\Backup) and then the ftp server if one is defined in GITSettings.json.

When AdvaniaGIT creates a database backup it is named according to the first pattern, in this case 2016-WineSolution.bak and saved in the default backup location.

The rest of the file types require that the solution branch has already been built like shown in the first video.

Here we restore from bacpac.  Bacpac format is for example used by AzureSQL.

The Navdata format was created by the NAV development team.  To be able to import from a Navdata file we require an Navdata export with the application included.

Perhaps the most common way is to have a FOB export.

Text exported objects can be imported directly into out GIT branch.

And finally we can update the solution branch from delta files.

Out next task will be to do some development in our solution and commit the changes we make to our GIT server.  Stay tuned…

In our previous post we completed the installation of GIT, SourceTree, NAV and the AdvaniaGIT modules.  We also created a GIT repository in Bitbucket.  We selected to use BitBucket just because I already had a user configured there.  I also have a user configured in Visual Studio Online where I store many of my NAV solutions in a private GIT repository.  Public projects I put on GitHub.  As I stated before we must make sure not to push any of the NAV standard code to public repositories.

Advania has internal GIT servers where we host our solutions.

The choice is yours.  I don’t have any favorite GIT server solution.

In Advania we have created a branch structure.  We create repositories for each NAV version.  The master branch is always the W1 release.  Each commit to the W1 branch contains a CU update.  We always store all objects in every branch.  In solution branches we also store deltas and reverse deltas.

We can access any of the CU’s code from the GIT repository and we can see every code change made from one CU to the next.

We branch out master to each localization.  Each localization has the same rule as the master branch.  Every CU is available and every code change is traceable.

All the GIT servers have a nice web interface.  There we can easily see all commits, all code and all changes.  This is a list of commits for the master branch.

This is a list of code changes in NAV 2017 CU8.

Let’s go ahead and create our first localization branch.  In the following video I use the AdvaniaGIT functions to download and extract information from the latest CU.  I don’t have a function that will download all updates for a given version.

Our next step will be creating a solution branch based of our localization.  Stay tuned…

We have a predefined folder structure in our GIT repository.  Each repository can have multiple branches.  The first branch and the parent to all the rest is “master”.  In our structure we always store released W1 objects in the master branch.

The GIT sub folder structure is defined in GITSettings.json.

“setupPath”: “setup.json”,
“objectsPath”: “Objects”,
“deltasPath”: “Deltas”,
“reverseDeltasPath”: “ReverseDeltas”,
“extensionPath”: “Extension1”,
“imagesPath”: “Images”,
“screenshotsPath”: “ScreenShots”,
“permissionSetsPath”: “PermissionSets”,
“addinsPath”: “Addins”,
“languagePath”: “Languages”,
“tableDataPath”: “TableDatas”,
“customReportLayoutsPath”: “CustomReportLayouts”,
“webServicesPath”: “WebServices”,
“binaryPath”: “Binaries”,

We store all the NAV objects in the “Objects” folder.  All NAV objects is everything needed to build a solution from our GIT branch.

The basic rules are

• Each branch needs a unique id, a GUID.  You can find a new guid with any of the online guid generators.  The branchId parameter is stored in each branch setup file.
• Public repositories must not contain exported Microsoft objects.  These repositories must have the storeAllObjects parameter set to false.  These branches are based on standard objects in the Source folder and the Deltas in the repository.
• Keep your common parameters in Data\GITSettings.json and your branch specific parameters in Setup.json

List of available setup parameters can be found on the AdvaniaGIT wiki.  The Wiki is a work in progress.

As we go through each of the Custom Actions we will talk about these parameters and how they are used.

Here is a demo video on me creating a private repository for NAV 2017 solutions.

The AdvaniaGIT module links each branch to an installed NAV environment.  This link is stored in Data\BranchSettings.json and is automatically maintained when environments are built and removed.

NAV Environment and NAV Databases have name rules.  Prefix is NAVDEV then the main release then an automatically increment number.  Example could be “NAV2017DEV0000008”.  The last increment number is stored in Data\BuildSettings.json and is updated on every environment build.

All installed NAV versions must be defined in Data\NAVVersions.json.  Make sure to have the correct web client port to have your web client working correctly.  This is an example of my NAV versions.

{
  "Releases": 
	[
		{"mainVersion": "90", "navRelease": "2016", "webClientPort": "8090", "helpServer": "nav90help.advania.is", "helpServerPort": "80"},
		{"mainVersion": "100","navRelease": "2017", "webClientPort": "8080", "helpServer": "nav100help.advania.is", "helpServerPort": "80"}
	]
}

This summer I got the change to work with Microsoft on vNext.  Microsoft gave me access to a GIT repository with their base application.  The GIT repository contained a ReadMe file and a folder called BaseApp with all the objects.  I just added a setup.json file to repository and was able to use SourceTree and the custom actions for all the development.  Here is the setup.json file I added.

{
  "branchId": "1901c80b-711a-4564-aec6-ac7684e578cb",
  "navVersion": "10.0.17001.0",
  "navSolution": "W1",
  "projectName": "W1",
  "storeAllObjects": "true",
  "objectProperties": "false",
  "objectsPath": "BaseApp"
}

Our next task will be on creating a branch for our localization and our solution.  Stay tuned…