feat: Update work items and documentation for improved release propagation clarity and system dependencies
This commit is contained in:
@@ -3,8 +3,8 @@ type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration]
|
||||
related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore]
|
||||
updated: 2026-04-16
|
||||
related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore, consumer-integration]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
@@ -23,6 +23,7 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
|
||||
- Validation in Fid4 often reveals issues that do not appear in XFlowSDK isolation or sample apps.
|
||||
- Historical Slack context shows that some tickets were incorrectly scoped until behavior was checked in Fid4 or flagship.
|
||||
- Real consumer testing in Fid4 matters for modal presentation, validation messaging, and backend-driven flow behavior.
|
||||
- Fid4 currently consumes XFlow through XFlowViewMaker rather than depending on XFlowSDK directly.
|
||||
|
||||
---
|
||||
|
||||
@@ -31,6 +32,14 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
|
||||
- If an issue depends on real flow behavior, do not assume XFlow-only validation is sufficient.
|
||||
- When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
|
||||
- Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
|
||||
- Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published.
|
||||
- The common update path is:
|
||||
- modify the Podfile to the new XFlowViewMaker version
|
||||
- run `tuist generate -n`
|
||||
- run `pod install --repo-update`
|
||||
- open and merge a PR
|
||||
- wait for the consumer team to carry the change forward in their normal App Store release flow
|
||||
- `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,8 +3,8 @@ type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-swiftui-migration]
|
||||
related: [fid4, xflowsdk, xflowviewmaker, pdiap-14859, pdiap-15836]
|
||||
updated: 2026-04-16
|
||||
related: [fid4, xflowsdk, xflowviewmaker, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
@@ -22,6 +22,8 @@ FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTra
|
||||
- FTFrameworks is often part of the real validation and release chain, not just a downstream detail.
|
||||
- Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4.
|
||||
- Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic.
|
||||
- `FTAccountOpen` and `FTTransfer` consume XFlow through XFlowViewMaker rather than directly from XFlowSDK.
|
||||
- For Account Opening flows, the current path is understood to go through `FTAccountOpen`.
|
||||
|
||||
---
|
||||
|
||||
@@ -34,6 +36,7 @@ FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTra
|
||||
- FTAccountOpen / FTTransfer
|
||||
- Fid4
|
||||
- Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
|
||||
- FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared `PR100660-ios-frameworks` monorepo.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,8 +3,8 @@ type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [rest-migration, ao-discourse, xflow-debugging, xflow-swiftui-migration, consumer-integration]
|
||||
related: [fid4, xflowviewmaker, ftframeworks, cogstore, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
updated: 2026-04-16
|
||||
related: [fid4, xflowviewmaker, ftframeworks, cogstore, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
@@ -21,6 +21,7 @@ XFlowSDK is the backend-driven UI engine that renders Fidelity flows from servic
|
||||
|
||||
- XFlow behavior depends on backend rules, entry point, and authentication state.
|
||||
- SwiftUI migration work introduced recurring behavior questions that were not just visual; many were contract or lifecycle issues.
|
||||
- XFlowSDK is developed in the dedicated repository `pr100660-xflow-for-ios`.
|
||||
- Historical Slack patterns show recurring topics around:
|
||||
- component type expansion in SwiftUI
|
||||
- Next-button visibility rules
|
||||
@@ -30,6 +31,14 @@ XFlowSDK is the backend-driven UI engine that renders Fidelity flows from servic
|
||||
|
||||
---
|
||||
|
||||
## Release Mechanics
|
||||
|
||||
- XFlowSDK publishing currently uses the Jenkins pipeline `xflow-for-ios-publish`.
|
||||
- The publish flow builds the XCFramework, publishes it to internal Fidelity Artifactory at `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
|
||||
- Once published, the new SDK version can be adopted downstream through `pod install` or `pod update`, but consumer validation still depends on XFlowViewMaker and Fid4 propagation.
|
||||
|
||||
---
|
||||
|
||||
## Debugging Implications
|
||||
|
||||
- Do not treat XFlow output as static UI; backend configuration can change the result.
|
||||
|
||||
@@ -3,8 +3,8 @@ type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-swiftui-migration]
|
||||
related: [xflowsdk, fid4, ftframeworks, pdiap-14859, pdiap-15836]
|
||||
updated: 2026-04-16
|
||||
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
@@ -22,6 +22,23 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework
|
||||
- Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible.
|
||||
- XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout.
|
||||
- Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions.
|
||||
- XFlowViewMaker currently lives in the monorepo `PR100660-ios-frameworks` under `Adapters/XFlowViewMaker`.
|
||||
|
||||
---
|
||||
|
||||
## Release Mechanics
|
||||
|
||||
- When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change.
|
||||
- The common release flow is:
|
||||
- update the XFlowViewMaker podspec to the new XFlowSDK version
|
||||
- run `tuist generate -n`
|
||||
- run `pod install`
|
||||
- open a PR
|
||||
- wait for required approvals, including protected-branch/code-owner approval when applicable
|
||||
- merge, often through automerge once approvals are complete
|
||||
- let the Jenkins pipeline `publish-XFlowViewMaker` publish the adapter release
|
||||
- `publish-XFlowViewMaker` usually auto-detects the next version and commonly increments the minor version automatically.
|
||||
- The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on `main`.
|
||||
|
||||
---
|
||||
|
||||
@@ -29,6 +46,7 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework
|
||||
|
||||
- When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption.
|
||||
- If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
|
||||
- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`.
|
||||
- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
|
||||
|
||||
---
|
||||
|
||||
@@ -3,9 +3,9 @@ type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
work-items: [pdiap-14859, pdiap-15836]
|
||||
related: [xflow-swiftui-migration, xflow-debugging]
|
||||
updated: 2026-04-16
|
||||
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
@@ -30,15 +30,65 @@ Capture the durable release and validation path between XFlow changes and real c
|
||||
|
||||
---
|
||||
|
||||
## Current Release Propagation Model
|
||||
|
||||
- The current release path is usually:
|
||||
- `pr100660-xflow-for-ios` releases XFlowSDK
|
||||
- `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release
|
||||
- `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
|
||||
- downstream consumer release then determines when the change reaches the App Store build
|
||||
- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
|
||||
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
|
||||
- Fid4 currently consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
|
||||
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
|
||||
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.
|
||||
|
||||
---
|
||||
|
||||
## Step-By-Step Propagation
|
||||
|
||||
1. Release XFlowSDK from `pr100660-xflow-for-ios`.
|
||||
- Jenkins pipeline: `xflow-for-ios-publish`
|
||||
- Produces the XCFramework artifact
|
||||
- Publishes to internal Fidelity Artifactory at `artifactory.fmr.com`
|
||||
- Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x`
|
||||
- After publication, consumers can adopt the new SDK version through CocoaPods
|
||||
2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`.
|
||||
- XFlowViewMaker lives in `Adapters/XFlowViewMaker`
|
||||
- Update the XFlowViewMaker podspec to the new XFlowSDK version
|
||||
- Run `tuist generate -n`
|
||||
- Run `pod install`
|
||||
- Open a PR and get required approvals
|
||||
- Ping code owners when protected-branch approval is the remaining blocker
|
||||
- After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter
|
||||
- That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0`
|
||||
- Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main`
|
||||
3. Update Fid4 in `ap010981-ios-flagship-app`.
|
||||
- Modify the Podfile to consume the new XFlowViewMaker version
|
||||
- Run `tuist generate -n`
|
||||
- Run `pod install --repo-update`
|
||||
- Open a PR and get approvals
|
||||
- After merge, the consumer team owns the final application release to the App Store
|
||||
|
||||
---
|
||||
|
||||
## Investigation Rules
|
||||
|
||||
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
|
||||
- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient.
|
||||
- Separate these failure modes:
|
||||
- SDK bug
|
||||
- adapter/version propagation issue
|
||||
- protected-branch or code-owner approval delay
|
||||
- publish pipeline failure or auto-versioning surprise
|
||||
- FT module publish/test issue
|
||||
- consumer app setup or pipeline issue
|
||||
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
|
||||
- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo.
|
||||
- The fastest reliable signals are:
|
||||
- fixed version references in the Podfile when present
|
||||
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
|
||||
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user