DevOps engineers who turn half-day deployments into 15-minute automated pipelines.

CI/CD pipelines on GitHub Actions, GitLab CI, or CircleCI that test, build, and deploy automatically on every push to a feature branch or merge to main. Pipeline stages: dependency installation with layer caching (so a Node.js install step that took 3 minutes runs in 15 seconds after the first build), unit test execution with parallel job splitting, Docker image build with BuildKit layer caching, container registry push (ECR, GCR, or Docker Hub), and deployment to the target environment. Branch-based deployment strategy: feature branches deploy to ephemeral preview environments (Vercel, Railway, or Kubernetes namespace with a cleanup job), main deploys to staging, tagged releases deploy to production with a manual approval gate for production-impacting changes. Docker builds optimised for layer caching: dependency installation in a separate layer from application code so a code change doesn't invalidate the dependency cache. Secrets managed via GitHub Actions secrets, GitLab CI variables, or AWS Secrets Manager, never in environment files committed to the repository. Pipeline execution time tracked per stage so regressions in build time are visible before they become 20-minute feedback loops that slow the entire team down.

Security scanning integrated into the pipeline at three layers. Trivy runs container image scanning on every built Docker image, catching OS package CVEs and application dependency CVEs, blocking the pipeline on critical or high-severity findings with a configurable suppression list for accepted risks. Snyk or Dependabot covers dependency vulnerability alerts in package.json/requirements.txt/go.mod with automated PR creation for patch updates. Semgrep SAST catches common vulnerability patterns in application code: SQL injection, XSS, insecure deserialization, and hardcoded secrets. gitleaks or TruffleHog runs on every pull request to catch accidentally committed secrets before they reach the main branch. These checks run in parallel with tests to avoid adding sequential time to the pipeline. The result is a CI/CD pipeline that enforces security checks as part of the standard engineering workflow without requiring a separate security team review for every deployment.

Infrastructure defined in Terraform HCL committed to version control: every VPC, subnet, security group, RDS instance, ECS service, S3 bucket, and CloudFront distribution is reproducible from a single terraform apply. Remote state stored in S3 with DynamoDB state locking (AWS) or GCS with advisory locks (GCP), preventing simultaneous applies from corrupting state. Workspace separation between environments: terraform workspace select staging applies to the staging environment, production to production, with separate state files and the ability to diff environments. Each infrastructure change is a reviewed pull request with a terraform plan output showing exactly what will change before anyone approves it, the difference between a confident change and an undocumented manual intervention. AWS and GCP modules built for the specific service mix: VPC with public and private subnets, NAT gateway for private subnet internet access, ALB for HTTP/HTTPS routing, RDS in a private subnet with encrypted storage, and ECS Fargate or Kubernetes for compute. Security group rules defined by principle of least privilege: compute layer only accepts traffic from the load balancer, database layer only accepts traffic from the compute layer, no inbound internet access to internal resources.

Terraform security scanning with tfsec or Checkov runs on every pull request containing infrastructure changes, catching misconfigurations (S3 buckets with public access, security groups with 0.0.0.0/0 inbound rules, RDS instances without encryption at rest, CloudTrail logging disabled) before they reach production. Infracost annotates infrastructure pull requests with the estimated monthly cost impact of the changes: adding a NAT gateway shows a +$32/month annotation; removing an unused load balancer shows a -$16/month saving. Infrastructure cost becomes part of the code review conversation rather than a monthly surprise. Drift detection runs on a scheduled basis (daily or weekly) comparing the actual cloud resource state against the Terraform state file, resources created or modified outside of Terraform (manual console changes, emergency fixes) are identified and either imported into Terraform state or flagged for removal.

Docker containerisation with multi-stage Dockerfiles: a build stage with all development dependencies (Node.js, Python pip packages, Go build toolchain), a production stage that copies only the compiled artefact, reducing a 1.2GB development image to a 180MB production image that deploys faster and has a smaller attack surface. Non-root user in the production stage (USER node or equivalent) and read-only root filesystem where the application doesn't require write access. Kubernetes deployment on EKS (AWS) with managed node groups, GKE (Google Cloud) with Autopilot or Standard mode, or AKS (Azure) for applications that need horizontal scaling, multi-service coordination, or multi-region resilience. Helm charts for application deployment: templated Kubernetes manifests parameterised per environment via values-staging.yaml and values-production.yaml, a single chart maintained rather than divergent manifests per environment. Horizontal Pod Autoscaler (HPA) configured against CPU utilisation target (60–70% to leave headroom before new pods become ready) and custom metrics via the Prometheus adapter (queue depth from SQS/Kafka, active connections) for workloads where CPU is a poor scaling proxy. KEDA (Kubernetes Event-Driven Autoscaling) for background workers that should scale to zero when their queue is empty, no idle pods consuming capacity during off-peak periods. Pod Disruption Budgets ensure a minimum number of replicas stay available during node pool upgrades or cluster maintenance, configured per-Deployment to guarantee at least one replica is always serving traffic. Resource requests and limits defined on every container (requests from profiling at p50 load, limits at 2× the p99 peak) so the Kubernetes scheduler has accurate capacity data and OOMKills are visible as an anomaly rather than a silent restart.

Observability at three levels: infrastructure metrics (CPU, memory, disk I/O, network throughput via CloudWatch, Datadog, or Prometheus/Grafana), application metrics using the RED method (Rate of requests, Error rate, Duration/latency per endpoint, not just "is it up"), and business metrics (orders processed per minute, payment success rate, job completion count) that surface application-level failures invisible to infrastructure monitoring. OpenTelemetry SDK instrumentation for distributed traces: traceparent propagated across service boundaries so a slow API response can be traced through every upstream service call to identify the specific operation causing the latency, the diagnosis that takes 2 minutes with tracing and 2 hours without it. Alerting with PagerDuty or OpsGenie: threshold-based alerts on sustained error rate (not a single 500 but >2% error rate for 5 consecutive minutes), latency (p95 response time exceeds 2s for a critical path for 10+ minutes), and infrastructure saturation (database CPU above 80% for 10 minutes). Alert noise reduction through appropriate aggregation, alerting on the condition rather than every individual event; an alert that fires more than twice a week without action is either a false positive or an unmitigated issue, and both should be resolved. Runbooks for the five most likely failure scenarios: RDS connection exhaustion, pod OOMKill, upstream API degradation, deployment failure, and cache layer failure, each with the symptoms, diagnostic commands, and recovery steps documented before an incident so the on-call engineer is executing a procedure, not improvising. Log aggregation to CloudWatch Logs, Datadog, or the ELK stack with structured JSON logging (request ID, user ID, latency, upstream dependencies called) from application code so log queries are filterable rather than requiring regex on unstructured text.