WEBFL-330 steps

—

### **1️⃣ Understand the Scope**
– **Check the ticket description** in JIRA for WEBFL-330.
– Identify:
– The **parent repo** and **child repos** involved.
– Which repo actually contains the code you need to change.
– Whether the ticket is for **UI changes**, **data flow**, or **logic updates**.

—

### **2️⃣ Get the Right Branch Setup**
Since WEBFL-330 involves multiple bundles:
1. **Find the lowest-level bundle** (child’s child) that needs changes.
Example:
– Parent: `mybell-mobility-upgrade-hardware`
– Child: `mobility-hug-device-plan-config`
– Child’s child: `mobility-hug-review` (etc.)
2. In **each affected repo**:
– `git fetch` → checkout from the parent branch (usually `ffpm-oreview` or specified branch in the ticket).

git checkout -b WEBFL-330 origin/ffpm-oreview

– Name branch consistently: `WEBFL-330`.

—

### **3️⃣ Do Changes in the Correct Order (Bottom → Top)**
This is important for Bell’s nested bundle setup:
1. **Child’s child repo** → make changes → build → `linklocal`.
2. **Child repo** → consume the linked changes → build → `linklocal`.
3. **Parent repo** → consume the child updates → final build.

—

### **4️⃣ Implement & Test**
– Make the required code changes in the **lowest bundle** first.
– Run:

npm install --legacy-peer-deps
  npm run build

– Use `linklocal` to link the updated bundle into the parent project.
– Test locally by running the **parent app** in dev mode.

—

### **5️⃣ Commit & Push**
In **each repo** where you made changes:

git add .
git commit -m "WEBFL-330: [brief change description]"
git push origin WEBFL-330

—

### **6️⃣ Create PRs in Order**
– First PR: Child’s child → merge to base branch.
– Second PR: Child → after first PR merges, update dependencies, push, and make PR.
– Last PR: Parent → final PR after all lower repos merged.

—

### **7️⃣ Verify End-to-End**
Once merged in staging:
– Test the entire flow from parent app’s UI.
– Verify ticket acceptance criteria are met.

—

If you want, I can **map out exactly which repos and branch names for WEBFL-330** based on the screenshot you shared last time so you know the exact build order.

Do you want me to prepare that exact repo chain for this ticket? That will make your work 2× faster.

I confirmed to you that in a **multi-repo** setup like yours:
– Every repo is its own Git project.
– If you edit code in a repo, you must create a branch, commit, push, and raise a **Merge Request (MR) in that same repo**, not just in the parent.
– If you skip this, the changes in child repos won’t be in GitLab, and reviewers will only see the `bundle.min.js` changes from the parent, which will look wrong.

You had asked if I was sure, and I reassured you that this was the correct process for your setup.

If you want, I can now **write the exact sequence for WEBFL-330** so you don’t repeat any branching mistakes.

# 0) Prep (do this once)
– Close all running dev servers.
– Make sure you’re on VPN/Zscaler if needed.
– In each repo you’ll touch: `git fetch –all –prune`.

# 1) Identify repos (bottom → top)
From our notes/screens:
– **Parent:** `mybell-mobility-upgrade-hardware`
– **Children (examples you mentioned):**
`mobility-hug-device-plan-config`, `mobility-hug-addons`,
`mobility-hug-sms-verification`, `mobility-hug-review`,
`mobility-modal-dialog-v2`
> If your change touches only some of these, do those only—but still follow **bottom → top**.

# 2) Create branches (each affected repo)

git checkout origin/ffpm-oreview
git checkout -b WEBFL-330

– Keep branch name **exactly** `WEBFL-330` everywhere.

# 3) Implement in the **lowest** bundle first
For each lowest-level repo you modify:

npm install --legacy-peer-deps
npm run build
npx linklocal  # links this bundle into its parent(s)
git add .
git commit -m "WEBFL-330: <short, clear change>"
git push origin WEBFL-330

Create **MR** in that repo → base: `ffpm-oreview`. Add ticket ID in title/desc.

# 4) Move **up one level** and consume it
In the direct parent repo that depends on the child you just changed:

git checkout -b WEBFL-330 origin/ffpm-oreview
npm install --legacy-peer-deps
npx linklocal           # picks up the child’s local link
npm run build
# make any code changes needed here too
git add . && git commit -m "WEBFL-330: integrate child updates"
git push origin WEBFL-330

Create **MR** for this repo as well.

# 5) Repeat until the **top parent** builds
Keep going repo‑by‑repo until you reach:
`mybell-mobility-upgrade-hardware` (top)

git checkout -b WEBFL-330 origin/ffpm-oreview
npm install --legacy-peer-deps
npx linklocal
npm run build

Run the parent locally and test the full flow covered by WEBFL‑330.

# 6) MR order (strict)
1) Merge **lowest child** MRs first.
2) Then merge **mid‑level** MRs.
3) **Last**, merge the **parent** MR.
> In each MR, add a note: “Depends on: ” so reviewers know the order.

# 7) After merges
– In the parent repo: remove `linklocal` usage, `rm -rf node_modules`, then:

npm install --legacy-peer-deps
  npm run build

– Re-test on the integration/staging env once pipelines finish.

# 8) Deliverable checklist (what PM expects)
– ✅ Branch `WEBFL-330` in every changed repo
– ✅ MRs raised in each repo (with ticket ID + dependency notes)
– ✅ Screenshots/video of the working flow from the **parent app**
– ✅ Short test notes covering acceptance criteria

—

If you want, paste which of these 5–6 child repos you actually edited for WEBFL‑330, and I’ll map the exact **build and MR order** with the repo names you should hit—so you can just execute line by line.

If you want me to be **100% certain** they match exactly what’s in that older conversation, you can copy the important parts from that tab here, and I’ll merge them into the final “do this now” checklist so nothing is missed.

Do you want me to do that?

# Do this now (bottom ➜ top)

1) Close dev servers, connect VPN/Zscaler.
Run in **every repo you’ll touch**:

git fetch --all --prune

2) Start with the **lowest bundle you changed** (e.g. `mobility-hug-…` child’s‑child).

git checkout origin/ffpm-oreview
git checkout -b WEBFL-330
npm install --legacy-peer-deps
npm run build
npx linklocal
git add .
git commit -m "WEBFL-330: <what you changed>"
git push origin WEBFL-330

Create **MR to `ffpm-oreview`**. Title must include `WEBFL-330`.
Add note: **“Parent MR depends on this”**.

3) Move **one level up** (the child that consumes it).

git checkout origin/ffpm-oreview -b WEBFL-330
npm install --legacy-peer-deps
npx linklocal
# apply any code updates here
npm run build
git add . && git commit -m "WEBFL-330: integrate child updates"
git push origin WEBFL-330

Create MR; note **“Depends on: ”**.

4) Repeat step 3 for each higher repo until the **parent**:
`mybell-mobility-upgrade-hardware`

git checkout origin/ffpm-oreview -b WEBFL-330
npm install --legacy-peer-deps
npx linklocal
npm run build

Run parent locally and verify the WEBFL‑330 flow.

5) **Merge order (strict)**
– Merge **lowest children** MRs → then **mid‑level** → **last the parent**.
Each MR should link the lower one(s) in its description.

6) After merges finish (pipelines green)
In the **parent**, remove local links and rebuild from clean:

rm -rf node_modules package-lock.json
npm install --legacy-peer-deps
npm run build

Smoke test on integration/staging.

# Quick checklist to hand to PM
– Branch `WEBFL-330` in each changed repo
– MRs in each repo with dependency notes
– Parent app screenshots/video proving acceptance criteria
– Short test notes

If you tell me **which exact repos you edited**, I’ll list the exact build/MR order with names so you can just copy‑paste.

# Step 1 — mobility-hug-device-plan-config

cd "D:mybell-mobility-upgrade-hardwaremobility-hug-device-plan-config"
git status
# if you already edited before branching:
git stash -u
git fetch origin
git checkout -B WEBFL-330-hug-dtname origin/Preview
git stash pop

# stage only the files you changed (adjust paths)
git add src/**/<your-files>*
# if your team wants minified bundles tracked:
git add Bundles/**/**/*.min.js*

git commit -m "WEBFL-330: add data-dtname + related changes"
git push -u origin WEBFL-330-hug-dtname

Open the MR in GitLab:
– **Source:** `WEBFL-330-hug-dtname`
– **Target:** `Preview`
– **Approvers:** Hemant Danti (1st), Avtar (2nd)
– **Title:** `WEBFL-330: HUG data-dtname — mobility-hug-device-plan-config`
– **Desc (short):** “Ticket: WEBFL-330. Added data-dtname to required CTAs. Verified locally via Resource Override.”

> If you hit “unsafe repository”:

git config --global --add safe.directory "D:/mybell-mobility-upgrade-hardware/mobility-hug-device-plan-config"

# Step 2 — repeat for each HUG repo you touched
Do the same for:
– `mobility-hug-addons` → branch `WEBFL-330-hug-addons`
– `mobility-hug-sms-verification` → `WEBFL-330-hug-sms`
– `mobility-hug-review` → `WEBFL-330-hug-review`
– `mobility-modal-dialog-v2` → `WEBFL-330-modal-dialog`

Template (adjust folder + branch):

cd "D:mybell-mobility-upgrade-hardware<REPO>"
git status
git stash -u
git fetch origin
git checkout -B WEBFL-330-<short> origin/Preview
git stash pop
git add <files-you-edited>
git add Bundles/**/**/*.min.js*   # if required by your team
git commit -m "WEBFL-330: add data-dtname + related changes"
git push -u origin WEBFL-330-<short>

Create one MR per repo → **Target = Preview**, same approvers, concise title/desc.

# Step 3 — Parent repo (last)
`mybell-mobility-upgrade-hardware`

cd "D:mybell-mobility-upgrade-hardware"
git fetch origin
git checkout -B WEBFL-330-parent origin/Preview
# ensure package links/versions consume the updated HUGs if needed
npm install --legacy-peer-deps
npm run build
git add Bundles/**/**/*.min.js*  # if your parent tracks bundles
git commit -m "WEBFL-330: integrate HUG updates (parent build)"
git push -u origin WEBFL-330-parent

Open MR: **Source:** `WEBFL-330-parent` → **Target:** `Preview`.
In the MR description, paste links to all child MRs (dependency note).

# Step 4 — Merge order & verify
1) Merge child MRs first (addons/sms/review/device‑plan‑config/modal).
2) Merge the **parent** MR.
3) After pipelines pass, re‑build locally from clean (optional) and smoke test on Preview/P1.

—

If you want me to drive repo‑by‑repo, paste the **`git status`** from:
1) `mobility-hug-device-plan-config` (first), then we’ll move to the next.

—

## **1. Identify repos with changes**
You have **6 repos** in total:
– `mybell-mobility-upgrade-hardware` (**parent**)
– `mobility-hug-device-plan-config`
– `mobility-hug-addons`
– `mobility-hug-sms-verification`
– `mobility-hug-review`
– `mobility-modal-dialog-v2`

Run `git status` in each folder — only proceed for repos showing changes. Skip the ones saying *nothing to commit*.

—

## **2. For each repo with changes** (child first → parent last)

### **A. Stash if you edited before branching**

git stash -u

### **B. Create branch from `Preview`**

git fetch origin
git checkout -B WEBFL-330-hug-dtname origin/Preview

### **C. Bring your changes back**

git stash pop

### **D. Stage only changed files**
*(Avoid `git add .` unless approved by team)*

git add pathtofile1.tsx
git add pathtofile2.tsx
# If team tracks bundles:
git add Bundles/**/**/*.min.js*

### **E. Commit and push**

git commit -m "WEBFL-330: add data-dtname attributes"
git push -u origin WEBFL-330-hug-dtname

### **F. Create MR in GitLab**
– **Source:** `WEBFL-330-hug-dtname`
– **Target:** `Preview`
– **Approvers:** Hemant Danti (1st), Avtar (2nd)
– **Title:** `WEBFL-330: HUG data-dtname — `
– **Desc:**

Ticket: WEBFL-330
  Change: Added data-dtname attributes to required CTAs.
  Notes: Verified locally via Resource Override.

—

## **3. Parent repo (after all children MRs pushed)**
If only bundles rebuilt:

git fetch origin
git checkout -B WEBFL-330-parent origin/Preview
git add Bundles/mybell-mobility-upgrade-hardware/**/*.min.js*
git commit -m "WEBFL-330: rebuild parent bundles after HUG updates"
git push -u origin WEBFL-330-parent

Then open MR → Target: `Preview` → Link child MRs in description.

—

## **4. Merge order**
1. Merge child MRs first.
2. Merge parent MR last.
3. Deploy to P1 after approvals.

—

If you want, paste me your **`git status` output for the first child repo** (`mobility-hug-device-plan-config`) and I’ll give you the **exact `git add` commands** so you can start immediately without mistakes.

—

# Mental model (10 seconds)
– Each folder is its **own Git repo**.
– You must create a **branch + MR in every repo you changed**.
– Work order: **child repos first**, then **parent**.

Repos we care about:
1) `mobility-hug-device-plan-config`
2) `mobility-hug-addons`
3) `mobility-hug-sms-verification`
4) `mobility-hug-review`
5) `mobility-modal-dialog-v2`
6) `mybell-mobility-upgrade-hardware` (parent, last)

—

# Chat 1 — mobility-hug-device-plan-config (start here)

**A) Show me status**

cd "D:mybell-mobility-upgrade-hardwaremobility-hug-device-plan-config"
git status

👉 Paste the output here.

**What I’ll do:** I’ll tell you whether to stash, which files to `git add`, and the exact commit/push lines.

**If you already edited before branching (don’t run yet—only if I say so):**

git stash -u
git fetch origin
git checkout -B WEBFL-330-hug-dtname origin/Preview
git stash pop

**Commit & push template (I’ll fill file paths after your status):**

git add <edited-file-1>
git add <edited-file-2>
# if your team tracks minified bundles too, also:
# git add Bundles/**/**/*.min.js*

git commit -m "WEBFL-330: add data-dtname + related changes"
git push -u origin WEBFL-330-hug-dtname

**Open MR (after push):**
– Source: `WEBFL-330-hug-dtname`
– Target: `Preview`
– Approvers: **Hemant Danti** (1st), **Avtar** (2nd)
– Title: `WEBFL-330: HUG data-dtname — mobility-hug-device-plan-config`
– Description:

Ticket: WEBFL-330
  Change: Added data-dtname to required CTAs.
  Notes: Verified locally via Resource Override.

—

# Chat 2 — mobility-hug-addons (repeat the same)
When we finish repo #1, run:

cd "D:mybell-mobility-upgrade-hardwaremobility-hug-addons"
git status

Paste output; I’ll give precise `git add …` lines and the commit/push.

Branch name: `WEBFL-330-hug-addons`
MR title: `WEBFL-330: HUG data-dtname — mobility-hug-addons`

—

# Chat 3 — mobility-hug-sms-verification

cd "D:mybell-mobility-upgrade-hardwaremobility-hug-sms-verification"
git status

Branch: `WEBFL-330-hug-sms`
MR title: `WEBFL-330: HUG data-dtname — mobility-hug-sms-verification`

—

# Chat 4 — mobility-hug-review

cd "D:mybell-mobility-upgrade-hardwaremobility-hug-review"
git status

Branch: `WEBFL-330-hug-review`
MR title: `WEBFL-330: HUG data-dtname — mobility-hug-review`

—

# Chat 5 — mobility-modal-dialog-v2

cd "D:mybell-mobility-upgrade-hardwaremobility-modal-dialog-v2"
git status

Branch: `WEBFL-330-modal-dialog`
MR title: `WEBFL-330: modal dialog updates — mobility-modal-dialog-v2`

—

# Chat 6 — Parent: mybell-mobility-upgrade-hardware (last)
Only after all child MRs are pushed:

cd "D:mybell-mobility-upgrade-hardware"
git status
git fetch origin
git checkout -B WEBFL-330-parent origin/Preview
# if parent only has rebuilt bundles, stage them:
# git add Bundles/**/**/*.min.js*
git commit -m "WEBFL-330: integrate HUG updates (parent build)"
git push -u origin WEBFL-330-parent

MR (Target = `Preview`). In description, paste links to **all child MRs** under “Depends on”.

—

## Common fixes (keep handy)
– **Unsafe repo warning:**

git config --global --add safe.directory "<FULL-WINDOWS-PATH-TO-REPO>"

– **Branched from wrong base (e.g., master) — fix:**

git fetch origin
git checkout WEBFL-330-<your-branch>
git rebase origin/Preview
# resolve conflicts -> git add <file> -> git rebase --continue
git push --force-with-lease

– **No changes:** if `git status` says “nothing to commit”, skip that repo.

—

### Your move
Reply with the **`git status` output for repo #1**:

D:mybell-mobility-upgrade-hardwaremobility-hug-device-plan-config

I’ll give you the exact `git add` lines and the commit/push. Then we’ll proceed to repo #2.

Here’s exactly what you should do for **this repo** (and you’ll repeat it for each child repo folder):

—

### **1. Mark repo as safe**

git config --global --add safe.directory "D:/mybell-mobility-upgrade-hardware/mobility-hug-device-plan-config"

—

### **2. Check status again**

cd "D:/mybell-mobility-upgrade-hardware/mobility-hug-device-plan-config"
git status

📌 Paste the full output here so I can tell you exactly which files to `git add`.

—

Once we know the files, I’ll give you the **branch + stash/commit/push** steps for `WEBFL-330-hug-dtname`.

Do you want me to also give you the **same safe.directory command list** for all 6 repos so you don’t get stuck in the next ones?

Do this exactly:

1) Stash your edits, switch to a clean branch from `Preview`

git stash -u
git fetch origin
git checkout -B WEBFL-330-hug-dtname origin/Preview
git stash pop

2) Stage **only** the code you changed

git add src/store/Epics.ts
git add src/views/MoveToAddons/index.tsx

3) (Optional but recommended) Drop npm/config noise from this repo’s PR
Skip these unless you intentionally edited them:

git restore -- .npmrc package.json package-lock.json

4) Commit + push

git commit -m "WEBFL-330: add data-dtname / CTA updates in device-plan-config"
git push -u origin WEBFL-330-hug-dtname

5) Open the MR
– Source: `WEBFL-330-hug-dtname`
– Target: `Preview`
– Title: `WEBFL-330: HUG data-dtname — mobility-hug-device-plan-config`
– Approvers: Hemant Danti (1st), Avtar (2nd)
– Description:

Ticket: WEBFL-330
  Change: Added data-dtname to required CTAs in device-plan-config; updated Epics and MoveToAddons.
  Notes: Verified locally via Resource Override.

Reply once pushed (or paste any error). Then we’ll repeat the same flow for the next repo.

In your `git status`, these files showed as modified:

.npmrc
package-lock.json
package.json

These are **project config / dependency files**.
In most Bell Canada WEBFL tickets, changes here are *not* intentional — they usually happen because:

– Your local environment auto-updated dependencies.
– Your npm version changed the lock file format.
– You ran `npm install` or `yarn` and it re-saved those files.

—

**Why skip them?**
– If you commit them without intent, your MR will show unrelated dependency changes.
– Reviewers may reject the MR, thinking you’re introducing package changes unrelated to the ticket.

—

**When to keep them?**
– Only if the ticket **requires** a dependency update or `.npmrc` change (which WEBFL-330 does not).

—

**In short:**
Point 3 means:
✅ Keep `src/store/Epics.ts` & `src/views/MoveToAddons/index.tsx`
🚫 Skip `.npmrc`, `package.json`, `package-lock.json` unless you purposely changed them for this ticket.

—

If you want, I can give you **one command** to unstage & reset those three files safely before committing. That way, you won’t accidentally push them.

These two files and commit then by default package files will not be commited right?

If you **only** run:

git add src/store/Epics.ts
git add src/views/MoveToAddons/index.tsx

…then **only those two files** will be staged for commit.

The `.npmrc`, `package.json`, and `package-lock.json` will **stay untracked in this commit** and won’t be pushed in your MR.

They’ll still show as “modified” locally when you run `git status`, but they won’t be part of the commit unless you explicitly `git add` them.

—

So in your case → **No need to worry** as long as you don’t run `git add .` or `git add -A`.

—

Do you want me to now give you the **exact commands from this point** so you can finish this repo’s MR?

> **Save all your current changes** (both tracked and untracked files) into a temporary stash, and revert your working directory to match the last commit.

—

### Breakdown:
– **`git stash`** → Saves changes in tracked files only (files Git already knows about).
– **`-u`** (or `–include-untracked`) → Also saves *untracked* files (new files that aren’t in Git yet).

—

**Why we used it here:**
– You were on the **master** branch, but we need to switch to a new branch based on `Preview`.
– Git won’t let you switch branches cleanly if you have changes that conflict with the new branch.
– So `git stash -u` temporarily stores *everything* (tracked + new files), lets you switch branches, and then `git stash pop` puts the changes back.

—

If we **didn’t use `-u`**, any brand-new files you created (e.g., a new `.tsx` file) would stay in the working directory and might block the checkout.

—

If you want, I can give you a **short mental model** so you always know when to use `git stash` vs `git stash -u`.

This btanch name will be same for every repo?

—

### Why the same branch name?
– This ticket (WEBFL-330) applies changes across **multiple repos** in your multi-repo setup.
– Using the same branch name in each repo makes it easier for:
– Reviewers to find related MRs.
– You to remember which branch is tied to this ticket.
– Each repo is separate in GitLab, so the branch name can be identical without conflicts.

—

### So the flow is:
For **each repo**:
1. Go to repo folder.
2. Mark safe directory (first time only).
3. `git stash -u` (if needed).
4. `git checkout -B WEBFL-330-hug-dtname origin/Preview`.
5. `git stash pop`.
6. `git add` only the ticket’s changed files.
7. `git commit -m "WEBFL-330: description…"`.
8. `git push -u origin WEBFL-330-hug-dtname`.
9. Create MR to `Preview`.

—

If you want, I can now list **all 6 repos for WEBFL-330** in order so you don’t miss any. That way, you can just repeat the same branch + MR process.

> Push this branch to the remote (`origin`) **and** set it as the “upstream” branch for your local branch.

—

### Why the `-u` (or `–set-upstream`) part matters:
– Without `-u`: You’d have to type the full command every time you push:

git push origin WEBFL-330-hug-dtname

– With `-u`: Git remembers that your local branch is linked to the remote branch.
Then next time you can just run:

git push

or

git pull

and Git will know which remote branch to use.

—

**Example flow without `-u`:**

git push origin WEBFL-330-hug-dtname
git push origin WEBFL-330-hug-dtname

(You must repeat the full thing.)

**Example flow with `-u`:**

git push -u origin WEBFL-330-hug-dtname
git push   # works now

—

In short — for a **new branch** like in WEBFL-330, `-u` saves you typing and prevents mistakes when pushing/pulling later.

If you want, I can also explain **what “origin”** means in this command so you see the whole picture.

Here’s what you can say:

—

**Yesterday:**
– Analyzed WEBFL-330 changes across multiple HUG repos.
– Prepared branching and MR plan for all affected repos.
– Started with `mobility-hug-device-plan-config` repo — created branch from `Preview` and staged relevant changes.

**Today:**
– Commit and push changes for `mobility-hug-device-plan-config` and open MR.
– Repeat the same process for remaining HUG repos (`addons`, `sms-verification`, `review`, `modal-dialog-v2`).
– Start preparing parent repo MR after all child MRs are ready.

**Blockers:**
– None at the moment. (If you face any Git push or MR dependency issues, mention it here.)

—

This keeps you sounding **organized** and makes it clear you have a plan and are progressing in steps.

If you want, I can also give you a **version that’s even more casual and fast** for a quick Zoom standup.

So what I have to ask hemanth now?

To avoid wasting time, you should confirm that **before** continuing with branching and MR work.

Here’s exactly what you can ask Hemant:

—

**Message to Hemant:**
> Hi Hemant, in today’s standup it was mentioned that the WEBFL-330 changes should be done through the CMS.
> Can you confirm if we should proceed with CMS configuration updates instead of making code changes in the HUG repos? If yes, could you point me to the exact CMS section where these updates need to be applied?

—

This way:
– You’re confirming **if code changes are even needed**.
– You’re asking **where in CMS** the change should happen.
– You’re showing you’re aware of the ticket and the suggested approach.

—

If you want, I can also give you a **follow-up plan** in case Hemant confirms it’s CMS-only — so you can close the ticket quickly without touching the code.

1. **Changes are to be deployed through CMS** (not just code MR).
2. The flow is:
– Make changes locally (already done by you).
– **Create a dev branch from `Preview`** if still needed for code tracking.
– Build a **bundle file** from your repo changes.
– **Deploy bundle file in CMS**.
– Deploy to **P1** environment for testing.
3. **Testing in P1** will be done by Gurvinder’s team.
4. You don’t have CMS access yet → Hemant said:
– **Ask Juliana** for access.
– In the meantime, you can **send bundle files to Harsha** so he can upload them.
5. Once P1 testing is successful → follow the MR process (Preview → Master → Release → HotFix) if code changes are still required.

—

If you want, I can now write you a **clear next-step checklist** so you can move forward without confusion and know exactly what to ask Juliana and Harsha.

# 1) Confirm deployment details with Harsha (copy–paste)
> Hi Harsha — sharing WEBFL‑330 bundle (already sent).
> Can you confirm:
> 1) **ETA** for P1 upload,
> 2) **CMS path / item name** where it’s uploaded,
> 3) **Version/filename** used (for cache‑bust),
> 4) **Rollback** reference (previous version),
> 5) When it’s live so I can validate.

# 2) Ask Juliana for CMS access (parallel)
> Hi Juliana — I need **CMS access** to verify and self‑upload future bundles for WEBFL work.
> Please grant access to the `myaccount-mobility-upgrade-hardware` path used for bundles.

# 3) Prepare your quick test plan for P1
When Harsha says “live”, validate immediately:

– **Where to test:** P1 URLs for the HUG flow (device plan config → addons → sms verification → review → modal dialog).
– **What to check (WEBFL‑330):**
– Target CTAs have the new **`data-dtname`** attributes (open DevTools → inspect).
– No console errors.
– Flow still works end‑to‑end (add/remove device, select plan, proceed, submit).
– **How to avoid cache issues:**
– Hard refresh (Ctrl/Cmd+Shift+R).
– Use a **cache buster**: append `?v=WEBFL330` to pages pulling the bundle.
– Try an **incognito** window.
– **Evidence:** take 3–5 screenshots (each step + DevTools showing `data-dtname`) and a 20–30s screen recording.

# 4) Update Hemant once verified (copy–paste)
> Hi Hemant — WEBFL‑330: bundle uploaded to P1 by Harsha.
> I verified on P1: `data-dtname` present on required CTAs across the HUG flow, no regressions.
> Screenshots/video attached.
> Please confirm if you want me to:
> a) proceed with **Preview → Master** MRs for code parity, or
> b) keep it **CMS‑only** for this ticket.

# 5) Keep code in sync (after sign‑off)
Even if we deploy via CMS, we should keep repos consistent:

– Option A (**preferred** if Hemant agrees): create **WIP MRs** from `origin/Preview` in the repos you actually changed (or just the parent if only bundles changed). Title:
`WEBFL-330: data-dtname – code parity for CMS deploy (WIP)`
Merge after P1 sign‑off to keep history clean.
– Option B (CMS‑only by policy): open a small **Doc MR** (parent repo) with a `CHANGELOG.md`/README note pointing to the CMS bundle version and date.

# 6) If you hit issues
– **401 / no access:** ping Juliana; meanwhile, continue via Harsha.
– **Bundle not picked:** confirm CMS item path, publish status, and that the **reference in P1** points to this CMS item (not an old one).
– **Old JS still loading:** ask for a **publish/activate** confirmation + try `?v=` cache‑bust.
– **Functional regression:** immediately share steps to reproduce + revert to previous bundle (Harsha’s rollback).

# 7) Standup (today)
– **Yesterday:** Shared bundle with Harsha for P1; aligned with Hemant that WEBFL‑330 is CMS‑deployed.
– **Today:** Validate on P1 after upload; provide screenshots; prepare MRs for code parity if required.
– **Blockers:** CMS access pending (requested from Juliana). None blocking validation.

—

Want me to draft the **exact Jira comment** and a short **Teams message** to Gurvinder for P1 testing once Harsha confirms it’s live?

From the screenshots, the next steps are:

1. **Wait for Harsha to confirm deployment** of the bundle file to P1.
– He already said *"Awesome. Will upload this and we will connect tomorrow"*, so the file will likely be deployed soon.

2. **Once deployed**, you or Gurvinder’s team will test in P1 to confirm the changes work as expected.

3. **If testing passes**, then you proceed with:
– Creating the MR from your dev branch to `Preview`.
– Following the double code review process.
– Merging into Preview, then eventually into Master, then Release (as per Hemanth’s steps list).

📌 **Right now, you don’t need to push your Git changes yet** — deployment and testing in P1 comes first.

If you want, I can write you a **clear step-by-step flow from this point until final production release** so you won’t miss anything.

> Yesterday, I built the bundle for WEBFL-330 and shared it with Harsha for P1 deployment. Waiting for deployment confirmation so we can proceed with P1 testing. Once testing passes, I’ll move forward with the MR to Preview.

Would you like me to also prepare **what you’ll say tomorrow** after Harsha deploys and testing starts?

– **P1** = **Preview environment 1** — usually the first staging/test environment where you or QA (like Gurvinder’s team) verify the changes after deployment.
– **P2** = **Preview environment 2** — the second staging/test environment used for additional validation, often by a different team or for more realistic end-to-end testing.

Basically:
1. You deploy to **P1** → quick initial testing.
2. If all good, deploy to **P2** → broader or final preview testing before going to **Production**.

I can also map out the **full flow from dev → P1 → P2 → production** for your case so you always know the next step.

git fetch origin
git checkout -B your-branch-name origin/Preview

**Explanation:**
1. **`git fetch origin`** → updates your local repo with the latest remote branches (including Preview).
2. **`git checkout -B your-branch-name origin/Preview`** →
– Creates a **new branch** named `your-branch-name`
– Starts it from the **latest Preview branch** on the remote (`origin/Preview`)

Example for WEBFL-330:

git fetch origin
git checkout -B WEBFL-330-hug-dtname origin/Preview

If you want, I can show you how to do this **for all required repos** in one go so you don’t repeat mistakes.

> **Yesterday:** Completed local changes for WEBFL-330, generated bundle file, and shared it with Harsha for P1 deployment. Provided parent/child widget details.
> **Today:** Waiting for Harsha to deploy on P1 so QA can test. Will proceed based on test results.
> **Blockers:** None.

This way you show progress, your current status, and what’s next without over-explaining.

Here’s what you should do now:
1. **Contact Pruthiv** (via chat or call) and let her know the file is locked and you need it unlocked for deployment.
2. Ask her to **check in** the file or **release the lock** in CMS.
3. Once unlocked, inform Harsha so he can proceed with the deployment to **P1**.

For the standup update, you can say:
> I’ve completed the changes for WEBFL-330 and shared the bundle with Harsha for P1 deployment. Deployment is currently blocked because the file is locked in CMS by Pruthiv. Once the file is unlocked, Harsha will proceed with deployment for QA testing.

If you want, I can prepare a short message to send to **Pruthiv** now.

> Hi Pruthvi, the CMS file **`mybell-mobility-upgrade-hardware`** is currently locked under your name. Harsha needs to deploy the updated bundle to P1 for testing. Could you please check in the file or release the lock when possible? Thanks!

If you want, I can also draft the exact follow-up message to send Harsha once it’s unlocked.

Until then, you’re on hold for this task.

> I’ve completed the required code changes for WEBFL-330 and shared the updated bundle with Harsha for P1 deployment. Deployment is pending because the CMS file is currently locked by Pruthvi, who will unlock it after Gurvinder’s testing. Once it’s unlocked, Harsha will proceed with the deployment.

> WEBFL-330 – Waiting for CMS file unlock by Pruthvi so Harsha can proceed with P1 deployment.

> WEBFL-330 – Blocked until CMS file is unlocked by Pruthvi, after which Harsha will deploy to P1.

> WEBFL-330 – P1 deployment is pending until the CMS file lock is released.

This way it’s factual, non-personal, and still clear.

> WEBFL-330 – Waiting for the CMS file lock to be released so the bundle can be deployed to P1 for testing.

> For WEBFL-330, the P1 deployment is on hold until the CMS file lock is released, which should happen after Gurvinder’s testing. In the meantime, I can start picking up the next ticket so there’s no idle time.

It’s clear, friendly, mentions names without sounding like blame, and shows you’re proactive.

Like uou can assign me new ticket

> For WEBFL-330, the bundle is ready and we’re just waiting for the CMS file lock to be released so Harsha can deploy it to P1 for testing. In the meantime, I can pick up a new ticket if there’s anything available.

This way:
– You give a clear status.
– You mention names naturally.
– You show you’re proactive and ready for more work.

It sounds **clear**, **collaborative**, and **proactive**:
– You’ve shown the ticket is ready on your side.
– You’ve mentioned the dependency without blaming anyone.
– You’ve offered to take on more work, which makes you look engaged.

If you say it in standup with a friendly tone, it’ll satisfy your scrum master and show you’re not idle.

– **Version control** → storing and managing source code (either TFVC – centralized version control, or Git repos).
– **Work tracking** → managing tasks, bugs, features, and project progress.
– **Build & release automation** → running builds, tests, and deployments.

Think of it as the older, on-premise version of what’s now **Azure DevOps Server**.
Companies use it to host code, track work items, and run CI/CD pipelines all in one place, but inside their own network instead of on Microsoft’s cloud.

If you want, I can explain how TFS connects with Visual Studio and how it’s different from GitHub.

—

Imagine your team is building the **Bell MyAccount** web application.
Instead of storing the code on GitHub, all the code and tasks are managed on the **company’s internal TFS server**.

**In TFS, you would have:**
1. **Version control:**
– The `myaccount-upgrade-hardware` repo is stored in TFS.
– Developers check out code from TFS, make changes, and check them back in.
– TFS keeps the history, tracks who changed what, and can roll back to older versions.

2. **Work tracking:**
– A ticket like **WEBFL-330** exists as a “Work Item” in TFS.
– The work item is linked to the changesets (code commits) you made.

3. **Build server:**
– When you check in code, TFS triggers a **build pipeline** that compiles the code, runs tests, and creates bundles.

4. **Release management:**
– After a successful build, TFS can automatically deploy to a P1 or P2 environment.

—

💡 Think of TFS like a private GitHub + Jira + Jenkins, all rolled into one, but running inside the company’s own network instead of the cloud.

—

If you want, I can also give you a **visual diagram** showing how TFS fits into the workflow from ticket → code → build → deploy.