Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-1577

Automated builds for FOLIO 'release'

    XMLWordPrintable

    Details

    • Template:
    • Development Team:
      Core: Platform

      Description

      Summary

      Continuously integrate and test new releases of both front-end and server-side components into
      a current and stable FOLIO instance that is accessible to POs, developers, and manual testers.

      Description

      Implement automated build pipelines for stripes platforms (platform-core and platform-complete)
      designed to integrate newly released modules into a stable FOLIO instance based solely on
      "released" versions of artifacts. PRs will be submitted in order add and test newly released
      stripes and UI modules into the on-going, stable release branch (master) of each platform's git
      repository. The PRs can either be manually created or generated automatically by an NPM dependency
      bot app that integrates with Github like Renovate or Greenhopper. These bots check for NPM
      dependency updates for specified NPM packages and repositories and automatally initiate
      pull requests to merge updated dependencies. Each PR will first trigger a build of the stripes
      platform, and, if successful will then attempt to build a FOLIO full stack by utlizing Okapi's
      "install" endpoint to resolve required interface dependencies provided by released server-side
      modules. If the build is successful, the UI integration test suite is run against the built
      FOLIO instance. If all tests pass, the PR can be then be merged to the stable release branch
      of the platform which will, in turn, can be used to build a publically accessible current and
      stable instance of FOLIO that can be used for additional testing/demos, etc.

      The PR test process includes the following quality gates:

      • Successful webpack build of the stripes platform. If the stripes platform cannot be built,
        then the PR will fail.
      • Successful interface dependency resolution between frontend and backend modules (releases only).
        If the new frontend module requires an interface that cannot be resolved by a released backend
        module, then PR will fail. This will ensure that frontend and backend module releases are
        coordinated.
      • Successful build of FOLIO instance to ensure installation processes are configured and working
        as expected and tenent initialization is successful.
      • Ensure passing UI integration tests to indicate either successful integration of the new module
        into the platform or to ensure tests are kept and current and compatible with new functionality.

      Tools/Platforms

      Each platform git repository will be integated with a Jenkins pipeline responsible for coordinating
      builds and testing using additional tools like folio-ansible and AWS. Each platform will also
      be configured with a NPM dependency bot like Renovate to provide updates to the platform and
      initiate PRs.

      Additional Outputs

      • A yarn.lock file representing a stable set of fixed NPM dependencies committed to the platform's
        stable, release branch.
      • install.json files committed to each platform's stable, release branch that can be used to
        build a FOLIO system from the most recent set of released and stable module.

      Prerequisites/Considerations

      • Front-end and backend module releases must occur on a regular, continuous basis in order
        for this process to work. Integration is more successful at regular, steady intervals (see FOLIO-1614)
      • An existing set of released compatible modules must be exist in order to build initial system
        (initial set to be based on Q4 release).
      • AWS resource utilization. We need to design a system that is cognizant of AWS resource
        utilization. Each PR will utilize an AWS EC2 instance and attached storage to build a
        FOLIO stack. Additionally, the process could be simplified to initialize a new tenant
        for each PR on an existing okapi cluster as long as larger number of released backend modules
        can be distributed across a cluster. Such a setup would most likely require additional
        orchestration tools, however. These ideas can be explored at a latter stage.
      • Determine how new backend module releases that are not explicitly required by frontend
        modules will be integrated into stable, release system.
      • Some Renovate initiated changes will fail, e.g consider the following scenario:
        "PR is issued to include new ui-users that depends on mod-circulation v2 but ui-checkin still depends on v1" in this and similar cases, a manual intervention will be required and a single PR that updates all ui- versions and a version of a shared dependency will be needed

      Definition of Done

      • Determine if prerequisites and considerations described above have been initially addressed.
      • Implement the process as described above and produce initial folio-release instances
        for platform-core and platform-complete.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                malc John Malconian
                Reporter:
                malc John Malconian
                Votes:
                0 Vote for this issue
                Watchers:
                11 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases