Not every engagement is the one you own end to end. On two much larger systems for a global automotive manufacturer (a .NET retail-reporting application and a Kubernetes-based microservice platform), my footprint was small and specific: containerization, delivery pipelines, and Helm chart scaffolding, contributed into codebases someone else architected and mostly owns. Both are honestly modest in scope. Neither is padded here to look bigger than it was.
A .NET app’s delivery layer
The application itself (an ASP.NET Core reporting tool with enterprise SSO and scheduled background jobs) was someone else’s, and stayed someone else’s. What I added sat entirely at the edges: a multi-stage Docker build, an enterprise CA trust bundle baked into the container’s trust store so it could actually reach internal endpoints over TLS, a startup connectivity probe that fails fast against a known internal target before the app process ever starts, and a lightweight health-check endpoint for the orchestrator to poll. On the delivery side I added branch-guard jobs to the release workflows so a workflow could only run from the branch it was meant to, and put environment protection rules in front of both the pre-production and production release paths. None of it is business logic. All of it is the difference between an image that builds and an image that’s safe to actually roll out.
flowchart LR gha["branch-guarded release workflows"] -->|"build + push"| ecr["internal registry"] subgraph app[".net 8 container"] ep["startup probe: fails fast"] core["asp.net core app: not mine"] hc["health endpoint"] end ecr -->|"deploy"| app ep --> core core --> hc ca["enterprise ca trust bundle"] -.->|"baked into the image"| core
Helm charts for someone else’s platform
The second system was a multi-service .NET and Angular platform already running on an internal Kubernetes cluster behind Istio, deployed through ArgoCD. My contribution there was narrower still: Helm chart scaffolding for a handful of the backend services (health probes, autoscaling, security context, Istio virtual-service routing), following the pattern the rest of the platform’s charts already used rather than inventing a new one, plus two small fixes (a database connection-string reference and an incorrect image-registry path) and a couple of workflow-input refinements to the GitOps deploy pipeline’s cluster and service selectors.
flowchart LR dev["developer dispatch"] --> setup["resolve cluster / service"] setup --> build["build image → internal registry"] build --> scan["image scan"] scan --> argo["argocd gitops deploy"] argo --> helm["helm charts + per-env values"] helm --> k8s["internal kubernetes cluster: istio mesh"]
What this wasn’t
I didn’t design either platform’s architecture, and I’m not claiming otherwise. What both engagements gave me was repeated, hands-on practice with the same delivery primitives (multi-stage container builds, TLS trust and health-checking at the container boundary, Helm as the unit of deployment, GitOps as the deployment mechanism) applied inside two codebases I didn’t own, which is a different, and in its own way harder, skill than building the same primitives inside my own.