Discuss localdevenv.ps1 - OG Style (transition out of OnPrem)

[KristofKlein]

Disclaimer

I work on an OnPrem source, which in the couple of next weeks/month should reach "cloud readyness". However, i need to have local developers. And Those need support and "easy access" to get to work quicker as they have to deal with like today.
Al:go Pipelines get the job magically done. i struggler with the part for the developers

localDevEnv.ps1 and settings.json

So in order to get this moving I stole some setup from the Business Central Repo:

{ "enablePerTenantExtensionCop": false, "includeAL": true, "runSandboxAsOnPrem": true }

furthermore I also added a NewBCContainer.ps1 (overwrite) - again copied from Business Centrals own repo:
With this I can enforce some details needed to run proper on my machine:

Param(
    [Hashtable]$parameters
)

$parameters.multitenant = $false
$parameters.RunSandboxAsOnPrem = $true
$parameters.memoryLimit = "16G"
if ("$env:GITHUB_RUN_ID" -eq "") {
    $parameters.isolation = "hyperv"
    $parameters.includeAL = $true
    $parameters.doNotExportObjectsToText = $true
    $parameters.shortcuts = "none"

    $parameters.MyScripts = @(@{"SetupDatabase.ps1" = '. c:\run\SetupDatabase.ps1; Invoke-Sqlcmd -Query "UPDATE [CRONUS].[dbo].[Published Application] SET [Published As] = 2, [Tenant ID] = ''Default''"' })
    
}
    New-BcContainer @parameters
    Invoke-ScriptInBcContainer -containerName $parameters.ContainerName -scriptblock { $progressPreference = 'SilentlyContinue' }

[actually I removed some code I have in my real script of this which handles custom dlls copy into the container😲 ]

Furthermore I have a GitHub Repo setting that sets "useProjectDependencies": true

I do not use appDependencyProbingPaths nor fetching of releases from github or nuget packages. I want the local to be a "true local".

The Repo

So my Repo looks like the following (I leave out all the test apps) - abstracted:

Repo

• Project A
  • App A.1
  • App A.2 (depends on A.1) [actually an Empty App that propagates Dependencies from A.1]
• Project B
  • App B.1 (depends on A.2)
  • App B.2 (depends on A.2)
• Project C
  • App C.1 (depends on A.2)

so what's the deal?

When I run localdevenv.ps1 for Project A - all is good. A.1 and A.2 are ending up in the container, and is well working.
If I now enter Project B, and run localdevend.ps1 and let it create another container it tells me that it sorted the Apps in my Project B folder, and it finds, besides BC A.2 as external dependency. And when it goes into compile it also shows that it is using A.2 ("Dependency App exists"). And compiles (not sure how it does that ...)! However, this is not good enough, as A.2 is just a propagating app. And it will not be able to publish the App into the container as it will need A.1 as well.

So is this me, having:

• a bad dependency resolving logic ( Al:Go pipes are working fine....)
• a bad Project Setup
• a bad app setting
• a bug in resolve dependencies not seeing the need for A.1

Furthermore,

IF you setup your workspaces, do you let them share e.g. the .alpackages folder? While writing it my brain said: "depends I guess?!" If one project is depended on another lets say country specific base app, it should be individual, if it is the same for all they might as well just share.
IF you have a multi Project Repo, do you expect a Repo Level localdevenv.ps1 ? Like one, that will deploy all the Projects into one container? If not, do you "Stack" deployments in local containers manually: like here I create container for Project A but now now I manually also publish B into it.

Unfortunately the Al:GO articles about development environments are quite an empty space - but maybe this discussion can be fruit for thoughts? What is needed? And I am aware that Al:GO is not really for OnPrem folks, still it looks like to be "close enough" to onboard onPrem folks to get into cloud readiness.

Outlook

well, obvious more documentation 😅 . I also see the need coming around the corner with multi repos which, If i read it right, will need appDependencyProbingPaths. So is it a good idea to mix? should all be appDependencyProbingPaths ? Is there than still the need for useProjectDependencies ? Just by looking at Al:Go it seems to have some tendencies to introduce more and more feature, while having a hard time to "please" everyone and cut away old branches. Don't get me wrong. I like it, and I like the extensibility ( "this is not for onPrem! but you know what? I can do it anyway if you tweak x, squeeze y and tickle z")
Or do I put "too much" into localdevEnv.ps1? as, the name says, is AlGo for GitHub (and pipelines), and maybe just a "nice to have"...can such a script fit all?
So with all the bells and whistles around "Nuget Packages Format". It feels there is "another big thing" around the corner that potentially will flip all this "upsidedown" once more. And tbh, sometimes it fells like: If you don't join all the conferences around the globe you will be missing something here. Which is kind of sad....

So this was a lot of text, with hopefully not too many stupid questions 😄
Skål ✌️

[KristofKlein]

Let me continue here a bit :)

So, after useProjectDependencies did not helped, I went along with option two.

  "appDependencyProbingPaths": [
    {
      "repo": ".",
      "release_status": "include",
      "projects": "W1"
    }
  ]

Which in fact also works for localdevenv.ps1 and not only for pipelines! (Which is kind of a big miss on the settings.md file explaining appDependencyProbingpaths) Well, after quite some while of waiting, I got my container with the apps I need for the selected Project! That. Is. Awesome! However, it makes setup of projects more complicated and is somewhat easy to forget.

This now also explains a bit on the other bits on making use of appDependencyProbingPaths together with GitHub Packages and the need for fitting tokens.

So for me, this is right now the best setup I can make use of: appDependencyProbingPaths using release_Status: include setup in the localDevEnv.settings.json per project as it stays local. It uses quite some time to get all set, but that is just what it takes.

so now it works or what?

Well yes, but still I am left a bit confused on the "two-faces" of that setting. Why is it not two dedicated once? You could even think of make use of gh and releases as primary source, if you can. If not "fall back" and try do the local thing?