GFTSolutions Lab
Solution Template

Build, demo and ship GFT prototypes faster on Azure.

This is the GFT Tech Office Azure starter — not a real solution. Clone it to spin up a new sales/delivery prototype: it ships a home, the Team Backlog, users & roles, the Container Apps infra, and Solution Hub registration. Follow the steps below to make it your own.

How to use this template Open the Backlog

0

Backlog ideas

0

Accepted

0

Built

What's in the box

Everything a prototype needs on day one

Team Backlog

Suggestions the team proposes, votes on and tracks from proposed to built, with file attachments — the reference slice to copy when you model your own entity. 0 ideas, 0 accepted.

Users & roles

App-level identity → admin/user roles persisted and managed in-app. First sign-in on a fresh database is bootstrapped as admin. (Wire up real app-level auth before exposing it.)

Azure infra + Hub

One terraform apply deploys a Container App into the shared Container Apps environment on the shared Flexible Server, binds a vanity domain, and registers the solution on the Solutions Lab Hub.

Get started

How to use this template

Full runbook

This solution is the GFT Tech Office Azure template. To spin up a new prototype, clone it, rebrand it, point the infra at a unique name, and deploy — the deploy also registers the solution on the Solutions Lab Hub. The steps below are the manual runbook (creating the Azure DevOps repo is not automated).

  1. 1

    Create the repository in Azure DevOps

    Each solution lives in its own repo under the Tech Office Azure DevOps project, named GftUs.SolutionsLab.<Name>. Create it, seed it from this template, then clone it locally.

  2. 2

    Rebrand the solution

    Everything in the UI (wordmark, page titles, hero copy) reads from one file. Edit it and the whole app renames.

  3. 3

    Set the infrastructure names

    Infra names are parameterised in Terraform. Copy the example tfvars and set a unique service name, database name/user and vanity hostname under azure.techoffice.gftus.com.

  4. 4

    Edit the Terraform state key by hand

    Terraform backends can't use variables, so the remote-state key must be changed by hand — once per solution. Pick a unique slug so you don't clash with the template's own state lock or Hub entry.

  5. 5

    Implement application-level authentication

    There is NO platform sign-in (no EasyAuth). Authentication is the app's job and is mandatory before you expose the deployment — otherwise every visitor is treated as the same user. The single integration point is resolveAuthenticatedEmail() in app/lib/auth.ts.

  6. 6

    Authenticate the CLIs

    A single apply builds the image in the shared ACR, talks to Azure, and publishes the Hub entry to the shared (GCP) registry bucket — so both the Azure CLI and gcloud must be authenticated on the machine running apply.

  7. 7

    Deploy to Azure Container Apps

    A single apply builds the image via az acr build, provisions the database + role on the shared Flexible Server, deploys the Container App into the shared Container Apps environment, and binds the vanity domain with a managed certificate. The shared Database, Network, Registry and ContainerApps stacks must already exist.

  8. 8

    Confirm the Solution Hub listing

    The same apply publishes solutions/<key>/solution.json to the shared Hub registry bucket, so the solution appears on the Solutions Lab Hub automatically. No separate step is needed.

  9. 9

    Build your first feature

    The Team Backlog is the reference CRUD slice. To model whatever your prototype tracks, copy it end to end and rename.