Add automated Kubernetes deployment to CI/CD pipeline

[mucsi96]

Summary

This PR adds an automated deployment job to the CI/CD pipeline that deploys both server and client applications to Kubernetes after successful image publication. It also refactors the deployment script to use GitHub Actions secrets instead of Azure Key Vault for configuration management.

Key Changes

• New deploy job in pipeline: Added a new deployment stage that runs after both server and client images are published, but only on pushes to the main branch

  • Installs required tools (Helm and kubectl)
  • Establishes secure network access via Twingate
  • Executes the deployment script with necessary secrets

• Refactored scripts/deploy.sh: Migrated from Azure Key Vault to environment variables for better CI/CD integration

  • Removed Azure CLI calls to fetch secrets from Key Vault
  • Now accepts K8S_CONFIG, HOSTNAME, and API_CLIENT_ID as environment variables with validation
  • Hardcoded the Azure Key Vault endpoint since it's a static value
  • Updated all variable references to use uppercase environment variable names

Notable Implementation Details

• The deployment only triggers on main branch pushes, preventing accidental deployments from feature branches
• Kubeconfig is written to a RAM-based temporary file (/dev/shm) for enhanced security
• The script maintains proper cleanup via trap handlers
• Helm chart versions are dynamically fetched to always deploy the latest available versions
• Docker image tags are retrieved from Docker Hub registry API to ensure latest published versions are deployed

https://claude.ai/code/session_01PfV6sZGpFXbZd4VDzF7hMi

[claude]

PR Review: Add automated Kubernetes deployment to CI/CD pipeline. Good overall direction - moving secrets from Key Vault lookups to GitHub Actions secrets simplifies CI/CD integration. Issues: (1) HOSTNAME is a reserved bash variable - automatically set by bash to the system hostname, so the validation check in deploy.sh silently passes locally. Rename to DEPLOY_HOSTNAME or APP_HOSTNAME. (2) Deploy job runs even when no new images were published - it always runs after publish jobs complete regardless of whether hasNextVersion was true. Expose job outputs and condition the deploy job on them. (3) Docker Hub tag fetching introduces a race condition - fetching the latest tag dynamically rather than using the version just published risks deploying a stale version. Pass published versions as job outputs instead. (4) Missing set -o pipefail - deploy.sh uses set -e but piped curl commands can fail silently since jq succeeds on empty input. (5) Unquoted variables in helm --set flags risk word-splitting. (6) twingate/github-action@v1 uses a mutable tag - pin to a commit SHA. (7) Minor: AZURE_KEYVAULT_ENDPOINT is hardcoded - add an inline comment noting it is static infrastructure.