Foundational Ops

FPS Procedure – Start a New Release

Starting a new release occurs under 2 circumstances:

  1. You feel that the base accomplishments for the current release have been satisfied and the current maintenance is small fixes and small additions to the prior release. In this case add 1 to the patch level and continue updating the family release in the new patch structure. This process will be described under “New Family Release Patch”.
  2. New additions to the code outside of the current family concepts will be added. Under this circumstance a new family release is added and the new code is added there. This process will be described under “New Family Release”.

New Family Release Patch

When the current patch level is up-to-speed and tested with what was intended for the patch, the current patch is declared closed and a new patch is created. This process is as follows.

  1. Create the new patch directory under { FPS:Containers } by incrementing the [family]-Pn number by one.
  2. Within the new patch directory create all of the fully qualified container directories for Common, DataResources, Make, and Services (initially these directories will be empty).
  3. Move any source that may be still in-flight in the prior patch family directory to the same location in the new patch directory.
  4. Update the $global:pro_CIAttributes.Patch variable within the { FPS:Metadata:Pro-CIs-DMNnn } files to reflect the current patch level (Note: The patch level is not used for locational information, just as a note as to which patch each CI uses. If the patch directory is available on a CI, it will be used in conjunction with all other Patches to retrieve the current CmdLet to load.)
  5. Run a CICD -Sync to implement the new patch as the current patch within the runtime on each CI.

When updating a previously published file, copy the file from where it resides last in the prior patches to the current patch before editing. The revised CmdLet will be used after it has been sync’d during a CICD run on the CI. It is not necessary to set the prior patch header to INACTIVE as only the most recent CmdLet will be used. If a CmdLet is to be retired, set its header line to INACTIVE in all of the patches it is present in.

New Family Release

When the current family release is up-to-speed and tested with what was intended for the release, the current family and all patches are declared closed and a release is created. This process is as follows.

  1. Create the family release directory under { FPS:Containers } by incrementing the family alphabetically by one and reset the patch back to P1.
  2. Within the family directory create all of the fully qualified container directories for Common, DataResources, Make, and Services.
  3. Move all active source from the prior family to the same location in the new family directory.
  4. Perform a Grep within the new family release directory looking for :INACTIVE. Remove any CmdLet where present in the header.
  5. Update the $global:pro_CIAttributes.Family and $global:pro_CIAttributes.Patch variables within the { FPS:Metadata:Pro-CIs-DMNnn } files to reflect the current patch level (Note: The family level is not used for computational locational information, just as a note as to which family each CI uses. If the new family directory is available on a CI, it will be used instead of the prior family to retrieve the current CmdLet to load.)
  6. Run a CICD -Sync to implement the new family as the current family within the runtime on each CI.

Current and Future Family Releases

Family Release A – Aloha (Current Release)

  • Highlights: Core functionality created with base integrations to WordPress and KeePass.

Family Release B – Bermuda (Q4 2025)

  • Highlights: Integration with ServiceNow for base functionality and for user/group automation.

Family Release C – Cayman (Q4 2026)

  • Highlights: Deeper dive into WordPress and ServiceNow automations.