Layer 0 is always FPS. Layer 1 is divided into four main categories: Collections, Containers, Media, and Metadata. Each of these contain the remaining categories that reside under Layer 1.
When the code is ready to be implemented it will be placed in an “ACTIVE” state and will be used the next time the code is requested. Since VMs can assign the Source path as the Runtime path, all development must be marked as “DEVELOPMENT” within the handle status so it is not loaded when requested.
Previously, the profile within an action or in the UI would load all the modules upon login. However, this approach slowed down the overall action duration and module loads will be replaced with “on-demand” CmdLet loads in memory. Although the modules are not used as true modules in Aloha, they will be still configured in Module form and can be loaded as modules by uncommenting the section of the profile that checks $Env:PSModulePath within profile.ps1.
In the Aloha release, all capabilities previously supported by configurations have been automated, greatly simplifying CI maintenance.
Using one foundational standard for MID Server naming will greatly simplify CI maintenance moving forward. Only the base CI record will be necessary.
Removing the MID Servers configurations from the paradigm allowed another major Aloha enhancement being the elimination of the “build” process and associated manifest files. The build process is no longer practical. Everything is on-demand in this release.