Modernisasi Proyek VB6 Lama dengan Git Hook dan CI Dasar

Modernisasi proyek VB6 lama dengan Git hook dan CI dasar bukan berarti memaksa tim melakukan migrasi besar atau rewrite total. Untuk banyak tim yang masih merawat aplikasi desktop Visual Basic klasik di Windows, kebutuhan paling mendesak biasanya lebih sederhana: mengurangi human error, membuat build lebih dapat diprediksi, dan memudahkan kolaborasi pada codebase yang sudah lama hidup.

Pendekatan yang paling realistis adalah menambahkan lapisan workflow modern di sekitar proyek lama. Artinya, source code tetap dipertahankan, tetapi repository dirapikan, aturan commit diperjelas, Git hook dipakai untuk validasi file proyek dan binary, lalu CI dasar digunakan untuk memastikan artefak build, checksum, dan packaging rilis konsisten. Hasilnya bukan sistem sempurna, tetapi proses kerja yang lebih aman dan lebih mudah diaudit.

Mengapa proyek VB6 perlu workflow modern, bukan langsung rewrite

Pada proyek legacy desktop, rewrite sering terdengar menarik tetapi berisiko tinggi. Aplikasi VB6 lama biasanya memiliki kombinasi masalah berikut:

Dependensi COM/OCX yang tidak terdokumentasi dengan baik.
Build yang bergantung pada mesin developer tertentu.
File biner seperti .frx, .res, atau komponen pihak ketiga yang sulit di-diff.
Perbedaan environment Windows yang dapat menghasilkan perilaku build berbeda.
Logika bisnis tersebar di form, module, dan event handler dengan coupling tinggi.

Dalam kondisi seperti ini, meningkatkan developer experience sering memberi hasil lebih cepat daripada rewrite. Tujuannya adalah membuat perubahan kecil lebih aman: siapa mengubah apa, file apa yang boleh ikut berubah, build apa yang dianggap valid, dan bagaimana rilis dibuat dengan langkah yang bisa diulang.

Catatan: CI pada proyek VB6 tidak selalu berarti kompilasi penuh otomatis di cloud. Pada banyak tim, bentuk awal CI yang paling berguna justru verifikasi struktur repository, pemeriksaan file sensitif, validasi metadata build, dan packaging artefak dari mesin Windows yang sudah dikontrol.

Standarisasi struktur repository

Langkah pertama adalah membuat repository lebih mudah dipahami. Proyek lama sering tumbuh organik: file bercampur, output build masuk ke folder source, dependency disalin manual, dan dokumentasi tersebar di email atau network share.

Struktur folder yang pragmatis

Anda tidak perlu memaksa struktur modern yang terlalu kompleks. Cukup pisahkan file yang sering berubah, file hasil build, dan file operasional tim.

repo-root/
├─ src/
│  ├─ App/
│  │  ├─ MyApp.vbp
│  │  ├─ Main.bas
│  │  ├─ FormMain.frm
│  │  └─ FormMain.frx
│  ├─ Shared/
│  └─ Controls/
├─ tools/
│  ├─ scripts/
│  │  ├─ build.ps1
│  │  ├─ verify-project.ps1
│  │  └─ package-release.ps1
│  └─ hooks/
│     ├─ pre-commit.ps1
│     └─ commit-msg.ps1
├─ docs/
│  ├─ build.md
│  ├─ release.md
│  └─ dependencies.md
├─ dist/
├─ checksums/
└─ .gitattributes

Struktur ini membantu memisahkan beberapa hal penting:

src/ untuk source utama.
tools/ untuk otomasi, bukan utilitas acak di desktop developer.
docs/ untuk langkah build, release, dan dependency.
dist/ untuk hasil packaging, sebaiknya tidak dicampur dengan source.
checksums/ untuk hash artefak rilis jika ingin disimpan sebagai referensi.

File yang perlu didokumentasikan sejak awal

Pada proyek VB6, dokumentasi minimum jauh lebih penting daripada teori arsitektur yang terlalu abstrak. Pastikan ada:

docs/build.md: langkah build lokal, dependency OCX/DLL, dan requirement environment.
docs/dependencies.md: daftar komponen eksternal, lokasi file, status registrasi, dan lisensi jika ada.
docs/release.md: urutan packaging, checksum, penamaan versi, dan lokasi artefak.

Jika tim kecil, tiga dokumen ini sudah cukup untuk menurunkan risiko build yang hanya bisa dilakukan oleh satu orang.

Aturan commit yang cocok untuk proyek legacy

Pada repository modern, aturan commit dipakai untuk keterbacaan dan otomasi. Pada proyek VB6 lama, manfaat tambahannya adalah membantu reviewer memahami apakah perubahan memang wajar. Ini penting karena file seperti .frm dan .frx sering berubah bersamaan, sementara perubahan tak disengaja juga mudah terjadi.

Prinsip aturan commit

Satu commit untuk satu tujuan perubahan.
Jangan mencampur refactor, bugfix, dan update artefak rilis dalam commit yang sama.
Jika file biner berubah, jelaskan alasannya di pesan commit.
Hindari commit output build kecuali repository memang menyimpan artefak tertentu secara sengaja.

Contoh format commit

fix: koreksi validasi tanggal pada form invoice
build: perbarui skrip packaging rilis
chore: sinkronkan dependensi OCX pada dokumentasi
release: paketkan versi 2.4.7 dan checksum

Format seperti ini sederhana, mudah dicari, dan cukup berguna jika nanti Anda ingin membuat changelog atau memfilter histori. Tidak perlu terlalu kaku; yang penting konsisten.

Git hook untuk validasi file project, form, dan binary

Git hook sangat cocok untuk proyek VB6 karena banyak kesalahan bisa dicegah sebelum commit masuk repository. Prinsipnya adalah memeriksa file yang sedang di-stage, lalu menolak commit bila pola perubahan terlihat berbahaya atau tidak lengkap.

Apa yang layak divalidasi pada pre-commit

Untuk proyek klasik, validasi yang paling berguna biasanya bukan linting canggih, melainkan pemeriksaan integritas file:

Jika file .frm berubah, pastikan file pasangan .frx juga ikut diperiksa bila memang diperlukan.
Tolak commit jika output build seperti .exe, .obj, atau file temporary ikut ter-stage tanpa alasan jelas.
Pastikan file project seperti .vbp tidak mengarah ke path absolut lokal developer.
Deteksi perubahan pada referensi komponen atau dependency yang perlu review ekstra.
Pastikan line ending konsisten untuk file teks seperti .bas, .cls, dan .frm.

Contoh pre-commit hook sederhana dengan PowerShell

Contoh berikut memeriksa file yang di-stage dan menolak commit jika ada output build atau perubahan .frm tanpa perhatian pada pasangan file terkait.

$ErrorActionPreference = "Stop"

$staged = git diff --cached --name-only
if (-not $staged) { exit 0 }

$blockedPatterns = @(
    '\.exe$',
    '\.obj$',
    '\.log$',
    '\.tmp$'
)

foreach ($file in $staged) {
    foreach ($pattern in $blockedPatterns) {
        if ($file -match $pattern) {
            Write-Error "Commit ditolak: file output/temporary terdeteksi: $file"
            exit 1
        }
    }
}

$frmFiles = $staged | Where-Object { $_ -match '\.frm$' }
foreach ($frm in $frmFiles) {
    $frx = [System.IO.Path]::ChangeExtension($frm, '.frx')
    if (Test-Path $frx) {
        if (-not ($staged -contains $frx)) {
            Write-Warning "Perhatian: $frm berubah. Periksa apakah $frx juga seharusnya ikut berubah."
        }
    }
}

$vbpFiles = $staged | Where-Object { $_ -match '\.vbp$' }
foreach ($vbp in $vbpFiles) {
    $content = Get-Content $vbp -Raw
    if ($content -match '[A-Z]:\\') {
        Write-Error "Commit ditolak: path absolut terdeteksi dalam $vbp"
        exit 1
    }
}

Write-Host "Pre-commit check lolos."
exit 0

Hook ini tidak sempurna, tetapi efektif untuk mencegah kesalahan yang umum. Di proyek legacy, aturan kecil seperti ini biasanya memberi nilai lebih besar daripada validasi yang terlalu ambisius.

Hook commit-msg untuk menjaga pesan commit

Selain pre-commit, Anda bisa menambah commit-msg hook agar pesan commit mengikuti format tim.

param(
    [string]$CommitMsgFile
)

$message = Get-Content $CommitMsgFile -Raw
if ($message -notmatch '^(fix|feat|chore|build|docs|refactor|release):\s') {
    Write-Error "Pesan commit harus diawali dengan tipe, misalnya: fix: ..."
    exit 1
}
exit 0

Trade-off-nya jelas: hook lokal bisa dilewati oleh developer yang mematikan hook atau melakukan commit dari lingkungan lain. Karena itu, aturan penting tetap perlu diverifikasi lagi di CI.

Skrip build sederhana yang bisa diulang

Masalah klasik di proyek VB6 adalah build hanya berhasil di mesin tertentu karena dependency, registrasi komponen, atau konfigurasi IDE berbeda. Anda mungkin tidak bisa langsung membuat build sepenuhnya portabel, tetapi setidaknya prosesnya bisa didokumentasikan dan dibungkus skrip.

Tujuan skrip build

Membuat langkah build eksplisit dan dapat diulang.
Menghasilkan output ke folder yang konsisten.
Mencatat checksum atau metadata hasil build.
Memisahkan build dari langkah packaging.

Contoh alur build PowerShell

Detail kompilasi bisa berbeda tergantung toolchain yang tersedia di mesin Windows Anda. Karena itu, contoh berikut sengaja fokus pada struktur langkah, bukan asumsi detail environment yang terlalu spesifik.

param(
    [string]$ProjectFile = "src/App/MyApp.vbp",
    [string]$OutputDir = "dist/build"
)

$ErrorActionPreference = "Stop"
New-Item -ItemType Directory -Force -Path $OutputDir | Out-Null

Write-Host "[1/4] Verifikasi file proyek"
& powershell -ExecutionPolicy Bypass -File tools/scripts/verify-project.ps1 -ProjectFile $ProjectFile
if ($LASTEXITCODE -ne 0) { exit 1 }

Write-Host "[2/4] Bersihkan output lama"
Get-ChildItem $OutputDir -Force | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force -Path $OutputDir | Out-Null

Write-Host "[3/4] Jalankan build sesuai toolchain lokal"
# Gantikan bagian ini dengan perintah build yang sesuai environment tim Anda.
# Misalnya memanggil tool kompilasi, IDE automation, atau wrapper internal.

Write-Host "[4/4] Catat metadata build"
$metadata = @{
    project = $ProjectFile
    builtAt = (Get-Date).ToString("s")
    machine = $env:COMPUTERNAME
}
$metadata | ConvertTo-Json | Set-Content "$OutputDir/build-metadata.json"

Write-Host "Build selesai."

Poin pentingnya adalah langkah build dibakukan. Walaupun kompilasi masih bergantung pada mesin Windows tertentu, tim setidaknya memiliki jalur resmi yang sama, bukan instruksi lisan yang berubah-ubah.

Validasi proyek sebelum build

Skrip verify-project.ps1 bisa dipakai untuk pemeriksaan ringan sebelum kompilasi:

Apakah file .vbp ada dan bisa dibaca.
Apakah referensi file source yang tercantum memang ada.
Apakah ada path absolut lokal.
Apakah output diarahkan ke lokasi yang sesuai kebijakan tim.

Pemeriksaan ini tidak menggantikan compile, tetapi membantu mendeteksi kerusakan repository lebih awal.

Checklist review untuk file yang sulit di-diff

Tantangan utama di proyek VB6 bukan hanya code review biasa, tetapi review terhadap file yang formatnya campuran teks dan biner. File seperti .frm relatif masih bisa dibaca, tetapi pasangan .frx sering tidak informatif di diff Git. Karena itu, tim perlu checklist review yang eksplisit.

Checklist pull request atau code review

Apakah perubahan .frm memang sesuai dengan bugfix atau perubahan UI yang dijelaskan?
Jika .frx berubah, apakah ada penjelasan apa yang berubah: ikon, resource, layout, atau embedded asset?
Apakah file .vbp mengalami perubahan referensi komponen? Jika ya, apakah dependency didokumentasikan?
Apakah output build atau file temporary ikut ter-commit tanpa sengaja?
Apakah perubahan menyentuh modul bersama yang berisiko tinggi?
Apakah langkah verifikasi manual minimum dicantumkan?

Praktik yang membantu reviewer

Karena file biner sulit di-diff, minta penulis perubahan untuk menambahkan konteks singkat di deskripsi PR:

Form yang diubah.
Kontrol yang ditambah/dihapus.
Screenshot sebelum/sesudah bila relevan.
Alasan perubahan file resource.
Langkah uji manual.

Ini terdengar sederhana, tetapi pada proyek desktop legacy, konteks manual seperti screenshot atau daftar langkah uji sering jauh lebih berguna daripada memaksa review murni berbasis diff.

Pipeline CI dasar untuk verifikasi artefak, checksum, dan packaging rilis

CI pada proyek VB6 harus disesuaikan dengan realitas environment Windows klasik. Jika kompilasi penuh otomatis belum stabil, jangan memaksakan pipeline yang rapuh. Mulailah dari pipeline dasar yang memverifikasi hal-hal penting dan bisa dipercaya.

Target realistis untuk CI tahap awal

Checkout repository dan validasi struktur file.
Jalankan skrip verifikasi proyek.
Pastikan file terlarang tidak masuk commit.
Jika build tersedia pada runner Windows internal, hasilkan artefak.
Buat checksum untuk artefak hasil build.
Paketkan rilis ke format yang disepakati tim.

Contoh langkah pipeline yang netral terhadap platform CI

steps:
  - checkout
  - run: powershell -File tools/scripts/verify-project.ps1 -ProjectFile src/App/MyApp.vbp
  - run: powershell -File tools/scripts/build.ps1 -ProjectFile src/App/MyApp.vbp -OutputDir dist/build
  - run: powershell -File tools/scripts/package-release.ps1 -InputDir dist/build -OutputFile dist/release/MyApp.zip
  - run: powershell -Command "Get-FileHash dist/release/MyApp.zip -Algorithm SHA256 | Format-List"
  - upload-artifact: dist/release/MyApp.zip

Contoh di atas sengaja umum agar dapat dipetakan ke berbagai sistem CI. Intinya bukan nama syntax CI, melainkan urutan proses yang konsisten.

Contoh skrip packaging dan checksum

param(
    [string]$InputDir = "dist/build",
    [string]$OutputFile = "dist/release/MyApp.zip"
)

$ErrorActionPreference = "Stop"
$releaseDir = Split-Path $OutputFile -Parent
New-Item -ItemType Directory -Force -Path $releaseDir | Out-Null

if (Test-Path $OutputFile) {
    Remove-Item $OutputFile -Force
}

Compress-Archive -Path "$InputDir/*" -DestinationPath $OutputFile

$hash = Get-FileHash $OutputFile -Algorithm SHA256
New-Item -ItemType Directory -Force -Path "checksums" | Out-Null
"$($hash.Hash) *$(Split-Path $OutputFile -Leaf)" | Set-Content "checksums/$(Split-Path $OutputFile -Leaf).sha256"

Write-Host "Paket rilis dibuat: $OutputFile"
Write-Host "Checksum SHA256: $($hash.Hash)"

Kenapa checksum penting? Bukan hanya untuk keamanan distribusi, tetapi juga untuk memastikan artefak yang diuji dan artefak yang dirilis benar-benar sama. Pada workflow manual, ini sering menjadi sumber kesalahan yang tidak terlihat.

Kapan perlu runner Windows khusus

Jika build VB6 bergantung pada komponen terdaftar, tool lama, atau konfigurasi COM tertentu, Anda kemungkinan membutuhkan runner Windows yang dikelola sendiri. Trade-off-nya:

Keuntungan: environment lebih mirip mesin produksi build yang sebenarnya.
Kekurangan: lebih sulit dipelihara, butuh hardening, dan rentan drift jika tidak didokumentasikan.

Jika tim masih kecil, cukup mulai dengan satu mesin build Windows yang perannya jelas, lalu bungkus semua langkah dengan skrip. Itu lebih realistis daripada langsung mengejar environment sepenuhnya ephemeral.

Keterbatasan dan trade-off yang perlu diterima

File biner sulit di-diff dan sulit di-merge

Ini fakta utama. Untuk file seperti .frx, Git tidak memberi visibilitas setara file teks. Konsekuensinya:

Hindari dua orang mengedit form yang sama secara paralel jika memungkinkan.
Perkecil ukuran pull request.
Biasakan commit kecil dan sering.
Gunakan penjelasan manual di PR untuk perubahan UI/resource.

CI tidak selalu bisa menjadi sumber kebenaran penuh

Pada stack lama, ada kemungkinan build sukses hanya pada environment tertentu. Ini bukan alasan untuk tidak memakai CI, tetapi alasan untuk mendefinisikan target CI dengan jujur. CI dasar tetap berguna walaupun belum bisa menjamin semua hal, selama ia bisa memeriksa konsistensi repository, packaging, dan artefak.

Hook lokal membantu, tetapi bukan kontrol mutlak

Hook Git lokal bisa di-bypass. Karena itu, validasi yang paling penting sebaiknya ada juga di CI atau pada tahap review. Gunakan hook untuk mempercepat feedback, bukan sebagai satu-satunya pagar.

Rencana implementasi bertahap untuk tim kecil

Modernisasi workflow tidak harus dilakukan sekaligus. Untuk tim kecil yang masih sibuk merawat bug produksi, urutan berikut biasanya paling masuk akal:

Tahap 1: rapikan repository dan dokumentasi minimum

Pisahkan source, tools, docs, dan dist.
Tambahkan build.md, release.md, dan dependencies.md.
Buat daftar file yang tidak boleh di-commit.

Tahap 2: tambahkan aturan commit dan pre-commit hook

Terapkan format pesan commit sederhana.
Blok file temporary/output build.
Periksa path absolut pada .vbp.
Beri warning untuk perubahan .frm/.frx.

Tahap 3: bungkus build dengan skrip

Standarkan output build.
Catat metadata build.
Pisahkan proses build dan packaging.

Tahap 4: aktifkan CI dasar

Jalankan verifikasi repository.
Jika memungkinkan, jalankan build pada runner Windows.
Buat zip rilis dan checksum otomatis.
Upload artefak untuk review internal.

Tahap 5: perkuat review dan release discipline

Gunakan checklist PR khusus proyek VB6.
Pastikan setiap rilis punya checksum dan catatan perubahan.
Evaluasi file atau langkah manual yang masih sering menyebabkan masalah.

Pendekatan bertahap ini penting karena proyek legacy jarang punya ruang untuk perubahan proses yang terlalu besar sekaligus. Workflow yang sedikit lebih baik tetapi dipakai konsisten jauh lebih bernilai daripada desain pipeline yang ideal tetapi tidak pernah stabil.

Penutup

Modernisasi proyek VB6 lama dengan Git hook dan CI dasar pada dasarnya adalah upaya membuat pekerjaan lama menjadi lebih terkontrol, bukan lebih mewah. Dengan repository yang rapi, aturan commit yang jelas, hook untuk mencegah kesalahan umum, skrip build yang bisa diulang, checklist review yang realistis, dan CI dasar untuk verifikasi artefak serta checksum, tim bisa mengurangi banyak masalah operasional tanpa rewrite besar.

Untuk aplikasi desktop klasik di Windows, kemenangan terbesar biasanya bukan adopsi tool paling baru, melainkan hilangnya langkah manual yang rawan lupa, build yang hanya dipahami satu orang, dan rilis yang sulit ditelusuri. Mulailah dari kontrol yang paling sederhana dan paling sering menyelamatkan waktu tim.

Quick Search

shopping_cart Keranjang