Team Workflow #

Ansible yang dikelola oleh satu orang sangat berbeda secara fundamental dibandingkan dengan Ansible yang dikelola secara kolaboratif oleh seluruh anggota tim. Ketika kita bekerja sendiri, semua asumsi, riwayat konfigurasi, dan logika playbook tersimpan dengan rapi di dalam kepala kita. Namun, begitu tim kita bertambah besar, setiap keputusan konfigurasi yang tidak terdokumentasi dan setiap playbook yang tidak memiliki struktur standar akan berubah menjadi bom waktu. Tanpa adanya kesepakatan workflow yang terstruktur, repository Ansible kita akan berubah menjadi kumpulan kode yang menakutkan—tempat di mana tidak ada satu pun engineer yang berani melakukan modifikasi karena takut akan merusak server di production.

Untuk menghindari skenario tersebut, kita harus memperlakukan konfigurasi infrastruktur sama seperti kita memperlakukan kode aplikasi (Infrastructure as Code atau IaC). Kita membutuhkan strategi branching Git yang disiplin, proses peninjauan kode (code review) yang ketat namun produktif, template Pull Request yang memuat konteks secara mendalam, proses onboarding yang mulus bagi rekan tim yang baru bergabung, serta kumpulan runbook taktis untuk menangani berbagai skenario operasional harian. Dengan mengadopsi standar kolaborasi ini, tim kita dapat bergerak cepat tanpa mengorbankan stabilitas dan keamanan sistem.

Git Branching Strategy untuk Infrastruktur #

Di dalam pengembangan perangkat lunak tradisional, kita sering kali melihat penggunaan strategi branching yang kompleks seperti GitFlow. Namun, untuk pengelolaan infrastruktur berbasis Ansible, strategi yang terlalu rumit justru sering menimbulkan kendala. Infrastruktur memiliki karakteristik yang unik: perubahan di satu bagian kode dapat berdampak langsung pada status sistem yang sedang berjalan secara real-time. Oleh karena itu, strategi branching yang sederhana, transparan, dan terfokus pada pengujian (seperti GitHub Flow) terbukti lebih aman dan efektif untuk tim DevOps.

Berikut adalah gambaran alur kerja branching yang kita gunakan:

flowchart TD
    A["Developer (Lokal)"] -->|"1. Buat Branch Feature"| B["Feature Branch"]
    B -->|"2. Lakukan Push & Buat PR"| C["GitHub / GitLab PR"]
    C -->|"3. CI Pipeline (Lint & Test)"| D{"CI Valid?"}
    D -- "Tidak" -->|"Perbaiki Kode"| B
    D -- "Ya" -->|"4. Code Review & Approval"| E{"Reviewer Setuju?"}
    E -- "Tidak" -->|"Revisi Kode"| B
    E -- "Ya" -->|"5. Squash Merge"| F["Main Branch"]
    F -->|"6. CD Deploy (Staging)"| G["Staging Environment"]
    G -->|"7. Promosi (Production)"| H["Production Environment"]

Di bawah ini adalah aturan main yang harus kita terapkan secara konsisten di seluruh tim:

1. Cabang Utama (Main Branch) #

Cabang main adalah sumber kebenaran tunggal (single source of truth) untuk seluruh status infrastruktur kita.

• Keadaan Selalu Deployable: Kode di cabang main harus selalu berada dalam kondisi stabil dan siap dideploy ke lingkungan staging atau production kapan saja.
• Perlindungan Cabang (Branch Protection): Kita wajib mengaktifkan proteksi cabang pada main di platform Git (seperti GitHub atau GitLab). Anggota tim dilarang keras melakukan push secara langsung ke cabang main.
• Persyaratan Merge: Agar sebuah perubahan dapat digabungkan ke cabang main, kode tersebut harus lolos pemeriksaan otomatis (CI pipeline) dan mendapatkan setidaknya satu persetujuan (approval) dari rekan tim lain setelah melalui proses code review.

2. Cabang Fitur dan Perbaikan (Feature & Fix Branches) #

Setiap kali ingin membuat perubahan—baik itu menambahkan role baru, mengubah parameter konfigurasi, maupun memperbaiki bug—kita wajib membuat cabang baru dari cabang main.

• Konvensi Penamaan: Gunakan nama cabang yang deskriptif dan mencerminkan tujuan perubahan.
  • feature/add-redis-role untuk penambahan komponen atau fitur baru.
  • fix/nginx-ssl-config untuk perbaikan bug atau konfigurasi yang salah.
  • hotfix/critical-security-patch untuk perbaikan darurat yang membutuhkan penanganan secepatnya.
• Masa Hidup yang Singkat: Usahakan agar cabang fitur memiliki masa hidup yang pendek. Kita sebaiknya sering menggabungkan perubahan kecil (frequent commits) daripada menimbun perubahan raksasa dalam satu cabang selama berminggu-minggu, yang hanya akan memicu konflik penggabungan kode (merge conflicts) yang menyakitkan.

3. Kebijakan Penggabungan (Merge Policy) #

Untuk menjaga agar riwayat commit di cabang main tetap bersih dan mudah dibaca, kita menerapkan aturan penggabungan berikut:

• Squash and Merge: Direkomendasikan untuk Pull Request (PR) kecil atau menengah. Metode ini menyatukan semua commit eksperimental dari cabang fitur kita menjadi satu commit tunggal yang bersih di cabang main.
• Merge Commit: Digunakan untuk perubahan arsitektural yang besar yang melibatkan beberapa sub-sistem, sehingga riwayat perubahan yang mendetail tetap terjaga untuk kebutuhan audit di masa mendatang.

Pull Request Template sebagai Komunikasi Konteks #

Masalah utama dalam kolaborasi infrastruktur adalah minimnya informasi mengenai dampak dari perubahan yang diajukan. Seorang reviewer tidak boleh menebak-nebak apa isi dari sebuah playbook atau efek apa yang akan terjadi pada sistem setelah playbook tersebut dijalankan. Untuk menjembatani komunikasi ini, kita wajib menggunakan template Pull Request yang terstandarisasi. Template ini akan memandu penulis PR untuk memaparkan deskripsi perubahan, hasil pengujian lokal, analisis dampak, serta rencana pemulihan jika terjadi kegagalan.

Kita perlu meletakkan berkas template ini di dalam repository di path .github/pull_request_template.md (atau .gitlab/merge_request_templates/default.md jika menggunakan GitLab).

Berikut adalah template Pull Request standar yang harus kita gunakan:

<!-- .github/pull_request_template.md -->

## 📝 Deskripsi Perubahan
<!-- Tulis penjelasan ringkas mengenai apa yang diubah, mengapa perubahan ini diperlukan, dan masalah apa yang sedang kita selesaikan. -->
Contoh: "Mengupgrade konfigurasi TLS pada Nginx untuk mendukung TLS 1.3 dan menonaktifkan TLS 1.0/1.1 demi meningkatkan standar keamanan kepatuhan PCI-DSS."

## 🛠️ Tipe Perubahan
- [ ] Role baru (penambahan komponen infrastruktur baru)
- [ ] Perubahan pada Role yang sudah ada
- [ ] Modifikasi Playbook umum
- [ ] Pembaruan variabel konfigurasi atau file template
- [ ] Perbaikan bug / Hotfix
- [ ] Refactoring (perbaikan struktur kode tanpa mengubah fungsi)

## 🧪 Hasil Pengujian (Testing)
<!-- Buktikan bahwa perubahan ini telah diuji secara lokal atau di lingkungan non-produksi. -->
- [ ] `ansible-lint` telah berjalan secara lokal dan tidak menemukan error/warning.
- [ ] `ansible-playbook --syntax-check` berhasil dieksekusi tanpa kesalahan.
- [ ] Pengujian berbasis Molecule telah dijalankan dan lulus (untuk role yang dimodifikasi).
- [ ] Pengujian manual telah berhasil dilakukan di lingkungan: [sebutkan nama environment, misal: Dev/Staging]
- [ ] Verifikasi idempotensi berhasil (playbook dijalankan dua kali berturut-turut, run kedua menunjukkan `changed=0`).

## ⚡ Dampak & Risiko (Impact Analysis)
- **Lingkungan yang Terdampak:** [ ] Staging  [ ] Production  [ ] Semua Environment
- **Layanan (Service) yang Terdampak:** (Sebutkan service yang disentuh, misal: Nginx, PostgreSQL, daemon aplikasi)
- **Kebutuhan Downtime:** [ ] Ya  [ ] Tidak
  *Jika Ya, estimasikan durasi downtime dan langkah mitigasi:* 
- **Rencana Rollback (Bila Terjadi Masalah):**
  <!-- Jabarkan instruksi langkah-demi-langkah untuk mengembalikan konfigurasi ke status semula sebelum PR ini diaplikasikan. -->
  1. Jalankan playbook rollback dengan tag pemulihan: `ansible-playbook -i inventory/production site.yml --tags rollback-nginx`
  2. Atau revert commit ini di Git, lalu jalankan kembali playbook utama di main branch.

## 📋 Checklist Keamanan & Kualitas Kode
- [ ] Tidak ada informasi sensitif (password, API key, private key) yang ditulis dalam bentuk plaintext. Semua rahasia telah enkripsi menggunakan Ansible Vault.
- [ ] Variabel baru telah didefinisikan dengan nilai default yang aman di dalam folder `defaults/main.yml`.
- [ ] Semua task Ansible telah dilengkapi dengan parameter `name` yang deskriptif dan human-readable.
- [ ] Blok kode `shell` atau `command` telah dilengkapi dengan `changed_when` agar akurasi status idempotensi tetap terjaga.

Dengan memaksa pengisian informasi ini di setiap Pull Request, kita meminimalkan risiko kesalahan operasional akibat asumsi sepihak. Reviewer dapat menilai tingkat risiko perubahan dengan cepat dan memberikan umpan balik yang relevan.

Proses Code Review yang Produktif untuk Ansible #

Code review bukan sekadar formalitas untuk menekan tombol “Approve”. Dalam konteks Infrastructure as Code, code review adalah lini pertahanan pertama kita dalam mencegah pemadaman sistem (outage) di lingkungan production. Ketika kita meninjau kode Ansible milik rekan tim kita, kita tidak sedang mencari siapa yang paling jago menulis kode, melainkan kita bersama-sama memastikan bahwa kode yang akan dieksekusi ke ratusan server adalah kode yang aman, efisien, dan mudah dipahami di masa depan.

Untuk melakukan peninjauan yang produktif, kita harus membagi fokus peninjauan ke dalam empat pilar utama:

1. Kebenaran Teknikal dan Idempotensi #

• Validasi Task Shell/Command: Setiap kali kita melihat penggunaan modul shell atau command, kita harus mencurigai tingkat kelayakannya. Apakah modul bawaan Ansible (seperti template, copy, apt, atau user) bisa digunakan sebagai gantinya? Modul bawaan menjamin stabilitas status sistem, sedangkan script shell kustom sering kali merusak prinsip idempotensi.
• Pengujian Dua Kali (Double Run): Pastikan penulis PR telah memverifikasi bahwa playbook-nya aman untuk dijalankan berulang kali. Jika kita melihat sebuah task memodifikasi berkas konfigurasi dengan cara menambahkan baris teks baru (misalnya menggunakan shell: echo "..." >> /file), tanyakan apakah ada pencegahan duplikasi baris konfigurasi tersebut.
• Penanganan Kegagalan (Error Handling): Periksa bagaimana task menangani kondisi kegagalan. Apakah task tersebut menggunakan blok block, rescue, dan always untuk memastikan proses pembersihan (cleanup) tetap berjalan saat terjadi error?

2. Kepatuhan Keamanan (Security and Secrets) #

• Pencarian Rahasia Bocor: Ini adalah prioritas tertinggi. Kita harus teliti melihat baris-baris kode baru untuk memastikan tidak ada token API, password database, atau private key SSL yang tidak sengaja tertulis langsung di file YAML.
• Gunakan no_log: Pada task yang berurusan dengan data sensitif—seperti pembuatan user baru dengan password default atau interaksi dengan API rahasia—pastikan properti no_log: true telah ditambahkan agar Ansible tidak memuntahkan isi variabel sensitif tersebut ke dalam output log terminal atau server CI.

3. Kemudahan Pemeliharaan (Maintainability) #

• Keterbacaan Variabel: Apakah nama-nama variabel yang digunakan mudah dimengerti? Nama variabel seperti db_port jauh lebih baik daripada variabel generik seperti port yang bisa bertabrakan dengan port web server.
• Dokumentasi Variabel Default: Semua variabel yang digunakan di dalam role harus memiliki nilai default yang terdefinisi dengan baik di defaults/main.yml. Kita juga harus memastikan adanya dokumentasi inline berupa komentar yang menjelaskan fungsi dan tipe data dari masing-masing variabel tersebut.

4. Konsistensi Gaya Penulisan (Code Style) #

• Otomatisasi Linting: Kita tidak boleh menghabiskan energi manusia untuk mendebat masalah spasi, indentasi, atau tanda kutip. Hal-hal kosmetik semacam ini harus sudah diselesaikan oleh ansible-lint dan yamllint di level CI Pipeline. Code review manusia harus fokus pada arsitektur dan logika perubahan.

Mari kita lihat perbedaan antara komentar review yang kurang produktif (anti-pattern) dengan komentar review yang konstruktif dan solutif (benar):

// ANTI-PATTERN: Peninjauan yang tidak memberikan solusi konkret atau subjektif
"Jangan pakai modul shell di sini, cari cara lain."
"Ini berantakan sekali kodenya. Tolong rapikan."

// BENAR: Memberikan alasan teknis yang jelas dan contoh solusi alternatif yang bisa dipakai
"Task ini menggunakan modul 'shell' untuk menginstal package. Demi keamanan dan konsistensi platform, sebaiknya kita menggunakan modul 'apt' bawaan Ansible. Contoh implementasinya:
- name: Pastikan nginx terinstal
  apt:
    name: nginx
    state: present
    update_cache: yes"

Dengan gaya komunikasi yang kolaboratif, proses code review akan dirasakan sebagai sarana belajar bersama untuk meningkatkan keahlian tim, bukan sebagai ajang interogasi yang menegangkan.

Onboarding Engineer Baru secara Sistematis #

Salah satu tolok ukur kesuksesan pengelolaan infrastruktur yang matang adalah seberapa cepat seorang engineer baru dapat berkontribusi di dalam proyek kita. Sering kali, tim membiarkan engineer baru kebingungan mencari tahu cara setup komputer lokal mereka, meminta akses kredensial ke berbagai pihak secara manual, hingga akhirnya tidak sengaja merusak konfigurasi karena minimnya panduan setup yang terstandarisasi.

Kita harus menyediakan alur onboarding yang sistematis yang terbagi ke dalam target mingguan yang jelas. Dengan demikian, proses transisi berjalan aman dan terukur.

Berikut adalah lembar kerja onboarding infrastruktur Ansible yang harus kita berikan kepada setiap rekan tim yang baru bergabung:

Panduan Setup Lingkungan Kerja Lokal (Hari ke-1) #

Rekan tim yang baru bergabung harus mengikuti langkah-langkah setup lingkungan lokal ini untuk memastikan konfigurasi berjalan seragam dengan anggota tim lainnya:

1. Isolasi Lingkungan Python dengan Virtual Environment #

Kita tidak ingin modul Python global bertabrakan dengan dependensi Ansible yang dibutuhkan oleh proyek kita. Oleh karena itu, kita selalu menyarankan penggunaan virtual environment Python.

# Pindah ke direktori kerja utama
cd /Users/unisbadri/Documents/Projects/Repository/Github/badricreativetech/ansible.unisbadri.com

# Buat virtual environment Python baru
python3 -m venv .venv

# Aktifkan virtual environment
source .venv/bin/activate

# Pastikan pip dalam versi terbaru
pip install --upgrade pip

2. Instalasi Dependensi Terstandarisasi #

Kita menginstal ansible-core, ansible-lint, dan alat pengujian lainnya menggunakan berkas requirements.txt yang telah kita commit di Git untuk menjaga konsistensi versi.

# Buat file requirements.txt jika belum ada, lalu install dependensi
pip install ansible-core==2.16.4 ansible-lint==24.2.0 pre-commit==3.6.1 molecule[docker]==24.2.0

3. Konfigurasi Pre-commit Hooks #

Agar kode kita selalu bersih sebelum dikirim ke remote server, kita wajib mengaktifkan pre-commit hooks lokal.

# Inisialisasi konfigurasi pre-commit hooks
pre-commit install

4. Uji Akses Konfigurasi dengan Mode Dry Run #

Setelah berhasil melakukan setup SSH key ke Managed Node dev/staging, jalankan perintah pengujian berikut untuk memastikan semua hak akses lokal telah terkonfigurasi dengan benar tanpa mengubah apa pun di server:

# Jalankan dry-run untuk seluruh konfigurasi staging
ansible-playbook -i inventory/staging/ site.yml --check --diff

Rencana Aktivitas Onboarding (30 Hari Pertama) #

Runbook untuk Skenario Operasional Umum #

Dalam situasi krisis atau saat operasional harian berjalan dengan ritme yang cepat, tim tidak boleh mengandalkan ingatan individu untuk melakukan tugas-tugas kritis. Kita harus mendokumentasikan skenario-skenario operasional yang sering dilakukan dalam bentuk runbook taktis yang siap pakai. Runbook ini berisi panduan alur, perintah CLI yang harus dieksekusi, serta playbook penunjang.

Di bawah ini adalah tiga runbook operasional utama yang sering kita hadapi di lapangan:

Runbook 1: Menambahkan Node Server Baru ke Produksi #

Ketika kita memperluas infrastruktur (scaling out), ikuti alur kerja berikut untuk memasukkan server baru ke dalam manajemen Ansible dengan aman:

Alur Penambahan Node Baru:

flowchart LR
    A["Provisioning VM Baru"] --> B["Catat IP/DNS"]
    B --> C["Daftarkan ke Inventory"]
    C --> D["Uji Ping"]
    D --> E["Dry-Run Playbook"]
    E --> F["Jalankan Playbook (Target Limit)"]

Langkah 1: Daftarkan Host Baru pada Inventory #

Buka berkas inventory produksi kita (misalnya inventory/production/hosts.yml) dan daftarkan server baru di bawah grup yang sesuai. Jangan lupa untuk menyertakan variabel unik jika ada:

# inventory/production/hosts.yml
all:
  hosts:
    web-production-05.company.internal:
      ansible_host: 10.0.1.25
      ansible_user: deploy-user
  children:
    webservers:
      hosts:
        web-production-05.company.internal:

Langkah 2: Uji Koneksi SSH Awal #

Sebelum menjalankan playbook yang kompleks, pastikan Ansible dapat berkomunikasi dengan node baru tersebut menggunakan modul ping bawaan:

# Verifikasi konektivitas ke host baru saja
ansible -i inventory/production/ hosts.yml web-production-05.company.internal -m ping

Langkah 3: Eksekusi Playbook Secara Terbatas (Limit Dry Run) #

Kita tidak boleh menjalankan seluruh playbook untuk semua server jika kita hanya ingin menambahkan satu server baru. Gunakan opsi --limit dan --check untuk memverifikasi perubahan secara spesifik pada server baru:

# Lakukan dry-run terbatas pada server baru
ansible-playbook -i inventory/production/ site.yml \
  --limit web-production-05.company.internal \
  --check --diff

Langkah 4: Terapkan Konfigurasi (Real Run) #

Jika hasil dry-run menunjukkan status perubahan yang sesuai dengan harapan kita, hapus opsi --check untuk menerapkan konfigurasi yang sesungguhnya:

# Terapkan konfigurasi ke server baru
ansible-playbook -i inventory/production/ site.yml \
  --limit web-production-05.company.internal

Runbook 2: Rotasi Kredensial Enkripsi Ansible Vault #

Keamanan infrastruktur menuntut kita untuk melakukan rotasi berkas Vault Password secara berkala. Ikuti panduan berikut untuk melakukan rotasi tanpa merusak ketersediaan data rahasia di repositori kita:

Langkah 1: Siapkan Vault Password Baru #

Buat berkas password baru di luar direktori kerja repositori Git kita. Misalnya, simpan di folder aman di komputer lokal kita:

# Generate password acak baru dan simpan di lokasi aman sementara
openssl rand -base64 32 > ~/.ansible_vault_key_new

Langkah 2: Rekonstruksi Enkripsi Menggunakan Password Baru #

Ansible menyediakan utilitas bawaan ansible-vault rekey untuk mengubah password enkripsi file tanpa perlu mendekripsinya ke plaintext terlebih dahulu. Jalankan perintah ini untuk berkas berkas variabel rahasia kita:

# Rekey file rahasia dengan memasukkan file password lama dan menunjuk file password baru
ansible-vault rekey \
  --vault-password-file ~/.ansible_vault_key_old \
  --new-vault-password-file ~/.ansible_vault_key_new \
  inventory/production/group_vars/all/vault.yml

Langkah 3: Update Konfigurasi Vault Password di Sistem CI/CD #

Jangan lupa untuk memperbarui nilai environment variable ANSIBLE_VAULT_PASSWORD di Jenkins, GitHub Actions, atau GitLab CI/CD kita dengan nilai password baru yang baru saja kita buat. Setelah berhasil, hapus berkas password sementara di laptop lokal kita:

# Hapus file password sementara demi keamanan
rm ~/.ansible_vault_key_new

Runbook 3: Emergency Rollback Menggunakan Tag Khusus #

Ketika sebuah perubahan konfigurasi di produksi menimbulkan kendala yang tidak terduga, kita membutuhkan respons cepat untuk mengembalikan status sistem ke kondisi stabil. Alih-alih melakukan pemecahan masalah (debugging) di server produksi saat sistem sedang mati, lebih aman untuk melakukan rollback konfigurasi terlebih dahulu.

Kita dapat merancang playbook kita untuk mendukung tag pemulihan darurat (rollback) pada tugas-tugas konfigurasi krusial:

# playbooks/roles/nginx/tasks/main.yml
---
- name: Salin file konfigurasi Nginx utama
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    backup: yes  # Menyimpan file lama dengan timestamp (misal: nginx.conf.XXXX~)
  notify: Reload nginx
  tags: nginx_config

- name: Restore konfigurasi cadangan darurat (Rollback)
  shell: |
    latest_backup=$(ls -t /etc/nginx/nginx.conf.*~ 2>/dev/null | head -n 1)
    if [ -n "$latest_backup" ]; then
      cp "$latest_backup" /etc/nginx/nginx.conf
      nginx -t && systemctl reload nginx
    else
      echo "Tidak ada file backup cadangan yang ditemukan!" && exit 1
    fi    
  when: trigger_rollback | default(false) | bool
  tags: rollback_nginx

Untuk mengeksekusi rollback darurat ini ke server yang bermasalah, jalankan perintah berikut:

# Paksa eksekusi tugas rollback Nginx di grup server web produksi
ansible-playbook -i inventory/production/ site.yml \
  --limit webservers \
  --tags rollback_nginx \
  -e "trigger_rollback=true"

Dengan menyediakan strategi pemulihan instan seperti ini, kita mengurangi waktu henti layanan (downtime) secara drastis saat terjadi insiden tak terduga.

Membangun Budaya Infrastructure as Code yang Berkelanjutan #

Alat dan teknologi hanyalah instrumen penunjang; keberhasilan sesungguhnya dari pengelolaan infrastruktur terletak pada budaya tim yang mengoperasikannya. Untuk memastikan codebase Ansible kita tetap sehat dan relevan dalam jangka panjang, kita harus menumbuhkan beberapa kebiasaan baik berikut di dalam tim kita:

1. Boy Scout Rule untuk Infrastruktur #

Biasakan untuk selalu meninggalkan kode dalam kondisi yang lebih baik daripada saat kita pertama kali menemukannya. Jika kita sedang membaca playbook untuk menambahkan tugas baru, dan kita menemukan ada task lama yang tidak memiliki nama deskriptif atau menggunakan sintaksis yang sudah usang, luangkan waktu 5 menit untuk memperbaikinya di dalam Pull Request kita. Perubahan kecil yang konsisten ini akan mencegah akumulasi hutang teknis di kemudian hari.

2. Tulis ADR (Architecture Decision Records) #

Setiap kali tim membuat keputusan arsitektur yang besar—seperti beralih dari satu modul database ke modul lain, mengubah struktur direktori utama, atau menetapkan standar penamaan variabel baru—dokumentasikan keputusan tersebut ke dalam file markdown sederhana di folder docs/adr/. Dokumentasi ini akan menjadi panduan sejarah yang sangat berharga bagi anggota tim di masa mendatang untuk memahami mengapa infrastruktur kita dibangun dengan cara tertentu.

3. Sesi Peer-Programming dan Rotasi Tugas #

Jangan biarkan satu orang memonopoli pengetahuan tentang satu role atau playbook tertentu (misalnya, hanya si A yang tahu cara mengelola kluster database). Lakukan sesi peer-programming secara berkala dan rotasikan tanggung jawab penanganan tiket pemeliharaan. Semakin merata pemahaman anggota tim terhadap codebase infrastruktur, semakin tangguh tim kita menghadapi situasi darurat.

Ringkasan #

• Git Branching Sederhana — Gunakan strategi branching berbasis GitHub Flow (cabang fitur pendek langsung digabungkan ke cabang main melalui Pull Request) untuk menghindari konflik penggabungan kode yang rumit.
• Template PR Wajib — Terapkan template Pull Request yang komprehensif di repositori untuk memaksa pemaparan analisis risiko, metode pengujian, serta rencana rollback yang jelas sebelum kode di-review.
• Review Kode yang Objektif — Fokuskan proses code review pada pilar kebenaran teknis, idempotensi, kepatuhan keamanan, dan kemudahan pemeliharaan. Hindari mendebat gaya penulisan kosmetik secara manual di PR; serahkan hal tersebut pada linter otomatis.
• Onboarding yang Terarah | Sediakan panduan setup lokal yang terisolasi menggunakan virtual environment Python, pre-commit hooks, dan requirements.txt yang terstandarisasi agar rekan tim baru dapat berkontribusi dengan aman sejak minggu pertama.
• Runbook Siap Pakai — Dokumentasikan skenario operasional krusial seperti penambahan server baru, rotasi berkas Vault, dan penanganan pemulihan darurat dalam bentuk langkah-langkah CLI yang siap dieksekusi oleh siapa saja yang sedang bertugas.
• Bina Budaya Berkelanjutan — Terapkan prinsip Boy Scout Rule pada kode infrastruktur, tulis berkas Architecture Decision Records (ADR) untuk setiap keputusan besar, dan lakukan rotasi pengetahuan antar anggota tim secara berkala.

← Sebelumnya: Testing Strategy   Berikutnya: Production Readiness →