Automated builds for FOLIO 'release'

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

• An automatically updated "next-release" FOLIO instance. e.g http://folio-release.aws.indexdata.com

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