Thunderjet Case Study

Owned by Oleksiy_Lemeshko
Last updated: May 28, 2021 by Victoria_Smelova
3 min read

Rancher environment usage

Case 1. Rancher environment is used for UAT testing in general and for a specific Rollover feature

Benefits:

  • the functionality of the feature is storing a data in DB for a long term and update source code without clearing DB (not achievable on reference environments thus functionality can be hardly tested on non-rancher env)
  • PO and users were able to test the feature prior the release thus provide early feedback that was addressed keeping master branch stable

Specifics:

  • no specific feature branch was created, latest versions of modules were deployed from master
  • in case of “No-go” release decision the roll-back of the feature from master branch would have required significant efforts


Case 2.  Rancher environment is used for development of a feature that involved a set of modules without merging to master

Benefits:

  • very short release window for this feature and rancher allows to test the functionality separately from master because (at the end of the release cycle and we will still have a long way to go to make it work or something will go catastrophically wrong with the changes we make there then we will be able to keep it aside and continue working on next release since this change is not critical for the release
  • from the PO perspective it saves a lot of time for data preparation and testing might take longer than 1 day and the data should stay there. In such environment rancher gives us a control of data clearance

Specifics:

  • separate feature branch was created with rancher pipelines used for deployment
  • stories are deployed, reviewed and verified on Rancher env (no merging to master)
  • if verified on rancher a story is closed with a special fix version created (for example "rancher - featureName")
  • separate task is created in backlog to merge stories later (stories verified on rancher and closed are linked to the merge task)
  • when the whole feature is completed and successfully tested on rancher, the merge task is done and all the linked stories (with "rancher - featureName" fix version) are merged to master
  • "rancher - featureName" fix version is deleted from jira, while deleting it is necessary to indicate which of the current fix version is appropriate for all the merged items (thus, all the items are marked with correct fix version)

Case 3.  Rancher environment is used for various feature front-end implementations

Benefits:

  • PO was able to use more than 1 front-end implementations of the feature and define the version that is most feasible for users (for instance, two different versions were deployed on an env and each had it's own link)

Specifics:

from UI perspective here are steps to deploy separate feature-branches of modules to a separate app URL (same tenant):

  • https://rancher.dev.folio.org/ Apps - clone platform-complete (change name of the app, no digits, Namespace - thunderjet, put desired url in ingress.hosts[0].host)
  • checkout platform-complete repo, make sure you have latest snapshot branch, delete locally and checkout thunderjet-rancher branch. Rebase platform-complete/thunderjet-rancher to the latest snapshot branch
  • create new branch of platform-complete from thunderjet-rancher branch (thunderjet-rancher-your-feature)
  • edit .rancher-pipeline.yml: ingress.hosts[0].host, name - your rancher cloned app name, branch/include - put your branch)
  • edit package.json to point for branches with your code ("@folio/orders": "git://github.com/folio-org/ui-orders.git#UIOR-623",), run yarn and commit changes for yarn.lock as well.
  • publish that branch and you can Run pipeline in rancher (Resources/Pipelines/platform-complete, choose your branch), it should build and deploy customized platfrom-complete under new url and the same tenant