PSI Knowledge Base

Deploy FAQ — Desktop App Publishing

12 min readEdit this page

Deploy FAQ — Desktop App Publishing

Quick answers for common questions about publishing PSI desktop apps through the CI/CD pipeline.

Getting Started

How do I deploy my app?

  1. For betas: open Pro Update Beta Management (gear icon) and confirm the Beta Access list for your app is set correctly. This is a prerequisite, not optional — see Always assign beta users first below for why.
  2. Go to Actions on PSI.All GitHub
  3. Click “Release: Deploy App” in the left sidebar
  4. Click “Run workflow”
  5. Select your app, pick a release channel, enter release notes
  6. Click “Run workflow”

The pipeline then builds, deploys, and notifies automatically.

What are the release channels?

ChannelWho gets itWhen to use
alphaOnly you / alpha testersEarly dev testing, experiments
betaNamed testers onlyStructured testing before production
minorAll usersProduction release (small version bump)
majorAll usersProduction release (bigger version bump)

Does my code need to be merged to main first?

Yes. The release workflow builds from the main branch. Merge your PR first, then deploy.

My app isn’t in the dropdown. What do I do?

Your app needs to be onboarded to the CI/CD system. See Onboard a New App for the setup steps, or ask the team for help.

Beta Testing

⚠ Always assign beta users in Pro Update Beta Management before pushing a beta

The Pro Update Admin Panel is the single source of truth for who tests betas. Pre-assign your testers there before kicking off the release workflow — don’t rely on the workflow’s “Beta users” override field for your real testing list.

Why this matters:

  • The workflow reads betaAccess from the registry to populate the Teams group chat. If the list is empty when the deploy fires, the chat is created with only you in it (or fails outright). Adding testers afterward does not retroactively add them to the chat (Teams chat membership doesn’t auto-sync).
  • The 7-day stale-beta reminder reads from the registry too. Empty list = no reminder = beta sits forgotten.
  • The list persists across /promote — same testers usually validate the next iteration, so the registry stays as your saved tester roster. Override at the workflow level breaks that continuity.
  • Apps with a deployed beta but no testers show an ⚠ no testers assigned warning in Beta Management — the panel actively flags the misconfiguration so you can spot it.

Workflow override field is for emergencies only — e.g., one-off deploys to a different tester for a specific scenario. Don’t use it as your regular flow.

How do I set up beta testers?

Use the Pro Update Admin Panel — this is the standard step before every beta:

  1. Open Pro Update normally
  2. Click the gear icon (top-right) — it appears automatically if you’re a developer
  3. Find your app, edit the Beta Access column
  4. Enter AD usernames or groups (e.g., AMD,BMC,JPT)
  5. Click Save

These testers are used automatically every time you deploy a beta for that app, surface in the 7-day stale-beta reminder, and get cleared automatically when you /promote.

Each app row in the admin panel shows the current deployed versions under the app name:

  • Stable v<X> always
  • Beta v<Y> (in orange) only when a beta is actually deployed and strictly newer than stable — betaversion.txt == version.txt is the idle state and shows nothing
  • ⚠ no testers assigned (in amber) when a beta is deployed but the access list is empty — flags abandoned betas you should either assign testers to or pull

Adding testers to an app that already has an active beta? The chat was created at deploy time and doesn’t auto-sync new members. After Save, a toast at the bottom reminds you to add them to the existing Teams chat manually. (For new betas you haven’t deployed yet, this isn’t an issue — pre-assign first, deploy second, and the chat is created with everyone in it.)

Workflow “Beta users” override field: treat as emergency-only. Anything you want repeated for future deploys belongs in Beta Management, not the workflow input.

I don’t see the gear icon in Pro Update. Why?

You need to be a member of the AD\IT - RF security group — this is now the only gate for Beta Management access. (The legacy developers group fallback in app-registry.json was removed in v1.0.0.55.) The gear icon appears automatically once you’re in the group; no special launch argument is needed. If membership was added recently, sign out and back in so your token picks up the new group, then relaunch Pro Update.

If the gear is missing for everyone (not just you), the registry JSON probably failed to parse — Pro Update v1.0.0.55+ shows a yellow banner across the top of the main window with the parser error in that case.

What happens when I deploy a beta?

The pipeline automatically:

  • Bumps the version in AssemblyInfo.cs and commits the bump back to main with [skip ci]
  • Builds your app and deploys it to the network share
  • Tags the bump commit <AppName>/v<Version> and creates a prerelease GitHub Release pinned to that exact commit (so the tag → source mapping is always correct, even after you /promote)
  • Creates a GitHub tracking issue ([Beta] AppName vX.X.X.X)
  • Creates a Teams group chat with you and the testers
  • Sends a notification message with release notes and test instructions

For solo betas where you’re also the only tester, you get a DM from the bot instead of a group chat (Teams group chats need ≥2 humans).

How do testers get the beta version?

Testers run ProReset from the Start menu or open Pro Update and update the app. The Teams notification tells them exactly what to do.

What if a tester finds a bug?

  1. Fix it and merge the fix to main
  2. Re-run the beta deploy workflow for the same app
  3. The old tracking issue closes automatically and a new one is created
  4. A new Teams chat is created with the testers
  5. Testers run ProReset or Pro Update again to get the fix

You can re-deploy betas as many times as needed.

What if the beta sits too long without action?

After 7 days, an automated reminder is posted to the Teams group chat and the tracking issue.

Promoting to Production

How do I promote a beta to stable?

  1. Go to the beta tracking issue on GitHub (titled [Beta] AppName vX.X.X.X)
  2. Comment /promote
  3. The bot reacts with a rocket emoji to confirm

The pipeline then:

  • Writes betaversion.txt’s value into version.txt and deletes betaversion.txt — no rebuild, the same binaries that served beta now serve everyone
  • Flips the existing GitHub Release’s prerelease flag to false and appends a “Promoted to stable: by @” footer (the tag stays pinned to the original build commit)
  • Closes the tracking issue
  • Notifies the Teams chat

The deployment model is pointer-based: every version folder on the share is a real build, and version.txt / betaversion.txt are pointers to one of them. Promotion is a pointer flip, not a redeploy.

I commented /promote but nothing happened. What’s wrong?

Check that:

  • The issue is open (not already closed)
  • The issue has the beta-test label
  • You commented on the issue, not on a pull request
  • Your comment contains exactly /promote

Can I skip beta and ship directly to all users?

Yes. Select “minor” or “major” instead of “beta” when running the workflow. This deploys straight to version.txt — all users get it immediately.

Be careful: There’s no rollback button. If it’s broken, you have to merge a fix and deploy again. When in doubt, beta first.

What’s the difference between minor and major?

  • minor: Bumps the last version number (1.0.0.22 → 1.0.0.23)
  • major: Bumps the second-to-last number and resets the last (1.0.0.22 → 1.0.1.0)

Use major for significant feature releases. Use minor for everything else.

After Deploying

How do users get the update?

  • Run ProReset — force-updates all apps immediately
  • Open Pro Update — shows available updates, user clicks Update
  • Application Manager — detects new versions the next time it launches the app

I deployed but users say they don’t have the update. Why?

Check these things in order:

  1. Verify version.txt (or betaversion.txt for beta) was updated on the network share
  2. The user must be on the internal network — update checks skip non-PSI subnets
  3. For beta: verify the user is listed in PSApplications.txt beta column
  4. Have them run ProReset or open Pro Update to force the check

Where is the network share?

\\ad.ptihome.com\DFS\Data\APPS\Approved\DotNet\AppDeployments\

Each app has a folder under Apps\{AppName}\ with version.txt, betaversion.txt, and versioned subfolders containing the binaries.

I updated my app but old DLLs are still in the install folder. Why?

Pro Update overlay-copies new files into the existing install folder — it never deletes anything. So if a new app version drops dependencies (e.g., switches off a NuGet package, drops Telerik, replaces log4net with Event Log), the old DLLs stay in C:\Users\Public\Progressive Surface\<AppName>\ forever.

They’re inert — the new exe doesn’t reference them — but they’re cruft, and they hide a hazard: if anyone’s <probing privatePath> config or Fusion sniffing accidentally picks them up, you can get a surprise version-conflict at runtime.

Three options for handling:

  1. Do nothing. Orphaned DLLs that aren’t loaded are harmless. Lowest-risk path for most cases.
  2. Self-clean on first launch. Add an OrphanCleanup step to the new app version that lists known-orphan filenames and File.Deletes them. PSI.CredentialsManager v2 ships an example — see its Services/OrphanCleanup.cs for the pattern.
  3. Have users run ProReset. Documented friction step in the release notes: “After updating, run ProReset to clean up old files.” Use this for major version transitions (e.g. v1 → v2 with a heavy dependency overhaul).

Pro Update does not know about file removal; it’s the deploying app’s responsibility.

Where can I find diagnostic logs when an app fails to launch?

Apps following the v2 pattern write a per-day diagnostic log at %LOCALAPPDATA%\PSI\<AppName>\diag-YYYY-MM-DD.log capturing every launch step. This is independent of Event Log permissions (Event Log source creation requires admin) and survives crashes.

Older apps log to the Windows Application Event Log under provider PSI.<AppName> if registered, otherwise the generic Application source. To sweep both:

# File-based logs (v2-pattern apps):
Get-ChildItem "$env:LOCALAPPDATA\PSI" -Recurse -Filter "diag-*.log" | Sort LastWriteTime -Desc | Select -First 5
 
# Event Log fallback for older apps:
Get-WinEvent -LogName Application -MaxEvents 50 |
  Where-Object { $_.Message -match "PSI\.|Login|Credential|Updater" }

Pro Update itself logs to C:\Users\Public\Progressive Surface\Pro Update\logs\proupdate-YYYYMMDD.log and writes telemetry JSON to \\ad.ptihome.com\DFS\Data\APPS\Approved\DotNet\AppDeployments\Telemetry\YYYY-MM-DD\ for fleet observability.

Teams Notifications

Why didn’t the Teams notification send?

Check the workflow run logs — go to Actions, find your run, look at the “Send Teams notification” step. Common causes:

  • A tester’s AD username is misspelled or doesn’t exist
  • The GRAPH_* secrets expired or aren’t configured
  • The bot app registration client secret needs rotation
  • App-registration permissions changed (group chats need Chat.Create; solo betas additionally need TeamsAppInstallation.ReadWriteSelfForUser.All)

The step prints the exact POST /chats body before calling Graph, so any rejection’s full request is visible in the log. If you see the misleading error 'user@odata.bind' field is missing in the request, see the Graph chat-creation pitfalls on the Deploy ProApps page — that’s a known class of bugs around OData key ordering and @ characters in UPNs.

The Teams step uses continue-on-error — a failed notification does NOT block the deploy. Your app still ships even if the notification fails. (The other steps no longer use continue-on-error; that practice silently hid the same Teams bugs for weeks.)

Who gets added to the Teams chat?

You (the deployer) and all the beta testers. The chat is titled [Beta] AppName vX.X.X.X.

Can I send the notification again if it failed?

Not directly. But if you re-deploy the beta, a new version is bumped and a new Teams chat is created with a fresh notification. (Each beta deploy always bumps to a fresh version number — no in-place reuse — so the new chat doesn’t conflict with anything stale.)

I added a new tester to an app that already has an active beta. Are they in the chat?

No — the chat was created at deploy time with whoever was configured then. The Pro Update Admin Panel pops a toast on Save reminding you to add them manually in Teams. Or re-deploy the beta to get a fresh chat with the updated tester list.

Alpha Channel

What is alpha for?

Developer-only testing. Deploy to alpha when you want to test on a real machine before involving other people.

How is alpha different from beta?

AlphaBeta
NotificationsNoneTeams chat + tracking issue
TestersOnly alpha-access usersNamed beta testers
TrackingNoneGitHub issue + 7-day reminders
PromotionN/A (manual)/promote to ship to all users

How do I set up alpha access?

Same as beta — use the Pro Update Admin Panel, but edit the Alpha Access column instead.

Quick Reference

I want to…Do this
Deploy to beta testersFirst: Pro Update → Beta Management → confirm Beta Access list. Then: Actions → Release: Deploy App → beta
Set up permanent testersPro Update → Beta Management (gear icon) → Beta Access
Promote beta to productionComment /promote on the tracking issue
Deploy directly to all usersActions → Release: Deploy App → minor
Test on my own machine firstActions → Release: Deploy App → alpha
Re-deploy after a bug fixConfirm tester list is still right in Beta Management → run the beta workflow again (old issue auto-closes)
Check beta test statusGitHub tracking issue or Teams group chat
See build/deploy logsActions tab → click the workflow run

Last updated: April 2026 — adds version display in admin panel, orphaned-beta warning, toast reminder, pointer-based promotion model, and Graph chat-creation pitfalls.

Graph View

Backlinks