Team Workflow #
Ansible yang digunakan oleh satu orang berbeda fundamental dari Ansible yang digunakan oleh tim. Satu orang bisa menyimpan konteks di kepalanya; tim perlu konvensi yang jelas, proses review yang konsisten, dan dokumentasi yang memungkinkan siapapun memahami dan berkontribusi. Tanpa workflow yang terstruktur, repository Ansible akan menjadi kumpulan playbook yang tidak ada yang berani diubah karena tidak ada yang tahu efek sampingnya.
Git Branching Strategy #
Untuk infrastruktur Ansible, strategi yang sederhana biasanya lebih baik:
main (atau master)
↑
├── feature/add-redis-role ← Fitur baru atau perubahan besar
├── fix/nginx-ssl-config ← Perbaikan bug
└── hotfix/critical-security-patch ← Patch darurat yang bypass review normal
Aturan untuk branch main:
- Selalu bisa di-deploy ke staging kapan saja
- Semua PR harus passing: lint + syntax check + Molecule test
- Minimal satu approval dari reviewer lain
- Squash merge untuk PR kecil, merge commit untuk PR besar
Branch protection rules di GitHub/GitLab:
- Require pull request reviews (min 1 reviewer)
- Require status checks to pass (CI pipeline)
- Require up-to-date branches before merging
- Restrict pushes directly to main
Pull Request Template #
Template PR yang konsisten memastikan reviewer punya informasi yang cukup:
<!-- .github/pull_request_template.md -->
## Deskripsi Perubahan
<!-- Jelaskan apa yang berubah dan mengapa -->
## Tipe Perubahan
- [ ] Role baru
- [ ] Perubahan role yang ada
- [ ] Perubahan playbook
- [ ] Perubahan konfigurasi
- [ ] Perbaikan bug
- [ ] Refactoring
## Testing
- [ ] ansible-lint passed
- [ ] Syntax check passed
- [ ] Molecule test passed (jika mengubah role)
- [ ] Ditest manual di staging/dev: <!-- tulis environment dan hasilnya -->
## Dampak
- **Environment yang terdampak:** <!-- staging / production / semua -->
- **Service yang terdampak:** <!-- nginx / postgresql / semua -->
- **Perlu downtime?** <!-- Ya/Tidak, jika Ya berapa lama -->
- **Cara rollback jika bermasalah:** <!-- langkah rollback -->
## Checklist
- [ ] Tidak ada secret plaintext
- [ ] Semua variabel terdokumentasi di defaults/main.yml
- [ ] Idempoten (ditest dengan menjalankan dua kali)
- [ ] Changelog diupdate jika ini perubahan signifikan
Proses Code Review yang Produktif #
Reviewer harus memeriksa:
1. KEBENARAN TEKNIKAL
- Apakah logika benar untuk semua kasus?
- Apakah ada edge case yang tidak dihandle?
- Apakah idempoten?
2. KEAMANAN
- Tidak ada secret plaintext?
- Privilege minimal?
- no_log untuk task sensitif?
3. MAINTAINABILITY
- Bisa dipahami 6 bulan dari sekarang?
- Nama variabel dan task sudah deskriptif?
- Tidak ada duplikasi yang seharusnya jadi shared role?
4. KONSISTENSI
- Mengikuti konvensi project?
- Struktur direktori sesuai?
- Style YAML konsisten?
Yang BUKAN tanggung jawab reviewer:
- Memastikan kode "sempurna" sebelum merge
- Memblok PR karena preferensi personal (bukan karena masalah nyata)
- Mereview setiap baris — fokus pada perubahan yang signifikan
Onboarding Engineer Baru #
Checklist onboarding yang komprehensif:
## Onboarding Checklist — Ansible Infrastructure
### Hari 1: Setup Lingkungan
- [ ] Clone repository
- [ ] Install Python dan Ansible (versi di README)
- [ ] Setup SSH key untuk akses managed node
- [ ] Minta akses ke vault password staging
- [ ] Jalankan: `ansible-playbook -i inventory/staging/ site.yml --check`
(harus berhasil tanpa error)
### Minggu 1: Pemahaman Project
- [ ] Baca README.md dan ADR (Architecture Decision Records) jika ada
- [ ] Ikuti pairing session dengan anggota tim untuk review role utama
- [ ] Buat PR kecil pertama (dokumentasi atau perbaikan kecil)
- [ ] Jalankan Molecule test untuk satu role secara lokal
### Minggu 2-4: Kontribusi
- [ ] Ambil task dari backlog yang sudah ada
- [ ] Shadow deployment ke staging minimal sekali
- [ ] Buat role baru atau update role yang ada dengan code review
Runbook untuk Skenario Umum #
Dokumentasikan prosedur yang sering dilakukan:
## Runbook: Menambahkan Server Baru ke Production
### Prasyarat
- Server sudah di-provision dengan OS yang sesuai
- IP sudah diketahui
- SSH key sudah terpasang
### Langkah-langkah
1. Tambahkan server ke inventory:
```
# inventory/production/hosts.ini
[webservers]
web-05.company.internal ansible_host=10.0.1.5
```
2. Test konektivitas:
```bash
ansible -i inventory/production/ web-05.company.internal -m ping
```
3. Dry run (mandatory sebelum apply):
```bash
ansible-playbook -i inventory/production/ site.yml \
--limit web-05.company.internal \
--check --diff
```
4. Terapkan konfigurasi:
```bash
ansible-playbook -i inventory/production/ site.yml \
--limit web-05.company.internal
```
5. Verifikasi server sehat:
```bash
ansible -i inventory/production/ web-05.company.internal \
-m uri -a "url=http://localhost:8080/health"
```
6. Tambahkan ke load balancer (jika applicable):
```bash
ansible-playbook -i inventory/production/ add-to-lb.yml \
-e "new_server=web-05.company.internal"
```
Ringkasan #
- Git branching yang sederhana lebih baik dari yang kompleks untuk infrastruktur — feature branch → main dengan PR adalah cukup untuk sebagian besar tim.
- PR template memastikan setiap PR punya konteks yang cukup: apa yang berubah, sudah ditest apa, dampaknya ke mana, cara rollback-nya bagaimana.
- Code review yang baik fokus pada kebenaran, keamanan, dan maintainability — bukan preferensi style personal. Reviewer blok PR hanya untuk masalah nyata, bukan perbedaan pendapat tentang cara yang “lebih elegan”.
- Onboarding checklist yang konkret lebih efektif dari dokumentasi panjang — engineer baru harus bisa setup dan berkontribusi dalam satu minggu.
- Runbook untuk skenario umum (tambah server, rotasi secret, patch emergency) mendokumentasikan pengetahuan tribal yang biasanya hanya ada di kepala satu orang.
- Budaya yang sehat: PR kecil yang sering lebih baik dari PR besar yang jarang — lebih mudah di-review, lebih mudah di-rollback, lebih sedikit konflik merge.
← Sebelumnya: Testing Strategy Berikutnya: Production Readiness →