/
Release preparation

Release preparation

This diagram focuses on the process of preparing for a FOLIO release by creating a dedicated release branch and configuration. In the FOLIO Eureka CI/CD ecosystem, release preparation is the step that bridges continuous development and an upcoming named release. Its purpose is to isolate release-candidate changes from ongoing “snapshot” development and to set up everything needed to eventually build official release artifacts. This is typically done at the start of a release cycle (for example, when the team is ready to freeze features for the R1 2025 release). The diagram shows how a new branch is created and how the system orchestrates module versions for the release. It fits into the CI/CD pipeline as a one-time (per release) setup flow that ensures subsequent release builds are consistent and that a stable set of module versions is identified.

  1. Parameter Setup & Job Trigger

  • DevOps (Kitfox) initiates the procedure by setting core parameters (e.g., previous release version, new release version, and any new applications to include).

  • These parameters feed into a CI job, orchestrating the release‑preparation workflow.

  1. Platform Repository Preparation

  • The CI framework checks out the platform‑lsp repository from the previous release branch.

  • A new release branch (e.g., Rx-202y) is created to isolate upcoming changes from ongoing development.

  • The process reads the platform-descriptor.json and platform-template.json files to understand which modules/applications are part of the platform.

  • The platform descriptor file must be deleted. It will be recreated during the release update CI flow.

  • The platform update configuration file (located in the default branch) must be updated with the new release branch reference.

  1. New Applications Merge

  • If any new applications were specified in the job parameters, the CI job automatically updates the applications section within platform-template.json.

  • This ensures the new release branch references the correct set of applications and modules.

  1. Per‑Application Branching & Configuration

  • For each application in the updated list, the job:

    • Clones the repository (based on the specified or previous release branch).

    • Create a new release branch to capture all release‑specific changes.

    • Updates the pom.xml, application template files, and deletes the application state file. The application state file must be deleted. It will be recreated during the release update CI flow.

    • The template file must include a placeholder restraint (e.g., ^VERSION) instead of the latest or previous release value. It helps ensure the new release module version is determined correctly.

    • Commits and pushes these changes to the new release branch.

      • The placeholder restraint (^VERSION) needs to be changed to the real module version limitation, for instance, to ">1.0.0 <=2.5.0" or “^2.0.0”. It will help to update several release module versions simultaneously and not overlap them.

    • The application update configuration file (located in the default branch) must be updated with the new release branch reference.

    • Platform Template Update

      • In parallel, the pipeline updates the platform template file to reference the new release branches and their major versions restraint (e.g., ^2.0.0).

      • These template changes are committed and pushed, aligning the platform’s master list of modules with the newly created branches.

    • Handoff to the Development Team

      • With each application branch set up and placeholders in place, the Development Team can now finalize module version restraint (^VERSION → actual version restraint).

      • This handoff ensures developers have a consistent, ready‑to‑configure branch for every module in the platform.

Key Benefits & Rationale

  • Automation & Consistency: By automating branch creation and version placeholders, the process ensures that every new application follows the same release workflow, reducing manual errors.

  • Modular Approach: Treating each application individually (cloning, branching, versioning) allows teams to manage changes at the module level while still tracking them in a central platform descriptor.

  • Streamlined Handoff: Developers only need to focus on final versioning in their respective modules, as the initial branching and file setup are handled automatically.

Overall, this flow provides a structured, repeatable mechanism for transitioning from ongoing development (master or snapshot) to a well‑defined release branch—ready for final version assignment, testing, and subsequent deployment.