Release Document #
Semakin cepat tim merilis, semakin penting dokumentasi rilis menjadi. Di lingkungan Agile yang merilis setiap sprint, tidak ada yang bisa mengingat semua perubahan yang terjadi — apalagi saat incident terjadi tengah malam dan kamu perlu tahu dengan cepat apa yang berubah sejak deployment terakhir. Release document adalah jawaban untuk itu: satu dokumen per sprint yang merangkum apa yang berubah, di mana, mengapa, dan apa yang harus dilakukan jika ada masalah. Bukan formalitas administratif — ia adalah alat survival tim engineering yang merilis secara rutin. Artikel ini membahas apa yang harus ada di release document, bagaimana membuatnya efektif, dan anti-pattern yang membuat release document tidak berguna.
Apa Itu Release Document Per Sprint? #
Release document per sprint adalah dokumen yang dibuat setiap akhir sprint — atau lebih tepatnya sebelum deployment ke environment tertentu — yang merangkum secara jelas apa saja yang berubah, komponen sistem mana yang terdampak, risiko yang perlu dimonitor, dan cara rollback jika terjadi masalah.
Kata kuncinya adalah per sprint. Bukan dokumen tahunan, bukan changelog yang diakumulasi dari banyak sprint, melainkan satu dokumen yang merepresentasikan satu unit rilis. Ini penting karena:
Release document yang terlalu jarang (per kuartal, per versi besar):
✗ Saat incident, sulit menentukan perubahan mana yang menjadi penyebab
✗ Dokumen terlalu panjang, tidak ada yang baca sampai selesai
✗ Engineer lupa konteks perubahan yang sudah dibuat 3 bulan lalu
Release document per sprint:
✓ Scope kecil dan terfokus — mudah dibaca dan dipahami
✓ Saat incident, langsung bisa dicocokkan dengan sprint yang baru deploy
✓ Engineer masih ingat konteks saat menulis dokumen
✓ Arsip sprint-per-sprint membangun sejarah sistem yang bisa ditelusuri
Release document bukan design doc, bukan RFC, dan bukan commit log. Ia adalah jembatan antara “apa yang dikerjakan tim” dan “apa yang perlu diketahui semua pihak yang terlibat” — mulai dari engineer on-call yang perlu debug di malam hari, QA yang perlu tahu area regression, sampai PM yang perlu update ke stakeholder.
Komponen Wajib Release Document #
Header dan Metadata #
Setiap release document dimulai dengan informasi dasar yang memudahkan pengelompokan dan pencarian:
# Release Document — Sprint 42
**Release Date:** 2026-01-27
**Environment:** Production
**Release Owner:** [Nama Engineer / Tech Lead]
**Status:** ✓ Released | ⚠ Partial | ✗ Rolled Back
**Link Sprint Board:** [URL ke Jira/Linear/GitHub Projects]
**Link RFC (jika ada):** [URL ke RFC terkait sprint ini]
Kolom “Status” sering dilupakan tapi sangat berguna saat menelusuri riwayat — kamu bisa langsung tahu sprint mana yang pernah di-rollback hanya dari daftar dokumen.
Apa Saja yang Dideploy #
Ini adalah bagian paling penting dan paling sering ditulis dengan buruk. Changelog yang baik bukan dump commit message — ia menjelaskan dampak perubahan, bukan detail implementasi.
New Features #
Fitur baru yang sebelumnya tidak ada di sistem:
## New Features
### Export Laporan Bulanan
- **Service:** `report-service`
- **Komponen:** API, Background Worker
- **Deskripsi:** User bisa mengekspor laporan penjualan bulanan ke format
Excel dan CSV. Proses export dilakukan secara async — user mendapat
notifikasi email saat file siap diunduh.
- **Catatan QA:** Perlu verifikasi edge case export bulan dengan 0 transaksi
dan bulan dengan >10.000 baris data.
Behavior Changes #
Perubahan pada logika atau perilaku yang sudah ada sebelumnya — ini adalah kategori yang paling sering menjadi penyebab regresi dan paling penting untuk didokumentasikan dengan jelas:
## Behavior Changes
### Validasi Status Order Sebelum Payment
- **Service:** `order-service`
- **Komponen:** API
- **Sebelumnya:** Payment bisa diproses untuk order dengan status apapun
- **Sesudahnya:** Payment hanya bisa diproses untuk order berstatus
`confirmed`. Order dengan status lain akan mengembalikan error 422.
- **Dampak ke sistem lain:** `payment-service` perlu menangani error 422
baru ini — sudah dikomunikasikan ke tim payment.
- **Dampak ke user:** User yang punya order lama dengan status `pending`
perlu mengkonfirmasi order terlebih dahulu sebelum bisa membayar.
Behavior changes adalah kategori paling rawan yang sering diremehkan. Perubahan sekecil apapun pada validasi, default value, atau urutan operasi bisa berdampak ke service lain yang bergantung pada behavior lama. Selalu cantumkan “Sebelumnya” dan “Sesudahnya” secara eksplisit untuk setiap behavior change, dan identifikasi siapa yang terdampak.
Bug Fixes #
Bug yang diperbaiki beserta konteksnya — ini membantu QA melakukan targeted regression testing:
## Bug Fixes
### Fix: Race Condition saat Update Status Order
- **Service:** `order-service`
- **Komponen:** API, Database Transaction
- **Deskripsi:** Request update status order yang concurrent bisa
menyebabkan status akhir yang tidak konsisten. Fix menggunakan
pessimistic locking di level database.
- **Cara reproduksi (sebelum fix):** Kirim 2 request PATCH /orders/:id
secara bersamaan dengan status berbeda.
- **Verifikasi:** Unit test ditambahkan untuk concurrent update scenario.
### Fix: Notifikasi Email Terkirim Dua Kali
- **Service:** `notification-service`
- **Komponen:** Background Worker
- **Deskripsi:** Job retry yang tidak idempotent menyebabkan email terkirim
dua kali jika worker crash setelah kirim tapi sebelum update status job.
Fix dengan menambahkan idempotency key di level email provider.
Technical dan Infrastructure Changes #
Perubahan non-fungsional yang tidak terlihat oleh user tapi tetap perlu diketahui tim — terutama tim infra dan engineer on-call:
## Technical / Infrastructure Changes
### Penambahan Index pada Tabel `orders`
- **Service:** `order-service`
- **Komponen:** Database
- **Detail:** Index composite pada `(user_id, status, created_at)` untuk
query listing orders per user yang saat ini full table scan.
- **Catatan migration:** Index dibuat dengan `CREATE INDEX CONCURRENTLY`
— tidak ada locking, tidak ada downtime yang diperkirakan.
- **Estimasi waktu migration:** ~15 menit untuk tabel dengan 2.3 juta baris.
### Update Timeout Background Worker
- **Service:** `payment-worker`
- **Komponen:** Background Job
- **Detail:** Timeout per job dinaikkan dari 30 detik menjadi 90 detik.
Beberapa payment gateway membutuhkan lebih dari 30 detik untuk merespons
di jam peak.
- **Monitoring:** Alert akan dipicu jika ada job yang mendekati 90 detik.
Impact Summary #
Setelah semua perubahan dilist per kategori, tambahkan ringkasan dampak untuk memudahkan on-call engineer dan QA mengetahui area yang perlu diperhatikan:
## Impact Summary
### Services yang Terdampak
- `order-service` — new feature, behavior change, bug fix, DB migration
- `report-service` — new feature
- `notification-service` — bug fix
- `payment-worker` — infra change
### Komponen Sistem yang Terdampak
- API: order-service, report-service
- Background Worker: report-service, payment-worker
- Database: order-service (migration)
- Email Provider: notification-service
### Tidak Ada Perubahan di Sprint Ini
- `user-service`
- `auth-service`
- `analytics-service`
Bagian “Tidak Ada Perubahan” sering dianggap tidak perlu — padahal justru sangat berguna. Saat debugging incident, mengetahui service mana yang tidak berubah mempersempit area investigasi secara signifikan.
Database Migration Notes #
Setiap perubahan database layak mendapat perhatian khusus karena dampaknya bisa paling sulit di-rollback dan paling berpotensi menyebabkan downtime:
## Database Migration Notes
| Migration | Service | Type | Backward Compatible | Estimasi Durasi | Risiko |
|---|---|---|---|---|---|
| Add index `orders(user_id, status, created_at)` | order-service | DDL | Ya | ~15 menit | Rendah |
| Add kolom `idempotency_key` ke `email_logs` | notification-service | DDL | Ya | < 1 menit | Rendah |
### Urutan Eksekusi Migration
Migration harus dijalankan dalam urutan berikut sebelum deployment:
1. `order-service`: index creation (bisa berjalan concurrent dengan production)
2. `notification-service`: tambah kolom (instant, tidak ada data migration)
### Catatan Rollback Database
- Index bisa di-drop tanpa dampak fungsional jika perlu rollback
- Kolom `idempotency_key` bisa diisi NULL — tidak ada data yang hilang jika di-drop
Risiko dan Rollback Plan #
Setiap release punya risiko — mendokumentasikannya bukan tanda bahwa kamu tidak percaya diri, melainkan tanda kematangan engineering. Dokumen ini akan sangat berharga di jam-jam pertama setelah deployment:
## Risiko dan Area yang Perlu Dimonitor
### Risiko 1: Behavior Change Validasi Order (Medium)
- **Potensi masalah:** Order lama dengan status tidak valid bisa
menyebabkan confusion jika user mencoba membayar
- **Yang perlu dimonitor:** Error rate endpoint `POST /payments`
— alert jika >1% dalam 30 menit pertama setelah deployment
- **Tanda bahaya:** Spike error 422 yang tidak proporsional
### Risiko 2: Migration Index (Rendah)
- **Potensi masalah:** `CREATE INDEX CONCURRENTLY` bisa gagal
jika ada long-running transaction di tabel `orders`
- **Yang perlu dimonitor:** Progress migration di DB monitoring dashboard
- **Tanda bahaya:** Migration berjalan >30 menit
## Rollback Plan
### Rollback Aplikasi
Estimasi waktu rollback: **< 5 menit**
```bash
# Rollback ke image versi sebelumnya
kubectl set image deployment/order-service \
order-service=gcr.io/project/order-service:v1.41.0
kubectl set image deployment/report-service \
report-service=gcr.io/project/report-service:v1.41.0
Rollback Database #
| Migration | Rollback Command | Aman? |
|---|---|---|
| Index orders | DROP INDEX CONCURRENTLY idx_orders_user_status_created | Ya, tidak ada data hilang |
| Kolom idempotency_key | ALTER TABLE email_logs DROP COLUMN idempotency_key | Ya, kolom masih kosong |
Urutan Rollback #
- Rollback aplikasi terlebih dahulu (semua service sekaligus)
- Verifikasi traffic kembali normal
- Rollback database hanya jika diperlukan (kolom baru tidak merusak kode lama)
---
### Deployment Steps
Untuk deployment yang melibatkan migration atau urutan tertentu, cantumkan langkah-langkah yang harus diikuti:
```markdown
## Deployment Steps
### Pre-Deployment (sebelum push ke production)
- [ ] Migration sudah dijalankan di staging dan verified
- [ ] Smoke test di staging lulus semua
- [ ] Tim on-call sudah di-notify tentang jadwal deployment
- [ ] Monitoring dashboard dibuka di tab terpisah
### Deployment Order
1. Deploy `notification-service` (tidak ada dependency ke service lain)
2. Jalankan DB migration `order-service`
3. Deploy `order-service` (setelah migration selesai)
4. Deploy `report-service`
5. Deploy `payment-worker`
### Post-Deployment Verification (15 menit pertama)
- [ ] Cek error rate semua service di monitoring
- [ ] Cek latency P95 endpoint kritis: /orders, /payments
- [ ] Verifikasi migration index sudah aktif (cek query plan)
- [ ] Test manual: buat order baru dan lakukan payment
- [ ] Verifikasi email notifikasi terkirim (cek email provider dashboard)
Template Lengkap Release Document #
Berikut template yang bisa langsung disalin dan digunakan:
# Release Document — Sprint [NUMBER]
**Release Date:** YYYY-MM-DD
**Environment:** Staging | Production
**Release Owner:** [Nama]
**Status:** ✓ Released | ⚠ Partial | ✗ Rolled Back
**Sprint Board:** [URL]
**RFC terkait:** [URL atau "Tidak ada RFC sprint ini"]
---
## New Features
### [Nama Fitur]
- **Service:** `nama-service`
- **Komponen:** API | Worker | DB | Cache
- **Deskripsi:** [Apa yang berubah dari perspektif user/sistem]
- **Catatan QA:** [Edge case atau area yang perlu dites]
---
## Behavior Changes
### [Nama Perubahan]
- **Service:** `nama-service`
- **Komponen:** [komponen]
- **Sebelumnya:** [perilaku lama]
- **Sesudahnya:** [perilaku baru]
- **Dampak ke sistem lain:** [service lain yang terdampak]
- **Dampak ke user:** [apa yang berubah bagi pengguna, jika ada]
---
## Bug Fixes
### Fix: [Deskripsi Bug]
- **Service:** `nama-service`
- **Komponen:** [komponen]
- **Deskripsi:** [penjelasan bug dan cara fix-nya]
---
## Technical / Infrastructure Changes
### [Nama Perubahan]
- **Service:** `nama-service`
- **Komponen:** [komponen]
- **Detail:** [penjelasan teknis singkat]
- **Catatan:** [hal penting yang perlu diketahui tim infra/on-call]
---
## Impact Summary
**Services terdampak:** `service-a`, `service-b`
**Komponen terdampak:** API, Database, Worker
**Services tidak berubah:** `service-c`, `service-d`
---
## Database Migration Notes
| Migration | Service | Backward Compatible | Estimasi Durasi | Risiko |
|---|---|---|---|---|
| [nama migration] | [service] | Ya / Tidak | [durasi] | Rendah / Medium / Tinggi |
---
## Risiko dan Rollback Plan
### Risiko
- **[Nama risiko]** (Level: Rendah/Medium/Tinggi)
- Yang perlu dimonitor: [metric dan threshold]
### Rollback Aplikasi
Estimasi waktu: [X menit]
[perintah rollback]
### Rollback Database
[tabel rollback migration]
---
## Deployment Steps
### Pre-Deployment
- [ ] [langkah persiapan]
### Deployment Order
1. [urutan deployment]
### Post-Deployment Verification
- [ ] [langkah verifikasi]
Best Practice Menulis Release Document #
1. Tulis Saat Masih Segar, Bukan Setelah Deployment #
Release document yang ditulis terburu-buru sesaat sebelum deployment cenderung tidak akurat dan kurang detail. Idealnya ditulis secara incremental selama sprint berlangsung.
// ✗ Anti-pattern: Ditulis H-1 deployment
"Ah nanti aja, buat release doc kalau mau deploy besok"
→ Banyak perubahan terlupakan, detail tidak akurat,
rollback plan tidak difikirkan matang
// ✓ Ditulis incremental selama sprint
Sprint hari ke-3: Story pertama Done → entry changelog ditulis
Sprint hari ke-7: Bug fix Done → entry ditambahkan
Sprint hari ke-9: Review dan lengkapi bagian risiko + rollback plan
Sprint hari ke-10: Final check sebelum deployment
2. Changelog Berdasarkan Dampak, Bukan Implementasi #
Kesalahan paling umum adalah meng-copy-paste commit message sebagai changelog. Commit message ditulis untuk developer yang memerlu konteks implementasi — release document ditulis untuk semua orang yang perlu tahu apa yang berubah di sistem.
// ✗ Changelog berbasis commit message (tidak berguna):
- "refactor: extract payment validation to service layer"
- "fix: update nil pointer dereference in order handler"
- "feat: add goroutine pool for concurrent export processing"
- "chore: bump dependencies"
// ✓ Changelog berbasis dampak (berguna untuk semua audience):
Bug Fixes:
- Fix: Crash pada endpoint GET /orders saat user tidak punya order aktif
→ Service: order-service | Ditemukan di: production log | Frekuensi: ~2x per hari
New Features:
- Export laporan sekarang diproses secara parallel — waktu export untuk
10.000 baris turun dari 45 detik menjadi ~12 detik
→ Service: report-service
3. Behavior Changes Wajib Eksplisit #
Ini adalah bagian yang paling sering dilewatkan dan paling sering menjadi sumber kebingungan saat incident. Setiap perubahan pada logika bisnis, validasi, default value, atau urutan operasi harus didokumentasikan dengan format “sebelumnya → sesudahnya”.
// ✗ Behavior change yang tidak jelas:
"Update validasi order"
// ✓ Behavior change yang eksplisit:
Validasi Status Order:
Sebelumnya: Semua status order bisa dilanjutkan ke payment
Sesudahnya: Hanya order dengan status 'confirmed' yang bisa dibayar
Dampak: Order dengan status 'pending' perlu di-confirm dulu
4. Rollback Plan Harus Bisa Dieksekusi oleh Orang Lain #
Rollback plan yang ditulis “nanti dipikirin kalau ada masalah” tidak berguna. Rollback plan yang ditulis dengan asumsi hanya kamu yang bisa mengeksekusinya juga tidak berguna — incident sering terjadi saat yang paling familiar dengan sistem sedang tidak available.
// ✗ Rollback plan yang tidak actionable:
"Rollback ke versi sebelumnya kalau ada masalah"
// ✓ Rollback plan yang bisa dieksekusi siapapun:
Estimasi waktu rollback: 5 menit
Step 1: Rollback deployment (siapapun dengan akses kubectl bisa lakukan ini)
kubectl rollout undo deployment/order-service -n production
Step 2: Verifikasi rollback berhasil
kubectl rollout status deployment/order-service -n production
→ Tunggu sampai semua pod running
Step 3: Cek error rate kembali normal
→ Buka Grafana dashboard: [URL]
→ Error rate harus turun dalam 2 menit setelah rollback
5. Satu Sprint, Satu Dokumen #
Menggabungkan beberapa sprint dalam satu release document, atau sebaliknya memecah satu sprint menjadi beberapa dokumen tanpa alasan yang jelas, menghilangkan kemampuan untuk mengaitkan incident dengan sprint tertentu.
// ✗ Penggabungan yang membingungkan:
"Release Document Sprint 40-42" (tiga sprint dalam satu dokumen)
→ Saat incident, tidak bisa langsung tahu perubahan mana dari sprint mana
// ✓ Satu dokumen per sprint, konsisten:
"Release Document Sprint 40" → deployment 13 Januari
"Release Document Sprint 41" → deployment 27 Januari
"Release Document Sprint 42" → deployment 10 Februari
→ Incident tanggal 28 Januari → langsung cek Sprint 41
Simpan release document di tempat yang mudah ditemukan dan terindeks dengan baik — Notion, Confluence, atau folder di repository. Konvensi penamaan yang konsisten (misalnya release-sprint-42.md atau tanggal deployment) memudahkan pencarian cepat saat incident. Dokumen yang ada tapi sulit ditemukan nilainya hampir sama dengan yang tidak ada.Anti-Pattern Release Document #
Release Document Sebagai Copy-Paste Commit Log #
Sudah dibahas di bagian best practice, tapi layak diulangi karena sangat umum. Commit log bukan release document. Beda audiens, beda tujuan, beda level abstraksi.
// ✗ Commit log sebagai changelog:
git log --oneline v1.41.0..v1.42.0 | pbcopy
→ paste ke release document
→ "Selesai!"
// Hasilnya:
- a3f2c1d fix nil pointer in auth middleware
- b7e8f2a refactor: split order handler into smaller functions
- c9d1a3b feat: add export endpoint
- d2e4b5c chore: update go modules
→ QA tidak tahu apa yang harus dites
→ On-call tidak tahu area mana yang rawan
→ PM tidak bisa jelasin ke stakeholder apa yang rilis
Tidak Ada Rollback Plan #
Release document tanpa rollback plan adalah setengah dokumen. Deployment selalu punya risiko — mendokumentasikan cara rollback bukan pesimisme, melainkan profesionalisme.
// ✗ Tidak ada rollback plan:
Risiko & Rollback:
"Akan dihandle kalau ada masalah"
// Dampak saat incident jam 2 pagi:
→ Engineer on-call panik mencari cara rollback
→ Bertanya ke Slack siapa yang tahu
→ Rollback butuh 30 menit yang harusnya 5 menit
→ Downtime lebih panjang, user lebih terdampak
Ditulis Setelah Deployment #
Release document yang ditulis setelah deployment tidak lagi berfungsi sebagai alat koordinasi — ia hanya menjadi dokumentasi retroaktif yang nilainya jauh lebih kecil.
// ✗ Pola yang umum terjadi di tim yang terburu-buru:
Senin: Deploy ke production
Rabu: "Oh iya, kita belum bikin release doc Sprint 42"
Kamis: Release doc dibuat dari ingatan
→ Detail penting terlupakan
→ Rollback plan ditulis berdasarkan spekulasi, bukan pengujian aktual
→ Behavior changes yang krusial tidak tercatat
// ✓ Pola yang benar:
Release doc ditulis selama sprint berlangsung
→ Final review H-1 sebelum deployment
→ Deployment dilakukan dengan release doc yang sudah siap
Tidak Mencantumkan Service yang Tidak Berubah #
Ini kesalahan kecil yang berdampak signifikan saat debugging. Saat terjadi incident, tim perlu tahu dengan cepat “apakah auth-service berubah di sprint ini?” — jika tidak dicantumkan, harus cek manual ke board atau git log.
// ✗ Hanya mencantumkan yang berubah:
Services terdampak: order-service, report-service
// Saat incident:
Engineer: "Apakah auth-service juga berubah?"
→ Tidak ada yang tahu, harus cek git log manual
→ Waktu debugging bertambah
// ✓ Cantumkan juga yang tidak berubah:
Services terdampak: order-service, report-service
Services tidak berubah: auth-service, user-service, payment-service
→ Engineer langsung bisa fokus investigasi ke service yang berubah
Siapa yang Bertanggung Jawab Menulis Release Document? #
Release document bukan tanggung jawab satu orang — tapi ada yang harus memastikan ia ada dan lengkap sebelum deployment:
Model yang baik:
Penulis utama: Tech Lead atau Engineer yang paling familiar dengan sprint
→ Bertanggung jawab atas struktur dan kelengkapan dokumen
Kontributor: Setiap engineer yang mengerjakan story di sprint
→ Menambahkan entry changelog untuk story yang mereka kerjakan
→ Lebih akurat karena ditulis oleh yang paling tahu detailnya
Reviewer: QA Lead atau Product Owner
→ Memverifikasi bahwa semua fitur yang di-sprint sudah masuk
→ Memastikan bagian "Catatan QA" cukup jelas
Gate keeper: Tidak ada deployment tanpa release document yang di-approve
Checklist Release Document #
SEBELUM MENULIS:
□ Template release document sudah disiapkan di awal sprint
□ Semua engineer di sprint tahu mereka perlu kontribusi changelog
KONTEN DOKUMEN:
□ Header lengkap: tanggal, environment, release owner, status
□ Link sprint board dan RFC (jika ada)
□ New features: semua story baru tercantum dengan service dan komponen
□ Behavior changes: format "sebelumnya → sesudahnya" digunakan
□ Bug fixes: semua fix yang masuk sprint tercantum
□ Technical changes: infra dan DB changes tercantum
□ Impact summary: services yang terdampak DAN yang tidak berubah
□ Database migration notes: tabel lengkap dengan risiko dan estimasi durasi
□ Rollback plan: step-by-step, bisa dieksekusi oleh engineer manapun
□ Deployment steps: urutan yang jelas kalau ada dependency antar service
KUALITAS:
□ Changelog berbasis dampak, bukan implementasi atau commit message
□ Behavior changes eksplisit dengan "sebelumnya" dan "sesudahnya"
□ Tidak ada "akan dihandle nanti" di bagian rollback plan
□ Rollback command sudah diverifikasi di staging
SEBELUM DEPLOYMENT:
□ Release document sudah di-review oleh minimal satu orang lain
□ QA Lead sudah acknowledge bagian "Catatan QA"
□ Tim on-call sudah membaca bagian risiko dan rollback plan
□ Dokumen disimpan di tempat yang mudah diakses semua anggota tim
Ringkasan #
- Release document adalah alat survival, bukan formalitas — ia paling dibutuhkan justru saat situasi paling kacau: incident di tengah malam, engineer kunci tidak available, sistem baru saja di-deploy dan ada yang tidak berjalan.
- Satu sprint, satu dokumen — granularitas per sprint memungkinkan traceability yang akurat antara incident dan perubahan yang menyebabkannya.
- Changelog berdasarkan dampak, bukan implementasi — tulis untuk QA yang perlu tahu apa yang harus dites, PM yang perlu update stakeholder, dan on-call engineer yang perlu debug cepat.
- Behavior changes wajib eksplisit — gunakan format “sebelumnya → sesudahnya” dan identifikasi siapa yang terdampak, baik service lain maupun user.
- Rollback plan harus bisa dieksekusi oleh siapapun — bukan hanya orang yang paling familiar dengan sistem. Sertakan command yang konkret dan estimasi waktu yang realistis.
- Database migration notes layak mendapat bagian tersendiri — detail tentang backward compatibility, estimasi durasi, dan cara rollback migration sangat krusial untuk deployment yang aman.
- Cantumkan juga service yang tidak berubah — ini mempercepat investigasi incident dengan mengeliminasi area yang tidak perlu dicurigai.
- Tulis selama sprint berlangsung, bukan H-1 deployment — document yang ditulis incremental jauh lebih akurat dan lebih lengkap daripada yang ditulis terburu-buru.
- Tidak ada deployment tanpa release document — ini adalah gate yang melindungi tim dari deployment yang tidak terkoordinasi dan incident yang bisa dicegah.
- Simpan di tempat yang mudah ditemukan — dokumen terbaik tidak berguna jika tidak bisa ditemukan dalam 30 detik saat dibutuhkan.