Skip to end of banner
Go to start of banner

Rancher Development Deployment Notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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 Back-end Module Feature Branch

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

Some of this 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 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)

  • No labels