feat: Update work items and documentation for improved release propagation clarity and system dependencies
This commit is contained in:
@@ -32,4 +32,4 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
|
||||
|
||||
- `PDIAP-15765` - AO DOB field error not showing investigation
|
||||
Detail: `vault/02-work-items/pdiap-15765.md`
|
||||
Current note: the small XFlowSDK iOS `birthDate` fallback was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up PR is open and partially approved but still needs one FTFrameworks code-owner approval before merge, then the pipeline and Fid4 update still need to happen.
|
||||
Current note: the small XFlowSDK iOS `birthDate` compatibility fix was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up PR is open and partially approved but still needs one FTFrameworks code-owner approval before merge. After that, `publish-XFlowViewMaker` must release the adapter, then Fid4 must update its Podfile and merge the consumer PR so the change propagates through the real app path.
|
||||
|
||||
@@ -4,10 +4,10 @@ project: fidelity
|
||||
status: active
|
||||
ticket: PDIAP-15765
|
||||
title: "AO DOB field error not showing investigation"
|
||||
systems: [xflowsdk, fid4, cogstore]
|
||||
workstreams: [ao-discourse, xflow-debugging]
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore]
|
||||
workstreams: [ao-discourse, xflow-debugging, consumer-integration]
|
||||
people: [jeff-dewitte, gurram-santosh, raj-sundararaj]
|
||||
related: []
|
||||
related: [pdiap-15838]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- work-item
|
||||
@@ -71,7 +71,8 @@ tags:
|
||||
## Next Step
|
||||
|
||||
- Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR.
|
||||
- Run the remaining pipeline/release steps after the PR merges.
|
||||
- Update Fid4 so the released XFlow `2.8.48` change propagates through the consumer path.
|
||||
- After merge, let `publish-XFlowViewMaker` release the updated adapter version.
|
||||
- Update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR.
|
||||
- After the Fid4 PR merges, treat the app release as the final downstream step before broader user visibility.
|
||||
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
|
||||
- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.
|
||||
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
type: people-index
|
||||
project: fidelity
|
||||
updated: 2026-04-16
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- people
|
||||
- map
|
||||
@@ -50,6 +50,9 @@ tags:
|
||||
- [derian-cordoba.md](./derian-cordoba.md)
|
||||
Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes.
|
||||
|
||||
- [tauf.md](./tauf.md)
|
||||
CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues.
|
||||
|
||||
## Usage
|
||||
|
||||
When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:
|
||||
|
||||
40
vault/04-people/tauf.md
Normal file
40
vault/04-people/tauf.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: CI and Jenkins support
|
||||
status: active
|
||||
teams: [ci-cd, ios-frameworks]
|
||||
topics: [jenkins, pipelines, podspec-publication, release-support]
|
||||
related: [consumer-integration, pdiap-15765]
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Tauf
|
||||
|
||||
## Role
|
||||
|
||||
- CI / Jenkins support contact who helps unblock pipeline and publication issues.
|
||||
|
||||
---
|
||||
|
||||
## Collaboration Pattern
|
||||
|
||||
- David reaches out to Tauf when Jenkins or release-pipeline steps need support, especially around XFlowViewMaker publication or approval/pipeline follow-through.
|
||||
- Tauf has been specifically relevant to the `PDIAP-15765` propagation work because David planned to ping him about the remaining XFlowViewMaker approval path.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Useful contact for operational release and pipeline troubleshooting.
|
||||
- David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `vault/03-context/workstreams/consumer-integration.md`
|
||||
- `vault/02-work-items/pdiap-15765.md`
|
||||
@@ -26,3 +26,16 @@ tags:
|
||||
- Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`.
|
||||
- Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting.
|
||||
- David updated the standup wording with those changes and sent the final version.
|
||||
|
||||
## Learning Session - Release Propagation
|
||||
|
||||
- David clarified the current release propagation chain for XFlow changes.
|
||||
- XFlowSDK is released from `pr100660-xflow-for-ios` through Jenkins pipeline `xflow-for-ios-publish`, which builds the XCFramework, publishes it to `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
|
||||
- XFlowViewMaker lives in `PR100660-ios-frameworks/Adapters/XFlowViewMaker`; after an XFlowSDK release, its podspec must be updated, then `tuist generate -n`, `pod install`, PR review, protected-branch/code-owner approval, merge, and `publish-XFlowViewMaker` publication are required.
|
||||
- The XFlowViewMaker publish pipeline usually auto-detects the next release and commonly auto-increments the minor version.
|
||||
- Fid4 then consumes the new XFlowViewMaker version from `ap010981-ios-flagship-app` by updating the Podfile, running `tuist generate -n` and `pod install --repo-update`, opening a PR, and merging it before the downstream app release process carries the change to users.
|
||||
- This release chain is durable context for understanding why an XFlowSDK fix can be merged and released but still not be visible yet in Fid4.
|
||||
- David clarified that Fid4 consumes XFlow only through XFlowViewMaker, not directly through XFlowSDK.
|
||||
- David also clarified that other frameworks such as `FTAccountOpen` and `FTTransfer` use XFlowViewMaker, and the practical Account Opening path is currently understood to go through `FTAccountOpen`.
|
||||
- Version verification in Fid4 is imperfect because `Podfile.lock` is ignored in the repo; fixed Podfile references and pipeline artifacts can help verify released versions, but podspec-repo edits can still change what gets resolved later.
|
||||
- Tauf was identified as a CI/Jenkins support contact who has helped with pipeline issues in the past.
|
||||
|
||||
Reference in New Issue
Block a user