Rancher Development Deployment Notes
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/11/14.
The official documentation is found in the How to Work with Rancher Environments documentation.
Be sure to read the official Jenkins CI 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:
The CLUSTER is set to
folio-dev
.The NAMESPACE is set to
aggies
.The MODULE_NAME is set to either
mod-workfow
ormod-camunda
.The MODULE_BRANCH is set to the desired Github branch name for the given module (aka: Feature Branch).
The CONFIG_TYPE is set to
development
.The MAVEN_ARGS is set to
-DskipTests
.The LOAD_REFERENCE is left unchecked.
The LOAD_SAMPLE is left unchecked.
The SIMULATE is left unchecked.
The IGNORE_ERRORS is left unchecked.
The AGENT is set to
jenkins-agent-java17
.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 simpler approach of just using platform-complete-aggies
branch from ui-workflow
may not consistently due to potential build time caching.
To work-around this, the solution is to make a new commit hash in the Platform Complete Aggies Rancher Branch for every rebuild.
The method of updating the package.json
file as described above achieves this result.
Consider also reading the CI Deployment Notes.
The Aggies team deploys a front-end module using the Build and Deploy UI Bundle process as follows:
The CLUSTER is set to
folio-dev
.The NAMESPACE is set to
aggies
.The FOLIO_REPOSITORY is set to
platform-complete
.The FOLIO_BRANCH is set to
aggies-rancher
.The CUSTOM_HASH is either left alone as empty or set to a specific commit hash from the
platform-complete
repository.The TENANT_ID is set to
diku
.The CONSORTIA is left unchecked.
The LINKED_DATA is left usually left unchecked.
The AGENT is set to
jenkins-agent-java17
.The REFRESH_PARAMETERS is usually left unchecked.
Pushing the Build button will build the image.
The reason for using the platform-complete-aggies branch for ui-workflow deployment is because the aggies-rancher branch in the platform-complete repository is set to point to the platform-complete-aggies branch in the ui-workflow repository.