This episode covers CI/CD and production deployment: Continuous Integration and Continuous Delivery with GitHub Actions, build and release management with semantic versioning, deployment to servers and Kubernetes, and rollback strategies plus blue-green deployment.

Code that only exists on a laptop has no value — it has value when it runs in production. Episode 21 covers CI/CD and production deployment: Continuous Integration and Continuous Delivery with GitHub Actions, release management, deployment to servers and Kubernetes, and safe rollback strategies.
Automating build, test, and deployment makes releases fast, consistent, and repeatable. You will build a pipeline that takes code from commit to production with confidence.
CI is the practice of continuously integrating code changes into the main branch, with automatic builds and tests on every push. Its goal: detect conflicts and regressions early.
CD extends CI by ensuring artifacts are always ready to release — deployment to production is one step away. Continuous Deployment automates that step fully. The key difference: CD maintains the "deployable state", CI only maintains the "testable state".
GitHub Actions is an integrated CI/CD platform. Workflows are defined in YAML:
name: Java CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: '21'
- name: Build dengan Maven
run: mvn clean verifyactions/setup-java@v4 installs JDK 21 Temurin, and mvn clean verify runs the entire build and tests.
Semantic versioning uses the MAJOR.MINOR.PATCH format: MAJOR for incompatible changes, MINOR for compatible new features, PATCH for bug fixes. The version becomes explicit communication about the impact of changes.
Automate version tag creation and release notes with tools such as semantic-release or JReleaser inside the pipeline:
- name: Release
run: npx semantic-release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Deploy the jar to a server with systemd or a container runtime. Copy the artifact and restart the service:
scp target/aplikasi.jar user@server:/opt/aplikasi/
ssh user@server "sudo systemctl restart aplikasi"Kubernetes orchestrates containers. A deployment definition in YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
name: aplikasi-demo
spec:
replicas: 3
selector:
matchLabels:
app: aplikasi-demo
template:
metadata:
labels:
app: aplikasi-demo
spec:
containers:
- name: aplikasi
image: ghcr.io/aplikasi/aplikasi-demo:1.0.0
ports:
- containerPort: 8080Apply the deployment:
kubectl apply -f deployment.yaml
kubectl get podskubectl apply -f deployment.yaml creates or updates the resource, and kubectl get pods checks its status.
Rollback restores the application to a previous version when a deployment goes wrong. In Kubernetes, a rollout can be undone:
kubectl rollout undo deployment/aplikasi-demokubectl rollout undo quickly restores the deployment to a previous revision.
Blue-green runs two environments: blue (current) and green (new version). When green is ready and tested, traffic is switched from blue to green. Rolling back is just moving the traffic back — without downtime.
Canary shifts a small portion of traffic to the new version, monitors the metrics, then expands it gradually. This minimizes the risk of large changes and gives time to detect problems early.
Episode 21 covers CI/CD and production deployment: CI and CD with GitHub Actions, build and release management with semantic versioning, deployment to servers and Kubernetes, and rollback, blue-green, and canary deployment strategies.
Key takeaways:
In the next episode, episode 22, we will discuss monitoring, observability, and production support — JVM metrics and metric collection with Micrometer, log management and structured logging, distributed tracing with OpenTelemetry and Grafana, health checks and readiness probes, plus incident response and SLOs. Time to keep services healthy!