Infrastructure and connectivity
Identify dependencies during service onboarding and provision them before the first deployment. An application values file or Flux HelmRelease does not create every dependency a service needs.
Infrastructure and data
For each database, storage account, queue or external API, record the target environment, resource name, owner, access identity and connection settings. Agree capacity and recovery requirements for stored data with the resource owner.
For persistent data, record the required backup retention, acceptable data loss, restore procedure and recovery owner. Check the resource’s actual backup settings. The CPP storage BCDR runbook identifies storage types and accounts with different recovery capabilities; creating a storage account alone does not establish that the application’s data can be restored.
Use the CPP repository that owns the resource. Existing Terraform roots include PostgreSQL, Azure Key Vault and application gateways. Agree the root, environment configuration and pipeline with Platform Operations before raising the infrastructure change. Review the plan and apply it through that repository’s pipeline; do not create parallel resources from a workstation.
For a database-backed service, provision the application database and permissions, define the schema migration step and test it against the non-live database. Keep migration and rollback instructions with the service. Confirm connectivity using the service’s runtime identity, not an administrator’s credentials.
A service that needs a new namespace also needs its namespace configuration, identity and permissions. For Flux, follow add a stack or environment and the workload-specific identity settings in onboard a service.
Secrets and identity
Record which secrets the application needs and how it receives each one. CPP supports HashiCorp Vault lookups while Ansible renders deployment values and Azure Key Vault secrets mounted through the Secrets Store CSI integration. Follow the selected mechanism in tools and configuration and the deployment instructions.
For HashiCorp Vault, provision the secret path and deployment access before adding its lookup to the values file. For Azure Key Vault, provision the secret, workload identity, federated credential and Key Vault access before enabling its chart mappings. Flux’s workload identity settings must be wired into both the Helm release and the stack configuration as its runbook describes.
Commit only secret references and non-secret configuration. Confirm that the running application can read its secrets as part of the first deployment checks.
Routing, DNS and TLS
Agree whether the service is called only inside the stack or needs access through a CPP gateway. Record its hostname, URL paths, port, authentication requirements and permitted callers. For an external connection, also record the destination and any firewall or IP allow-list requirement.
The CPP application charts provide service routing. For example, the springboot-app VirtualService template reads gateway.name, gateway.namespace, gateway.host and each service’s route.path and optional route.rewrite. Set these in the Helmsman values or Flux release for the target environment, using the agreed gateway and stack hostname.
When a new hostname or public entry point is required, arrange the DNS record, TLS certificate and gateway or application-gateway change with Platform Operations. Supply the hostname, route, backend port and target environments. Confirm which repository owns each change and complete those changes before testing the URL. A chart route alone does not provision public DNS or a certificate.
The Crime private DNS BCDR runbook identifies cpp-terraform-network as the owner of the managed live private DNS zones and resolver. It records the public cjscp.org.uk zone in azure-public-dns, and distinguishes AKS and ACR zones owned elsewhere. Classify the requested hostname against that ownership before raising the DNS change.
For outbound connections requiring an allow-list, use CPP egress IP guidance to establish the address for the actual workload. Check auto shutdown schedules when booking dependency and integration tests.
Ready for deployment
Before deploying, confirm that:
- the selected chart version and application image exist in the target registry
- required infrastructure, database schema and runtime permissions are provisioned
- secret entries and their access identities exist
- the intended hostname, route and TLS configuration are ready for the tests that need them
- the service values define its port, health probes, resource requests and limits using the selected chart
Continue with the Helmsman or Flux deployment steps, then verify the service through its intended route as well as its health endpoint.