How SKAO environments fit together

SKAO runs software in several environments, on infrastructure owned by different teams and reached in different ways. This page explains how a change moves between them, who runs each platform, and what stands between you and access.

Environment lifecycle

The central CI/CD clusters host four kinds of deployment environment for a project. Each one is created by a job template from the templates repository, so the promotion path is the same for every project that includes them.

Environment	Created from	Trigger	Lifetime
Test	Any pipeline	Runs automatically when the repository has tests	Per commit, removed when the job finishes
Development	Any branch	Manual	Stops automatically after four hours
Integration	Default branch only	Automatic	Persistent, one per project
Staging	Default branch only	Automatic, after integration succeeds	Persistent, one per project

Promotion is gated by the templates rather than by convention. A development environment is deliberately manual, because it exists for a branch that one person is working on. Integration and staging both carry a rule restricting them to the default branch, so a feature branch cannot deploy to either. Staging additionally declares that it needs the integration deployment, which means a change reaches staging only after it has been deployed to integration in the same pipeline.

Read the GitLab environments documentation for the underlying mechanism, and Environment naming conventions for the namespace and environment name each template creates.

Deployment to production is gated differently. It is restricted to the AIV teams, rather than controlled by a branch rule that any project can satisfy. Web-based deployments are usually made to AWS, where the System Team acts as the AIV team. Requesting that access, and the pipeline job that uses it, are covered in Deploy to the AWS production cluster.

Infrastructure ownership

Environments run on platforms owned by different teams. Ask the owning team about capacity, outages, and access.

Environment	Owner	Where to ask
CI/CD clusters	System Team	#team-system-support
mid-itf	BANG with #team-atlas	#team-mid-itf-support
low-itf	BANG with #team-vulcan	#team-low-itf-support
mid-aa	BANG with #team-atlas	#team-mid-aa-support
low-aa	BANG with #team-vulcan	#team-low-aa-support
psi-mid	PSI teams	#mid-psi-itf-integration
psi-low	PSI teams	#help-psi-low
digital-signal-psi	PSI teams	#team-topic

The CI/CD clusters — stfc-techops, stfc-dp, and aws-cicd — are managed by the System Team, which also provides the VPN profiles and the GitLab runners that deploy into them. The ITF and Array Assembly environments are managed between BANG and the AIV teams — Atlas for Mid and Vulcan for Low — and each facility has its own support channel above. #team-bang covers questions that span the facilities. PSI hosts the integration environments for Mid, Low, and digital signal processing.

Where no channel is listed above, raise a ticket on the System Team Support Desk. That is the default route whenever you do not know which team owns a question.

Environments are taken down for scheduled maintenance. Check the Planned Maintenance Schedule before concluding that an environment is broken.

Access boundaries

Reaching an environment and being permitted to act in it are separate boundaries. Both depend on where the environment runs rather than on what you intend to do there.

Reach an environment

The central CI/CD clusters sit behind a VPN. TechOps and DP use separate profiles, and a TechOps profile does not grant access to DP. Both are requested from the System Team and used the same way, as described in Configure your development environment.

The ITF and Array Assembly environments publish no endpoint at all. They are reached through InfraHQ, which issues short-lived Kubernetes credentials for the clusters your grants cover and writes them into a local kubeconfig. That is also the only route to Headlamp for those environments, as described in Access a cluster with InfraHQ.

Production environments have restricted deployment and debugging access. VPN access to them is requested through #team-bang rather than the System Team.

Act in an environment

On stfc-techops, most people hold read-only access through the debugging tools. Headlamp applies the permissions of the signed-in identity, and a Coder workspace is limited to list and view operations, so the API can refuse changes such as deleting a Pod. Request elevated access through InfraHQ when read-only is not enough.

stfc-dp works the same way, but the DP platform team manages its own access rather than the System Team. Ask in #proj-dp-platform.

Access to the ITF and Array Assembly environments is highly restricted. It is granted to the AIV and Platform teams, and to whoever those teams consider necessary. Ask in the support channel for the facility, listed under Infrastructure ownership.

Deploying into a cluster is a third boundary. A pipeline deploys through a GitLab runner holding a kubeconfig for the target cluster, so a project gains deployment access by being given a runner tag, not by a developer holding credentials. See Deploy to SKAO environments for the request process and the job configuration.