Project structure · Data and DevOps
Kubernetes with Helm project structure
Opens with creditsA Helm chart repository for one app: the chart that helm create gives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design.
Curated by Tauseef FayyazIntermediate129 files and foldersHelm 4.3 (chart apiVersion v2), Kubernetes 1.34 to 1.37, helm-unittest 1.2Checked October 2026How it grows
Each stage opens the explorer there
- 1Day 1What the scaffold and your first hour give you21 files and folders
- 2GrowingWhat a real app with features and tests adds+54 files and folders
- ProductionWhat running it for real users adds+20 files and foldersOpens with credits
- ExpertWhat a team needs to keep it healthy for years+34 files and foldersOpens with credits
How it is organised
- Charts live under `charts/`, one folder each, created with `helm create` and trimmed to what the app needs.
- The chart is a package; environments are configuration. Defaults in the chart's values.yaml are small and safe, and each environment's overrides live in `environments/<env>/values.yaml`.
- Bump the chart `version` on every chart change and `appVersion` when the app changes. One version, one exact chart.
- Every value has a comment, a type in values.schema.json and a place in the generated README.
- Test in layers: `helm lint` and the schema on every save, helm-unittest offline on every commit, `ct install` into kind on every pull request, a Kubernetes version matrix nightly.
- No secrets in values or Git. Pull them from a secret store at runtime with the External Secrets Operator (or your cloud's CSI driver).
- Every workload ships with requests, limits, probes, a non-root security context and, in production, a PodDisruptionBudget and NetworkPolicy.
- Deploys come from Git: CI runs `helm upgrade` or Argo CD syncs the repo. Never `helm upgrade --set` from a laptop.
- Share helpers through a library chart only once there are several charts; until then, `_helpers.tpl` is enough.
At the top of the project
Open one in the explorer for the full story
- shop-charts/
- .devcontainer/A dev container with Helm, kubectl, kind, ct and the unittest plugin installed.1 inside
- .vscode/Editor settings and extension recommendations.2 inside
- charts/One folder per chart. chart-testing looks here by default.2 inside
- environments/One values file per environment, kept outside the chart.2 inside
- rendered/Output of scripts/render.sh: every environment rendered to plain YAML.
- scripts/Shell scripts CI and the Makefile share.2 inside
- .editorconfigTwo-space indentation and final newlines for YAML and templates.
- .gitignoreIgnores packaged charts, downloaded dependencies and rendered output.
- .pre-commit-config.yamlHooks that run helm lint, helm-docs and helm unittest before each commit.
- ct.yamlchart-testing config: chart folder, target branch, timeouts, version bump check.
- kind-config.yamlA kind cluster definition for local and CI installs, with the Kubernetes version pinned.
- lintconf.yamlyamllint rules that ct lint applies to Chart.yaml and values files.
- MakefileShort commands: make lint, make test, make render, make install ENV=dev.
- README.mdWhat the charts deploy, how to install locally, and how releases work.
Learn more on Sefism
Roadmaps, cheat sheets and projects that go with Kubernetes with Helm.
- RoadmapDevOps and cloud roadmapLinux, Docker, Kubernetes, AWS
- Roadmap· Platform engineeringPlatform engineering and SRE roadmapSLOs, observability, Kubernetes platforms
- RoadmapCloud engineering roadmapOne cloud in depth, with certifications
- Cheat sheetDevOps and cloud cheat sheetLinux, Docker, Kubernetes, AWS.
- Cheat sheetPlatform engineering and SRE cheat sheetSLOs, observability, Kubernetes platforms.
- FYP idea· AdvancedHelm Chart Permission Analyser That Finds Kubernetes Cluster Takeover Paths Before InstallBuild a tool that reads a Helm chart before it is installed and works out whether the permissions it grants could let an attacker who compromises one of its pods take over the whole cluster. Many third-party operators and add-ons ask for far more access than they need. The analyser explains each dangerous permission, the attack path it opens and a narrower alternative.
- FYP idea· IntermediateKubernetes Network Policy Generator With Pre-Apply Connectivity Tests to Stop Lateral MovementBuild a tool that watches which services in a Kubernetes cluster actually talk to each other, generates least-connection network policies from that traffic, and tests them in CI against the expected connectivity before they are applied, so nothing legitimate breaks. Most clusters run with no network policies at all, which lets an attacker who breaks into one pod reach every database and internal API. This makes locking them down safe enough to actually do.
- FYP idea· BeginnerContainer Image Slimming and Vulnerability Diff Report in CI, Verified by Your Own TestsBuild a CI step that takes an application's container image, produces a slimmed version that keeps only the files the app actually uses, runs the project's own tests against the slim image to prove nothing broke, and reports the size saved and the known vulnerabilities removed. Teams get smaller, safer images without hand-tuning Dockerfiles, and a clear report they can trust.
- QuestionDo I need Docker and Kubernetes as a junior developer?Docker, yes: learn the basics, because nearly every team uses containers and you will be expected to run the project locally and read a Dockerfile. Kubernetes, mostly no: understand what it does and a few core terms, but deep Kubernetes can wait until your job or a DevOps direction needs it.
See 7 moreShow fewer
- QuestionWhat is platform engineering, and how is it different from DevOps?DevOps is a culture and set of practices: developers and operations sharing responsibility for shipping and running software. Platform engineering is one way to put that into practice at scale: a team builds an internal platform, a paved road of tools and templates, so product teams can ship without becoming infrastructure experts.
- QuestionCan I become an SRE or platform engineer straight after graduating?Sometimes, but it is rare, because these roles expect you to have run production systems. The more reliable path is a first job in backend, DevOps or cloud support, where you learn production, then a move into SRE or platform work within a couple of years.
- QuestionHow do I move from DevOps to site reliability engineering?Keep your DevOps base and add what SRE is really judged on: SLOs and error budgets, alerting on burn rate, running incidents and writing postmortems, and debugging production calmly. Prove it with one service you operate end to end, then move internally or apply with that evidence.
- Resource· GuideHelm DocumentationThe official docs for Helm, the package manager for Kubernetes and a CNCF graduated project. Learn to install, upgrade and roll back charts, then write your own with the chart template guide and best practices. Now covering Helm 4, with Helm 3 docs still a click away.
- Resource· Cheat sheetKubernetes Production Best PracticesLearnk8s's free, open production readiness checklist for Kubernetes workloads: 40 checks covering your application, manifests, security, scaling and going live. Each item explains why it matters and how to verify it. Use it before your first real deployment and as a review list for every service after.
- Resource· GuideArgo CD DocumentationThe official docs for Argo CD, the declarative GitOps continuous delivery tool for Kubernetes. Learn how a Git repository becomes the source of truth for what runs in your clusters, how syncs and drift detection work, and how teams deploy Helm charts and Kustomize overlays without running kubectl by hand.
- Resource· GuideCNCF Platforms White PaperThe CNCF's vendor-neutral answer to "what is an internal platform, and why build one?", written by TAG App Delivery. It defines a platform, lists the attributes of good platforms and platform teams, and maps 13 capability areas to open source projects. Free, short, and the clearest shared definition to start a platform conversation with.
Checked against 22 official sources, October 2026. If something has changed, the docs win.Show sourcesHide sources
- Helm: helm create source (v4.3.0)
- Helm 4 overview
- Helm: Chart best practices
- Helm: Charts (Chart.yaml, values schema, dependencies)
- Helm: Chart tests
- Helm: Chart hooks
- Helm: Library charts
- Helm: Use OCI-based registries
- helm-unittest
- chart-testing (ct)
- chart-testing-action
- kind
- helm-docs
- kubeconform
- kube-linter
- Kubernetes: Recommended labels
- Kubernetes: Deprecated API migration guide
- Gateway API: HTTPRoute
- External Secrets Operator
- Argo CD: Helm
- Argo CD: ApplicationSet Git generator
- GitHub Docs: Dependabot supported ecosystems
Best practices and checklists for this stack
Picked from the other libraries by shared topics.
Best practices
See all- Kubernetes Best PracticesRun workloads on Kubernetes that schedule well, survive restarts and node drains, and stay locked down: resources, probes, PDBs, Pod Security and RBAC.
- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Disaster Recovery ChecklistBackups and DR you can prove: RPO and RTO per system, backup coverage, off-site and immutable copies, restore tests, zone and region choices, runbooks, drills, dependencies and communication.
Work with me
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com