Rancher Development Deployment Notes

Owned by Kevin Day
Last updated: yesterday at 4:50 PM
3 min read

Rancher may be logged into here: https://rancher.ci.folio.org/dashboard/auth/login .

The deployment process is undergoing changes by the DevOps team and this process is accurate as of 2024/10/30.

The official documentation is found in the How to Work with Rancher Environments documentation.

The deployment process involves deploying back-end modules and front-end modules (UI modules).
The process for deploying for active development for back-end module involves Deploying via a Feature Branch.

Ensure the Rancher Pod is Running

Recent operational decisions have led to having the Rancher Pods being offline based on a schedule.

The Rancher Pod should be started before deploying.

The https://folio-dev-aggies-diku.ci.folio.org/ will show a 502 Bad Gateway when the Pod is down.

Use the Scale Up or Down a Pod via Manage Pods to bring the Pod up.
The How to Start/Activate Rancher Environment guide describes how to do this.

Deploying Feature Branches

A feature branch is simply a branch on Github that is to be deployed.
These branches are classified as a “feature branch” even if they are bug fixes or something else that is not a “feature”.

Deploying Back-end Module Feature Branch

Some of the back-end module deplyoment feature branch process is still described in the (Deprecated) Deploy/Update back-end module from feature branch documentation.

The pipeline build select lists filtering can be slow and generally processes one character at a time.
It is easier and faster to type the search filter in another place (text editor, command line, browser tab, etc…) and then copy that over in the the filter.

The Aggies team deploys a back-end module using the Jenkins Feature Branch Deployment process as follows:

  1. The CLUSTER is set to folio-dev.

  2. The NAMESPACE is set to aggies.

  3. The MODULE_NAME is set to either mod-workfow or mod-camunda.

  4. The MODULE_BRANCH is set to the desired Github branch name for the given module (aka: Feature Branch).

  5. The CONFIG_TYPE is set to development.

  6. The MAVEN_ARGS is set to -DskipTests.

  7. The LOAD_REFERENCE is left unchecked.

  8. The LOAD_SAMPLE is left unchecked.

  9. The SIMULATE is left unchecked.

  10. The IGNORE_ERRORS is left unchecked.

  11. The AGENT is set to jenkins-agent-java17.

  12. The REFRESH_PARAMETERS is left unchecked.

Pushing the Build button will build the image.

To determine what has been run previously (and with what parameters) the job history should be used:

Confirming a Back-end Module Feature Branch is Deployed

The build process should show success, but one should also visit the Aggies Scratch Environment to confirm that the back-end module is correctly deployed, registered, and enabled.

Each build in the pipeline ends up with a build hash appended to the end of the package version.
The hash is generally a short github hash, which as an example might be something like 70a44d3.
GIven a mod-workflow with a package version of say 1.2.0-SNAPSHOT, then the resulting pipeline built version would be mod-workflow-1.2.0-SNAPSHOT.70a44d3.

This can be confirmed or denied by visiting the Aggies Scratch Environment Software Versions page.

Under the OKAPI Services column, there should be two particular modules of concern, mod-workflow and mod-camunda.

The mod-workflow module might look like this:

Workflow Module (mod-workflow-1.2.0-SNAPSHOT.70a44d3)

The mod-camunda module might look like this:

Camnuda BPM Module (mod-camunda-1.2.0-SNAPSHOT.d18c2f2)

Deploying Front-end Module Feature Branch

The feature branch is deployed using the platform-complete-aggies branch from the ui-workflow project. That branch should be updated to contain the desired state of the code that is intended to be deployed. This branch may be force-pushed to.

Before deploying, make sure that the platform-complete-aggies branch is up to date with the desired code changes.

The feature branch is now deployed by modifying the package.json in the Platform Complete Aggies Rancher Branch.
The @folio/workflow must be set to the gitub repository and branch (such as my_custom_branch), like this:

"@folio/workflow": "https://github.com/folio-org/ui-workflow.git#my_custom_branch",

The Aggies team deploys a front-end module using the Deploy UI Bundle process as follows:

  1. The CLUSER is set to folio-dev.

  2. The NAMESPACE is set to aggies.

  3. The FOLIO_REPOSITORY is set to platform-complete.

  4. The FOLIO_BRANCH is set to aggies-rancher.

  5. The CONFIG_TYPE is set to development.

  6. The TENANT_ID is set to diku.

  7. The UI_BUNDLE_BUILD is usually checked (uncheck to select an existing bundle).

  8. The UI_BUNDLE_TAG is set left alone or blank except when UI_BUNDLE_BUILD is unchecked.

  9. The CUSTOM_HASH is set left alone.

  10. The CONSORTIA is left unchecked.

  11. The AGENT is set to jenkins-agent-java17.

  12. The REFRESH_PARAMETERS is left unchecked.

  13. Pushing the Build button will build the image.