268 lines
4.8 KiB
Markdown
268 lines
4.8 KiB
Markdown
# RayLab Core Phase 8 --- Development Workflow
|
|
|
|
## Tujuan
|
|
|
|
Fase 8 mendefinisikan alur kerja pengembangan (Development Workflow)
|
|
RayLab Core agar proses implementasi, pengujian, review, dan rilis
|
|
dilakukan secara konsisten.
|
|
|
|
Dokumen ini menjadi standar kerja untuk seluruh pengembangan RayLab
|
|
Core.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Prinsip
|
|
|
|
- Seluruh perubahan dapat dilacak.
|
|
- Setiap fitur dikembangkan secara terpisah.
|
|
- Kualitas kode lebih penting daripada kecepatan.
|
|
- Otomatisasi digunakan sebanyak mungkin.
|
|
- Dokumentasi diperbarui bersamaan dengan perubahan kode.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Development Lifecycle
|
|
|
|
``` text
|
|
Requirement
|
|
│
|
|
▼
|
|
Architecture
|
|
│
|
|
▼
|
|
Issue / Task
|
|
│
|
|
▼
|
|
Implementation
|
|
│
|
|
▼
|
|
Unit Test
|
|
│
|
|
▼
|
|
Integration Test
|
|
│
|
|
▼
|
|
End-to-End Test
|
|
│
|
|
▼
|
|
Code Review
|
|
│
|
|
▼
|
|
Merge
|
|
│
|
|
▼
|
|
Release
|
|
```
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Git Workflow
|
|
|
|
## Branch Utama
|
|
|
|
``` text
|
|
main
|
|
```
|
|
|
|
Selalu berisi kode yang stabil.
|
|
|
|
## Branch Pengembangan
|
|
|
|
Gunakan branch terpisah untuk setiap pekerjaan.
|
|
|
|
Contoh:
|
|
|
|
``` text
|
|
feature/identity
|
|
feature/media-manager
|
|
feature/api-users
|
|
|
|
fix/login-session
|
|
fix/storage-permission
|
|
|
|
refactor/authorization
|
|
|
|
docs/api-architecture
|
|
```
|
|
|
|
Satu branch hanya menangani satu tujuan.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Commit Convention
|
|
|
|
Format commit:
|
|
|
|
``` text
|
|
type(scope): description
|
|
```
|
|
|
|
Contoh:
|
|
|
|
``` text
|
|
feat(identity): add user service
|
|
fix(media): resolve folder permission bug
|
|
docs(api): update endpoint documentation
|
|
refactor(registry): simplify adapter registration
|
|
test(users): add integration test
|
|
```
|
|
|
|
Jenis commit:
|
|
|
|
- feat
|
|
- fix
|
|
- docs
|
|
- refactor
|
|
- test
|
|
- chore
|
|
- ci
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Pull Request Checklist
|
|
|
|
Sebelum merge:
|
|
|
|
- Kode berhasil dikompilasi.
|
|
- Unit test lulus.
|
|
- Integration test lulus.
|
|
- E2E test lulus (jika relevan).
|
|
- Dokumentasi diperbarui.
|
|
- Migration ditinjau.
|
|
- Tidak ada perubahan yang tidak terkait.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Testing Strategy
|
|
|
|
## Unit Test
|
|
|
|
Menguji business logic secara terisolasi.
|
|
|
|
Tool:
|
|
|
|
- Jest
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
## Integration Test
|
|
|
|
Menguji interaksi antar modul.
|
|
|
|
Tool:
|
|
|
|
- Jest
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
## End-to-End Test
|
|
|
|
Menguji perilaku sistem dari sudut pandang pengguna.
|
|
|
|
Tool:
|
|
|
|
- Playwright
|
|
|
|
Standar ini mengikuti proses pengujian RayLab yang telah ditetapkan.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Code Review
|
|
|
|
Fokus review:
|
|
|
|
- Kesesuaian dengan arsitektur.
|
|
- Kualitas business logic.
|
|
- Keamanan.
|
|
- Konsistensi penamaan.
|
|
- Keterbacaan kode.
|
|
- Dampak terhadap modul lain.
|
|
|
|
Review tidak hanya memeriksa apakah kode berjalan, tetapi juga apakah
|
|
kode sesuai dengan standar RayLab Core.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Database Workflow
|
|
|
|
Perubahan database:
|
|
|
|
1. Ubah `schema.prisma`.
|
|
2. Buat migration.
|
|
3. Jalankan migration pada lingkungan pengembangan.
|
|
4. Perbarui dokumentasi jika diperlukan.
|
|
|
|
Perubahan langsung pada database produksi tidak diperbolehkan.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Documentation Workflow
|
|
|
|
Setiap perubahan yang memengaruhi arsitektur, API, atau modul harus
|
|
diikuti dengan pembaruan dokumentasi.
|
|
|
|
Area dokumentasi:
|
|
|
|
- Architecture
|
|
- API
|
|
- Module
|
|
- ADR
|
|
- Guide
|
|
|
|
Dokumentasi menjadi bagian dari proses pengembangan.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Release Workflow
|
|
|
|
``` text
|
|
Development
|
|
│
|
|
▼
|
|
Testing
|
|
│
|
|
▼
|
|
Review
|
|
│
|
|
▼
|
|
Tag Release
|
|
│
|
|
▼
|
|
Docker Build
|
|
│
|
|
▼
|
|
Deployment
|
|
```
|
|
|
|
Setiap rilis menggunakan tag versi yang jelas.
|
|
|
|
Contoh:
|
|
|
|
``` text
|
|
v1.0.0
|
|
v1.1.0
|
|
v2.0.0
|
|
```
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Definition of Done
|
|
|
|
Sebuah pekerjaan dianggap selesai apabila:
|
|
|
|
- Implementasi selesai.
|
|
- Seluruh test lulus.
|
|
- Tidak ada error linting.
|
|
- Dokumentasi diperbarui.
|
|
- Migration tersedia (jika diperlukan).
|
|
- Telah melalui code review.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
# Hasil Akhir Fase 8
|
|
|
|
Pada akhir fase ini RayLab Core memiliki standar workflow pengembangan
|
|
yang mencakup implementasi, pengujian, review, dokumentasi, dan proses
|
|
rilis. Workflow ini menjadi pedoman agar seluruh pengembangan tetap
|
|
konsisten, berkualitas, dan mudah dipelihara dalam jangka panjang.
|