gitops

GitOps deployment layer for my application projects. This repository is intended to manage Kubernetes deployments with Argo CD and Helm, without adding another product project to maintain.

Goal

Use one operations-focused repository to describe how my existing projects can be deployed, promoted, and managed across environments.

This repo can eventually manage deployments for:

• devforces
• lovable
• exchange
• turtle-justice
• other deployable services

Proposed Structure

gitops/
  README.md

  argocd/
    app-of-apps.yaml
    projects/
      personal-platform.yaml
    apps/
      devforces.yaml
      lovable.yaml
      exchange.yaml
      turtle-justice.yaml

  charts/
    web-app/
      Chart.yaml
      values.yaml
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
        configmap.yaml
        secret-ref.yaml

  apps/
    devforces/
      values-dev.yaml
      values-prod.yaml
    lovable/
      values-dev.yaml
      values-prod.yaml
    exchange/
      values-dev.yaml
      values-prod.yaml
    turtle-justice/
      values-dev.yaml
      values-prod.yaml

  environments/
    dev/
      namespace.yaml
      ingress-values.yaml
    prod/
      namespace.yaml
      ingress-values.yaml

  docs/
    architecture.md
    deployment-flow.md
    secrets.md

What This Would Show

• Argo CD based continuous delivery
• Helm chart design for reusable app deployments
• Environment-specific configuration through values files
• Separation between app source code and deployment configuration
• Production-style thinking around ingress, secrets, namespaces, and promotion
• A platform/devops layer that supports the existing projects

Deployment Model

The intended flow is:

1. Application repositories build and publish Docker images.
2. This repository references those image tags in environment-specific values files.
3. Argo CD watches this repository.
4. Argo CD syncs the desired state into the Kubernetes cluster.
5. Rollbacks are handled by reverting Git commits or changing image tags.

Notes

• Secrets should not be committed to this repository.
• Real deployments should use External Secrets, Sealed Secrets, SOPS, or cloud-managed secret bindings.
• The initial implementation can target a local kind or k3d cluster before moving to a VPS or managed Kubernetes cluster.
• The repository should stay small and practical instead of becoming a collection of fake infrastructure YAML.

Future Scope

• Add a reusable Helm chart for Next.js and Express services.
• Add Argo CD app-of-apps configuration.
• Add separate dev and prod values.
• Add ingress and TLS examples.
• Add CI checks for helm lint and Kubernetes manifest validation.
• Add documentation for deployment flow and secret management.