Skip to end of banner
Go to start of banner

Thunderjet Case Study

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 3 Current »

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

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


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
  • No labels