Let’s face it—most Java developers are great at writing code but find Kubernetes deployments and infrastructure automation a bit daunting. GitOps changes the game by turning deployment into a version-controlled, auditable, and reproducible process—just like your code.
This article introduces GitOps from a Java developer’s perspective. You’ll learn how to:
- Use Git as your single source of truth
- Automate deployments with ArgoCD
- Manage Kubernetes manifests like a pro
- Integrate CI/CD pipelines with GitOps workflows
Let’s get you deploying Java apps to Kubernetes without drowning in kubectl commands.
What is GitOps?
GitOps is an operational model where:
- All deployment configuration is stored in Git
- Git changes automatically sync to Kubernetes clusters
- A GitOps tool (like ArgoCD) continuously reconciles your declared state
Think of it as “Infrastructure-as-Code meets CI/CD.”
Tech Stack Overview
- Java App: Spring Boot (or any Java app)
- Containerization: Docker
- Kubernetes Cluster: Local (Minikube/kind) or Cloud (GKE, EKS, etc.)
- GitOps Tool: ArgoCD
- Git Repo: Separate repo for Kubernetes manifests (preferred)
Step 1: Containerize Your Java App
Your Dockerfile should look something like:
# Dockerfile
FROM eclipse-temurin:17-jdk-alpine
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
Build & push your image:
docker build -t your-registry/java-app:1.0 . docker push your-registry/java-app:1.0
Automate versioning with Git commit SHA or CI build number.
Step 2: Write Kubernetes Manifests
Create a simple Kubernetes deployment + service:
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: java-app
spec:
replicas: 2
selector:
matchLabels:
app: java-app
template:
metadata:
labels:
app: java-app
spec:
containers:
- name: java-app
image: your-registry/java-app:1.0
ports:
- containerPort: 8080
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: java-app-service
spec:
selector:
app: java-app
ports:
- port: 80
targetPort: 8080
type: ClusterIP
Pro tip: Use Kustomize or Helm to manage environments (dev, staging, prod) cleanly.
Step 3: Organize Your GitOps Repository
Structure your Git repo like this:
gitops-repo/ ├── apps/ │ └── java-app/ │ ├── base/ │ │ ├── deployment.yaml │ │ └── service.yaml │ └── overlays/ │ └── prod/ │ └── kustomization.yaml
Use Kustomize to patch images per environment:
# overlays/prod/kustomization.yaml
resources:
- ../../base
images:
- name: your-registry/java-app
newTag: "1.0"
Commit and push these manifests to Git.
Step 4: Install and Configure ArgoCD
Spin up ArgoCD:
kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Access the ArgoCD UI:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Login using the default admin password (initially stored in a secret):
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d
Step 5: Connect ArgoCD to Your GitOps Repo
You can create an application in ArgoCD via UI or YAML:
# argo-java-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: java-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-repo
targetRevision: main
path: apps/java-app/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
Apply it:
kubectl apply -f argo-java-app.yaml
ArgoCD will now monitor Git and automatically deploy your Java app when the manifest is updated.
Step 6: Automate via CI/CD
You don’t update Kubernetes directly anymore—you push to Git.
Here’s a basic CI step (GitHub Actions example) that updates the image tag:
- name: Update Kustomize image
run: |
git clone https://github.com/your-org/gitops-repo.git
cd gitops-repo/apps/java-app/overlays/prod
kustomize edit set image your-registry/java-app:${{ github.sha }}
git commit -am "Update image to ${{ github.sha }}"
git push
ArgoCD will detect this and apply the new deployment. No kubectl needed.
Step 7: Test, Rollback, Repeat
- Break something? Revert the Git commit. ArgoCD rolls back.
- Want to test in staging? Use a different overlay (e.g.,
/overlays/staging) - Need approvals? Use pull requests to gate deployment changes.
Git becomes your source of truth and audit log.
Best Practices
| Practice | Why It Matters |
|---|---|
| Separate app and ops repos | Keeps code clean, avoids accidental infra edits |
| Use Kustomize/Helm | Manage complexity across environments |
| Automate image tagging | Avoids manual edits and stale configs |
| Protect main branches | Enforce PR reviews for deployments |
| Monitor ArgoCD status | Alerts you if sync fails or drifts |
Conclusion: GitOps Makes Ops Feel Like Dev
GitOps with ArgoCD bridges the gap between application development and infrastructure deployment. Java developers can finally:
- Own their deployments
- Treat config as code
- Reduce ops toil and human error
By combining Git, CI pipelines, Kubernetes, and ArgoCD, you build secure, scalable, and repeatable delivery pipelines—without babysitting clusters.
Resources
