Spitfire Case Study

Owned by Oleksiy_Lemeshko
Last updated: Apr 27, 2021
2 min read

Rancher environment usage

Problem to be resolved. Long living repository branches were identified as problem for interim feature testing thus early feedback from PO provision. Long living branches contained both ready for testing feature functionality and in development feature functionality so standard FOLIO workflow was not applicable since this feature was agreed to be merged into master after PO runs full test cycle on rancher

Rancher based process flow was established starting Q3:

  1. Long living branch was created for specific feature
  2. Development team contributed multiple changes into the branch (Jira scrum board flow column for user story in sprint: “In progress” or “In Code Review”)
  3. Deployment on rancher env took place once any feature functionality development was done (Jira scrum board flow column for user story in sprint: “In Code Review”)
  4. Developer performed dev testing (Jira scrum board flow column for user story in sprint: “In Code Review”)
  5. Developer notified PO that feature functionality was ready for testing (Jira scrum board flow column for user story in sprint: “In Review”)
  6. PO performed early feature testing on a user story level and reported back to development team (Jira scrum board flow column for user story in sprint: “In progress” or “Done”)
  7. Specific testing task was added to backlog to ensure the feature is tested on reference environments after merging the branch into master


Use case: feature in progress belonged to a certain module. All changes were committed into this branch

Problems and constraints that were encountered

  1. Manual pipeline restart was required after adding a change. To have this problem resolved one should enable pipeline setting “Pipeline Trigger” (configurable for push, pull or tag)
  2. Each team should have its own pipeline config for a branch when working with module that team does not own. No workaround identified so far
  3. Other modules dependencies required diligence in following specific order of these modules upgrade in case of module version change
  4. There were no other features in progress within the module so separate branch was created. When development takes place in multiple modules the approach can hardly work