Best Practice Github Action Untuk Manjemen Release
1. Struktur Proyek
my-go-api/
βββ .github/
β βββ workflows/
β βββ ci.yml # CI untuk setiap push/PR
β βββ release.yml # Release saat tag dibuat
β βββ tag.yml # Auto-tagging untuk main branch
βββ cmd/
β βββ server/
β βββ main.go # Entry point aplikasi
βββ internal/
β βββ config/ # Konfigurasi aplikasi
β βββ handler/ # HTTP handlers
β βββ middleware/ # Middleware
β βββ version/ # Package untuk version management
β βββ version.go # File version variables
βββ pkg/ # Public packages
β βββ logger/
βββ go.mod # Go modules
βββ go.sum # Go modules checksums
βββ Dockerfile # Docker image build
βββ .dockerignore # File diabaikan Docker build
βββ README.md # DokumentasiPenjelasan:
Struktur ini mengikuti Standard Go Project Layout
internal/untuk kode private yang tidak bisa diakses dari luarcmd/untuk entry point aplikasipkg/untuk kode yang bisa digunakan oleh proyek lain.github/workflows/untuk GitHub Actions workflows
2. Setup Version di Golang
Penjelasan:
Version variables di-set pada build time menggunakan
ldflagsDefault values untuk development mode
Runtime access ke version info untuk debugging dan monitoring
Full version format:
v1.0.0-abc123 (2024-01-15T10:30:00Z)
3. Docker Multi-Stage Build
Penjelasan:
Multi-stage build mengurangi image size dari ~800MB ke ~20MB
Stage 1: Build environment dengan Go dependencies
Stage 2: Runtime environment hanya dengan binary dan certificates
CGO_ENABLED=0 untuk static linking
Version injection via ldflags untuk build-time variables
4. .dockerignore
Penjelasan:
Mengurangi build context size yang dikirim ke Docker daemon
Mencegah cache invalidation yang tidak perlu
Keamanan dengan tidak menyertakan sensitive files
Optimasi build speed dengan mengabaikan development files
5. GitHub Actions CI Workflow
Penjelasan:
Trigger conditions: Push ke main/develop branches dan PR ke main
Parallel jobs: Test dan build berjalan parallel jika memungkinkan
Dependency management: Build job hanya run jika tests pass
Multi-platform builds: Support untuk AMD64 dan ARM64
Smart tagging: Tag otomatis berdasarkan branch, PR, dan commit
Security: Docker login via secrets, bukan hardcoded credentials
6. GitHub Actions Release Workflow
Penjelasan:
Trigger: Hanya saat tag baru dibuat (v1.0.0, v1.0.1, etc.)
Changelog generation: Otomatis dari commit messages
GitHub release: Create release dengan changelog
Docker tagging: Tag image dengan version number
Version injection: Use tag name as application version
7. Semantic Versioning dengan Conventional Commits
Penjelasan:
Conventional Commits: Format commit messages yang terstruktur
Automatic versioning:
featβ minor bump,fixβ patch bump,BREAKING CHANGEβ major bumpChangelog generation: Otomatis dari commit history
Grouping: Commits dikelompokkan berdasarkan type (feat, fix, docs, etc.)
8. Workflow untuk Automated Tagging
Penjelasan:
Semantic-release: Analisa commit messages untuk menentukan version bump
Automatic tagging: Membuat tag baru berdasarkan conventional commits
Changelog update: Update CHANGELOG.md otomatis
GitHub release: Create release notes otomatis
9. Kapan Membuat Tag Baru - JAWABAN PERTANYAAN UTAMA
β TIDAK, setiap push TIDAK membuat tag baru!
Kapan tag baru dibuat:
Push ke main branch dengan conventional commits
feat: add new featureβ Memicu minor version bump (v1.0.0 β v1.1.0)fix: resolve bugβ Memicu patch version bump (v1.0.0 β v1.0.1)feat: add breaking change+BREAKING CHANGE:β Major bump (v1.0.0 β v2.0.0)
Manual tag creation
Schedule-based releases
Setup workflow untuk release setiap 2 minggu
Contoh conventional commits:
Flow kerja:
Development: Push ke
developbranch β CI tests onlyMerge to main: Push ke
maindengan conventional commits β Auto-tagging + releaseManual override: Bisa buat tag manual jika perlu
10. Kapan Harus Release
Release Schedule:
Patch releases: Setiap 1-2 minggu (bug fixes, security patches)
Minor releases: Setiap 4-6 minggu (new features)
Major releases: Setiap 3-6 bulan (breaking changes)
Release Checklist:
11. Environment Variables untuk Build
Development:
Production (GitHub Actions):
12. Best Practices Tambahan
1. Multi-Platform Builds
2. Caching Strategy
3. Security Scanning
4. Slack Notifications
13. Setup Secrets di GitHub
Required Secrets:
DOCKER_USERNAME: Docker Hub username
DOCKER_PASSWORD: Docker Hub access token
GH_TOKEN: GitHub personal access token (untuk semantic-release)
SLACK_WEBHOOK: Slack incoming webhook (optional)
Setup Instructions:
Go to repository β Settings β Secrets and variables β Actions
Click "New repository secret"
Add each secret with proper permissions
14. Contoh Penggunaan Version di Code
15. Testing Setup
Unit Tests:
Integration Tests:
Test Workflow:
Summary Workflow
Development Flow:
Feature branch: Push ke
developβ CI tests onlyPull Request: PR ke
mainβ Full CI + checksMerge to main: Auto-tagging + release jika conventional commits
Production deployment: Auto-deploy dari release
Key Points:
β Tidak setiap push buat tag baru - hanya conventional commits ke main
β Semantic versioning otomatis berdasarkan commit messages
β Multi-platform Docker builds untuk production
β Version injection ke binary untuk debugging
β Security scanning dan quality checks
β Industry best practices dari Google, Uber, dll.
Setup ini memberikan fully automated CI/CD pipeline yang mengikuti best practices industri untuk Go applications! π
Last updated