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 8 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 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 Aggies team deploys a front-end module using the Deploy UI Bundle (Deprecated) process as follows:

The Deprecated UI Bundle build process is currently being used because the newer one at Deploy UI Bundle is not yet ready for use. Given the deprecated state, this process is subject to change at any point in time.

  1. The REFRESH_PARAMETERS is left unchecked.

  2. The RANCHER_CLUSTER_NAME is set to folio-dev.

  3. The RANCHER_PROJECT_NAME is set to aggies.

  4. The UI_BUNDLE_TAG is set to a desired image (if one is already bundled) or left blank.

  5. The UI_BUNDLE_TAG is left unchecked when UI_BUNDLE_TAG is to be used, but when a new bundle is desired then this must be checked.

  6. The FOLIO_REPOSITORY is set to platform-complete.

  7. The FOLIO_BRANCH is set to aggies-rancher.

  8. The TENANT_ID is set to diku.

  9. The CONSORTIA_ENABLED is left unchecked.

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

  • No labels