Teams Toolkit CI Pipeline for Multi-Environment App Publishing Prompt
Design a CI/CD pipeline that uses the Teams Toolkit CLI (teamsapp) to provision, deploy, validate, and publish a Teams app across dev/staging/prod environments with environment-specific manifests and zero manual portal clicks.
- Target user
- Platform engineers automating Teams app delivery in CI
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has wired the Teams Toolkit CLI into CI and promoted a Teams app from dev to prod without ever touching the Developer Portal by hand. I will provide: - The app's components (tab, bot, message extension, declarative agent): [APP COMPONENTS] - Your CI system and runner OS: [CI SYSTEM] - Your environments and how secrets/registrations differ per env: [ENVIRONMENTS AND SECRETS] - Your target: sideload-only, org app catalog, or store submission: [PUBLISH TARGET] Your job: 1. **env files** — lay out the teamsapp.yaml lifecycle (provision/deploy/publish) plus per-env .env files (.env.dev, .env.staging, .env.prod) so each environment gets its own app registration, bot id, and manifest placeholders without code changes. 2. **Service-principal auth in CI** — replace interactive login with a service principal / federated credential for the teamsapp CLI and Azure provisioning; show the exact env vars and the non-interactive auth call. 3. **Validate before deploy** — run `teamsapp validate` (manifest schema + capability checks) and fail the pipeline on errors; treat validation as a required gate, not advisory. 4. **Promote, do not rebuild** — provision and deploy per env, but build the app package once and pass the SAME artifact forward, swapping only the env-specific manifest values so prod ships what staging tested. 5. **Publish step** — for org catalog, call the publish lifecycle to push to the app catalog and handle the admin-approval state; document where a human approval gate is unavoidable. 6. **Rollback** — keep the previous app package versioned so you can re-publish the last-good manifest if a release regresses. Output as: (a) the teamsapp.yaml lifecycle skeleton, (b) the per-env .env layout, (c) the CI pipeline stages with the non-interactive auth and validate gates, (d) the promote-not-rebuild artifact flow, (e) the publish + rollback steps. Bias toward: one built artifact promoted across envs, validation as a hard gate, and service-principal auth over interactive login.
Why this prompt works
The Teams Toolkit is usually shown as a VS Code experience: click provision, click deploy, click publish. That is fine for a demo and useless for a team that needs reproducible releases. This prompt reframes the toolkit around its CLI (teamsapp) and the teamsapp.yaml lifecycle so the entire flow runs in CI with no portal clicks, which is the only way to get auditable, repeatable Teams app delivery.
The hard parts of CI-driven Teams publishing are authentication and environment separation, and the prompt attacks both directly. It demands non-interactive service-principal or federated-credential auth instead of the interactive login the docs default to, and it insists on per-environment .env files so dev, staging, and prod each carry their own app registration and bot identity without branching the code. The “promote, don’t rebuild” instruction is the keystone: build the package once, carry the same artifact forward, and swap only manifest values, so production ships exactly what staging validated.
By making teamsapp validate a required gate and asking explicitly where a human approval is unavoidable (org-catalog admin review), the output stays honest about what can and cannot be fully automated. Combined with a versioned-package rollback step, the result is a pipeline you can defend in a change-review meeting rather than a script that happened to work once on someone’s laptop.