Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

  • 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

...

  • 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