Pro-Config
By j.dickey | Published | No Comments
After loading the profile.ps1, the more dynamic “Pro-Config” file is executed to set up the remaining foundational elements of the PowerShell session. With the FPS Aloha release, this process has been significantly automated, reducing maintenance by 90%. Previously, it required loading a large number of configurations, but these have now become obsolete opting for a simpler set of logical configurations. The context and automation redesign in FPS Aloha now manage these elements internally, marking a substantial improvement over the previous release.
[Key Insight b3.1] The past versions Continuous Integration/Continuous Development (CICD) processing did the patching throughout the domain. The configuration of the CI’s across the domain became error prone when maintained manually – especially when the number of CI’s using FPS go above 50. It’s a bit easier when the file is partly automated, but there still has to be a person involved. In the FPS Aloha release, nearly all capabilities previously supported by configurations have been automated greatly simplifying CI maintenance. [Key Insight b3.2] Removing the configuration files from the paradigm allowed another major FPS Aloha enhancement being the elimination of the “build” process and associated manifest files.
Eliminating the build process was straightforward but necessitated a complete top-down rewrite of the code to accommodate this major theoretical shift. The filesystem’s structural orientation had to inherently support progressive patching and locating the correct version to load. Moving away from module loads improved both supportability and load speed. Considering internal CmdLet dependencies, automating this portion didn’t make much sense, as developers know the dependencies while coding. By implementing a simple CmdLet to locate the necessary file (Get-ActiveFileNm), we achieved similar ease-of-use to the automated manifests of prior releases. With the FPS Aloha release, routine configurational maintenance from previous versions has been eradicated.
With the latest upgrades, the Pro-Config file serves three primary functions. First, it loads the four essential base CmdLets: Get-ActiveFileNm, Push-NeededFor, Mount-Path, and Get-Answer. Second, it dynamically identifies the modules to be included via $global:FPSModules. Module introduction was difficult in prior releases requiring a large number of configurations throughout the code. Modules are now dynamic in nature, therefore no configuration is necessary other than placing the module in FPS/Containers. [Key Insight b3.3] Module introduction can only occur in the initial release for a code family and cannot be introduced during patching of a family release. Third, it loads the Shortcuts. Get-ActiveFileNm and Push-NeededFor enable the loading of dependent CmdLets as illustrated below:
if (Push-NeededFor Get-Answer) { . (Get-ActiveFileNm -PS1 Get-Answer) }
[Requirement b3.1] Shortcuts function as a distinct subsystem, enhancing the capabilities of standard Alias’s. Located in the first module layer with an SC- prefix, shortcuts provide access to all capabilities and services. Pro-Config scans all shortcuts in the configured base release for the CI (family-P1) and loads the active version of each noted shortcut. [Key Insight b3.4] If a shortcut is first introduced post-initial patch release (past Patch 1), a “stub” shortcut must be included in the base release (Patch 1), with only the handle present within the code.
Pro-Config is a straightforward load file with several pseudo-dependencies involving utility software essential for future development. These dependencies must be coded now due to their close correlation and interdependence with the profile functionality currently being designed. The required dependencies are listed below (click on the file name to view the sample source):
NOTE: Never include these CmdLets as a dependency. They are perpetually available via Pro-Config.ps1)
Get-ActiveFileNm – The first item that is loaded are the core CmdLet Get-ActiveFileNm. This is a KEY foundational CmdLet and is loaded perpetually via Pro-Config.ps1 Get-ActiveFileNm is the CmdLet that loads that retrieves the fully qualified filename of the ACTIVE entity currently in use for the current patch of FPS. Since this CmdLet drives all file loads within the system, its critical that it is the first thing that is loaded within Pro-Config. The first thing that needs to be spec’d out is to hunt the current release of the code. The input to the CmdLet will be the CmdLet name and the FPS/Containers directory will be searched for the currently ACTIVE source. Theoretically there will only be one ACTIVE source in the containers directory, but the likelihood that two may exist is possible, so that circumstance needs to be coded in also. Given the filesystem structure used for the Containers path, the last item in a Get-ChildItem list will aways be the most recent – therefore the correct file to load. The actual CmdLet used will return the filename back to calling script so that it can be loaded in context to the calling scope.
Push-NeededFor – Confirms if a function (CmdLet) exists. This is a KEY foundational CmdLet and is loaded perpetually via Pro-Config.ps1. The name given is for readability purposes when used. An example usage is:
if (Push-NeededFor Get-Answer) { . (Get-ActiveFileNm -PS1 Get-Answer) }
…where the if statement is descriptive of its use.
Mount-Path – Ensures that a complete path exists from the path sent as a parameter. Interrogates the entire stream to make sure all sub-paths exist prior to checking the next. At the conclusion of the CmdLet, the complete path will exist and the return path will be the fully qualified path that was created.
Get-Answer – Simple function that asks a question until a reply is given. The reply is then sent back to the calling script.
Referenced Source Files
Source for profile.ps1, Pro-Config.ps1, Pro-Locations.ps1, Get-ActiveFileNm.ps1, Mount-Path.ps1, Push-NeededFor.ps1,and Get-Answer.ps1.
Leave a Reply
You must be logged in to post a comment.