01

Shared runners and templates for many teams

A central CI/CD platform many application teams build on: shared runners, owned templates, short-lived credentials.

  • Templates included, not copiedA platform team owns the CI templates; one fix reaches every pipeline.
  • One pod per job, on SpotShared runners on Amazon EKS scale with demand; nothing idles overnight.
  • No cloud keys in pipelinesJobs swap a GitLab ID token for a short-lived role; production trusts protected branches only.
  • A portal for onboardingGuidelines and docs in one place, so new developers onboard themselves.
Central CI/CD Platform
merge requestsincludeonboardingCI jobsadds nodesID token → STSShared GitLab · every teamDevelopment account · shared runnersVPCPrivate subnetAmazon EKS clusterNon-production accountProduction accountApp teamsevery teamCode scanningdependency botsCI template libraryplatform-ownedShared GitLabrepos · merge requestsDeveloper portalguidelines · docsAWS Fargaterunner manager · KarpenterAmazon EKSprivate clusterEC2 Spot nodeone pod per jobEC2 Spot nodeadded on demandAmazon ECRimage cacheAmazon S3dependency cacheAmazon CloudWatchrunner logs · metricsDeploy roleGitLab OIDC trustWorkloadsdev · testDeploy roleprotected branch onlyWorkloadsproduction

Point at a component to light its links; select it for what it does here and the practice that makes it right on AWS.

Point at a component to see what it does; select it for the best practice.Open the architecture
02

Tools by pipeline stage

Tools NGT has integrated in client delivery. We start from what you run and standardise where it lowers risk.

Source control

githubgitlabbitbucket

CI/CD orchestration

jenkinsazure-devopsaws-codepipelineGitLab CIGitHub Actions

Code quality & SAST

sonarqubeCoverityVeracodeFindSecBugs

Open source & artifacts

blackducksnykOWASP Dependency-CheckJFrog ArtifactoryNexus

Containers & images

dockertrivyTwistlockHarbor

Dynamic & performance testing

zapPostmanJMeterSelenium

Secrets & identity

vaultazure-key-vaultKeycloak

Infrastructure & deployment

terraformansiblehelmargokubernetes

Monitoring & security operations

datadoggrafanaprometheusopentelemetrySplunkCheck Point
03

Same practice, native services

The controls stay the same on every cloud; the building blocks are each provider's own.

AWSAzureGoogle Cloud
PipelineCodePipeline, CodeBuild, CodeDeploy (blue/green)Azure DevOps with environment approvalsCloud Build or GitLab CI to GKE
RegistryAmazon ECRAzure Container RegistryGoogle Container Registry
Infrastructure as codeTerraform, AWS CDK, CloudFormationTerraform, BicepTerraform
RuntimeECS, EKS, LambdaAKS, App ServiceGKE
Logs & monitoringCloudWatch, DatadogAzure Monitor, Log AnalyticsCloud Logging and Monitoring, Datadog, Splunk

Toolchain questions

The questions this part raises, and their answers.

Yes. Each stage is a separate job a team can adopt on its own, so one set serves different languages, frameworks and clouds.

The checks and reporting stay the same; only the build steps differ.

SourcesNGT Service Offering v2.0 (Mar 2025)NGT Service Offering v3.2 (Jul 2026)NGT DevSecOps & Cloud Security Service Offering v0.4 (Jan 2025)NGT Cloud Operations Service Offering v0.2 (Jan 2025)NGT Cloud/DevOps/SRE Service Offering (Sep 2026)NGT DevOps-AI Service Offering (Oct 2026)