Kolaborasi Tim dan Pemanfaatan Tools: Strategi Penyelesaian Isu dan Integrasi Layanan dari Requirements hingga Deployment

Source: Dev.to

Pendahuluan

Dalam pengembangan perangkat lunak berbasis tim, kualitas kolaborasi tidak hanya ditentukan oleh kemampuan teknis individual, melainkan oleh seberapa efektif tim memanfaatkan tools yang tersedia untuk menyelaraskan workflow, mendeteksi masalah lebih awal, dan memastikan kualitas kode secara konsisten. Dokumen ini menyajikan analisis komprehensif mengenai penerapan best practices dalam kerja tim, penyelesaian isu‑isu kritis, serta integrasi antar tools untuk memaksimalkan efisiensi kolaborasi.

Tujuan Dokumen

• Identifikasi dan penyelesaian isu‑isu kolaborasi yang memberikan dampak signifikan bagi tim.
• Integrasi tools dari tahap requirements hingga deployment.
• Strategi recovery dari kondisi kritis (crisis management) dalam konteks version control.
• Bukti manfaat terukur dari disiplin penggunaan tools terhadap produktivitas tim.

Kriteria Penilaian (Level 4)

• Memberikan solusi penyelesaian atas isu‑isu yang terjadi agar memberikan manfaat bagi tim.
• Memaksimalkan pemanfaatan tools dari requirements hingga deploy.
• Menunjukkan integrasi antar tools untuk memaksimalkan teamwork.
• Evaluasi kritis terhadap penerapan tools dan dampaknya.

Proyek FIMO

Tim FIMO terdiri dari 5 anggota, namun selama pengembangan menghadapi tantangan signifikan.

Kondisi Tim

Kontribusi di Luar Scope Awal

Backend Development

• Pengembangan lengkap modul apps/forum/ (models, views, services, repositories, tests)
• Pengembangan lengkap modul apps/reply/ dengan arsitektur SOLID terdokumentasi
• Implementasi testing infrastructure dengan coverage komprehensif

Frontend Development (Beyond Initial Scope)

• Implementasi fitur‑fitur terkait modul forum dan reply
• Penerapan otorisasi dan access control di frontend
• Integrasi dengan backend API yang dikembangkan

Infrastructure & DevOps

• Konfigurasi SonarQube untuk static code analysis
• Integrasi CI/CD pipeline dengan quality gates
• Crisis management untuk recovery dari kondisi branch yang kacau

Insiden Awal: “Death Commit”

Kronologi Insiden

T+0: Anggota tim melakukan "create app forum"
T+1: Commit langsung ke staging dengan perubahan masif
T+2: Tidak ada unit test yang menyertai
T+3: Struktur kode tidak modular, sulit di‑maintain

Karakteristik “Death Commit”

Contoh Masalah Struktural (ANTI‑PATTERN)

# File: apps/forum/models.py
class Topic(models.Model):
    # ... topic fields
    pass

class User(models.Model):  # ← Seharusnya di auth/models.py
    # ... user fields
    pass

class Reply(models.Model):  # ← Seharusnya di apps/reply/models.py
    # ... reply fields
    pass

class Note(models.Model):   # ← Seharusnya di apps/reply/models.py
    # ... note fields
    pass
# Semua class dalam 1 file = violation of modularity
# Tidak ada separation of concerns
# Sulit untuk multiple developers bekerja paralel

Strategi Recovery: Parallel Branch Reconstruction

Diagram Alur Recovery

staging (contaminated)          staging2 (clean reconstruction)
    │                                   │
    │ ← death commit                    │ ← clean Django structure
    ▼                                   ▼
┌─────────────────┐              ┌─────────────────┐
│ Monolithic      │              │ Modular         │
│ - Single file   │              │ - apps/forum/   │
│ - No tests      │              │ - apps/reply/   │
│ - Tight coupled │              │ - apps/main/    │
└─────────────────┘              └─────────────────┘
                                        │
                                        ▼
                                 Gradual Migration
                                        │
                                        ▼
                                 staging ← staging2
                                 (complete replacement)

Langkah Implementasi

Step 1: Membuat Branch staging2 dari State Sebelum Death Commit

# Identifikasi commit terakhir yang bersih
git log --oneline staging

# Buat branch baru dari commit sebelum death commit
git checkout -b staging2

Step 2: Membangun Struktur Modular

apps/
├── __init__.py
├── forum/              # Domain‑specific app
│   ├── models/
│   ├── views/
│   ├── services/
│   ├── repositories/
│   └── tests/
├── reply/              # Domain‑specific app
│   ├── models/
│   ├── views/
│   ├── services/
│   ├── repositories/
│   └── tests/
└── main/               # Shared utilities

Step 3: Koordinasi Tim untuk Migrasi Gradual (via Discord)

1. Announce: “staging2 dibuat dengan struktur bersih”.
2. Guide: “Refactor existing work ke struktur baru”.
3. Review: “Merge ke staging2 setelah review”.
4. Validate: “Testing di environment staging2”.
5. Finalize: “Replace staging dengan staging2”.

Step 4: Final Replacement

# Setelah staging2 stabil dan tervalidasi
git checkout staging
git reset --hard staging2
git push --force-with-lease origin staging

Metrik Perbandingan

Guardrails yang Diterapkan

1. Branch Protection Rules

staging:
  - Require merge request
  - Require at least 1 approval
  - Require CI pipeline success
  - No direct push allowed

2. Commit Message Convention

Format: type(scope): description

Contoh:

• feat(forum): add create topic endpoint
• fix(reply): handle empty content validation
• test(reply): add unit tests for NoteService

3. Atomic Commit Philosophy

Prinsip: 1 Commit = 1 Logical Change

GOOD

feat(forum): add Topic model with basic fields
feat(forum): add TopicSerializer for API
test(forum): add Topic model unit tests

BAD

add forum app with models views serializers tests and everything

Integrasi SonarQube & CI/CD

Sebelum integrasi SonarQube, proses quality assurance bersifat manual dan tidak konsisten.

Kondisi Sebelumnya

Arsitektur Integrasi CI/CD

┌─────────────────────────────────────────────────────────────┐
│                     CI/CD Pipeline                              │
├─────────────────────────────────────────────────────────────┤
│  • Build → SonarQube analysis → Unit Tests → Deploy            │
└─────────────────────────────────────────────────────────────┘

Dengan konfigurasi ini, setiap commit harus melewati:

1. Static analysis oleh SonarQube (quality gates).
2. Unit test dengan minimal coverage yang ditetapkan.
3. Code review melalui merge request.

Hasilnya, tim memperoleh feedback otomatis, mengurangi technical debt, dan meningkatkan kepercayaan pada kualitas rilis.