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 Jenkins job, orchestrating the release‑preparation workflow.

2. Platform Repository Preparation

• Jenkins 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 file to understand which modules/applications are part of the platform.

3. New Applications Merge

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

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

4. 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 or creates pom.xml and application.template files, inserting placeholder versions (e.g., CHANGE_ME).

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

    • The placeholder version (CHANGE_ME) is used so that developers can finalize the actual module versions later. This approach standardizes initial versioning steps while allowing flexibility for each module’s final version numbers.

  • Platform Descriptor Update

    • In parallel, the pipeline updates the platform descriptor to reference the new release branches and their placeholder versions.

    • These descriptor 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 versions (CHANGE_ME → actual version numbers).

    • 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.