Skip to main content

CI/CD Pipelines

NextGenPoll has 5 GitHub Actions workflows covering continuous integration and deployment for all components.

Pipeline Dependency Map​

Deployment Flow​

The following diagram illustrates how code moves from a developer's machine to the production environment:

GitHub Actions Dashboard - Shows the list of recent workflow runs and their status.
Figure 6: Monitoring deployment status in the GitHub Actions dashboard.

Overview​

WorkflowFileTriggerWhat it does
Backend CIbackend-ci.ymlPR / push to backend/**Compile, test (H2), PMD static analysis
Backend CDbackend-cd.ymlAfter Backend CI succeeds on mainBuild JAR, run Flyway migrations, deploy to Azure App Service
Frontend CIfrontend-ci.ymlPR / push to frontend/**, powerpoint/**, packages/shared/**Build Office add-in, build Next.js
Frontend CDfrontend-cd.ymlAfter Frontend CI succeeds on mainBuild add-in + frontend, deploy to Azure App Service
Docs CDdocs-cd.ymlPush to docs/** on mainBuild Docusaurus, deploy to Azure Static Web Apps

Backend CI (backend-ci.yml)​

Triggers: PRs and pushes to backend/**

checkout → Java 25 setup → ./mvnw verify -Dflyway.skip=true
  • Uses H2 in-memory database via SPRING_PROFILES_ACTIVE=test — no PostgreSQL needed.
  • Flyway is skipped (-Dflyway.skip=true); schema created by ddl-auto=create-drop in H2.
  • PMD static analysis runs but does not fail the build (-Dpmd.failOnViolation=false).
  • Dummy Azure OpenAI env vars are set so the Spring context loads without real credentials.

Required secrets: None (uses dummy values for CI).

Backend CD (backend-cd.yml)​

Triggers:

  • Automatically when Backend CI completes successfully on main
  • Manually via workflow_dispatch
checkout → Java 25 setup → Build JAR → Flyway migrate (Azure DB) → Deploy JAR to App Service

Key steps:

  1. Build JAR — ./mvnw package -DskipTests -Dflyway.skip=true
  2. Run migrations — ./mvnw flyway:repair flyway:migrate against Azure PostgreSQL using DB secrets
  3. Rename JAR — app.jar (required by App Service startup command)
  4. Deploy — azure/webapps-deploy@v3 using AZURE_BACKEND_PUBLISH_PROFILE

Required secrets:

  • AZURE_BACKEND_PUBLISH_PROFILE
  • AZURE_DB_URL, AZURE_DB_USERNAME, AZURE_DB_PASSWORD
Migration before deploy

Flyway migrations run before the new JAR is deployed. This ensures the schema is ready before the new code starts. Never swap this order.

Frontend CI (frontend-ci.yml)​

Triggers: PRs and pushes to frontend/**, powerpoint/**, packages/shared/**, package.json, package-lock.json

checkout → Node 24 setup → npm ci → Build Office add-in → Copy add-in to frontend/public/addin/ → Build frontend
  • The Office add-in must be built before the Next.js build because the frontend serves add-in assets from /public/addin/.
  • No deployment; validates that the build succeeds.

Required secrets: None.

Frontend CD (frontend-cd.yml)​

Triggers:

  • Automatically when Frontend CI completes successfully on main
  • Manually via workflow_dispatch

Uses a concurrency group (azure-app-nextgenpoll-web) to prevent simultaneous deploys.

checkout → Node 24 setup → npm ci → Build add-in → Build frontend → Package standalone → Deploy to App Service

Key steps:

  1. Build add-in — npm run build in powerpoint/
  2. Build frontend — copies powerpoint/dist/* into frontend/public/addin/, then npm run build
  3. Package standalone — copies static/ and public/ into .next/standalone (required for output: "standalone")
  4. Deploy — azure/webapps-deploy@v3 deploys the .next/standalone directory

Required secrets:

  • AZURE_FRONTEND_PUBLISH_PROFILE
  • All NEXT_PUBLIC_* and AZURE_TENANT_ID build-time secrets

Docs CD (docs-cd.yml)​

Triggers:

  • Push to docs/** on main
  • Manually via workflow_dispatch
checkout → Node 24 setup → npm ci → Build Docusaurus → Deploy to Static Web Apps
  1. Build — npm run build --workspace=docs outputs to docs/build/
  2. Deploy — Azure/static-web-apps-deploy@v1 using AZURE_STATIC_WEB_APPS_API_TOKEN_DOCS

Required secrets:

  • AZURE_STATIC_WEB_APPS_API_TOKEN_DOCS

Adding a New Workflow​

  1. Create .github/workflows/{name}.yml.
  2. Follow the naming convention: {component}-{ci|cd}.yml.
  3. For CD workflows, gate with if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }} to prevent deploys from failed builds.
  4. Document required secrets in Environment Variables.

Re-running a Failed Deployment​

  1. Go to GitHub → Actions → find the failed workflow run.
  2. Click Re-run failed jobs (not "Re-run all jobs") to avoid re-running steps that already succeeded.
  3. If a DB migration failed, check Flyway's output in the logs and run flyway:repair locally against the production DB before re-deploying.