Mengerjakan tiket

Jalur dari work item Jira sampai perubahan yang di-merge, khusus untuk INACT. Aturan seluruh perusahaan, commit, branch dan pull request, ada di Standar; halaman ini menambahkan apa yang berbeda karena INACT adalah satu code base yang di-fork per klien.

Cara halaman ini diverifikasi

Fakta repository dan branch dibaca dari remote pada 2026-09-05 dan 2026-09-06. Pemetaan Jira adalah peta kerja tim.

1. Temukan instance-nya

Setiap tiket INACT milik satu instance, dan instance menentukan repository, model branch dan database uji.

Project Jira	Instance	Repository
INA01	Master (INACT v3)	inact
INA27	Jadestone	ina-jadestone
INA28	Medco	ina-medco-v3
INA36	JOTRE	ina-jotre
INA14	Timas	ina-timas
INA12	Tomori	ina-tomori
INA10	KTP	ina-ktp
INA05	INACT Support: instance mana pun	yang disebut item-nya

INA05 adalah project lintas instance. Setiap item di sana berasal dari tiket support INARTS, ringkasannya diawali id tiket itu dalam kurung, dan field INACT Instance-nya menyebut instance-nya. Karena ini defect di instance live, defect yang sama biasanya juga ada di fork sibling.

Tiga klien punya kata "Timas" di namanya dan merupakan tiga repository berbeda: Timas, KTP dan JOTRE. Periksa key project-nya, bukan namanya.

2. Periksa model branch

Baca dari remote, jangan dari ingatan:

git ls-remote --heads origin

Instance	Branch permanen	Artinya
Master	hanya main	commit langsung di main, tanpa branch work-item, tanpa PR
Jadestone, Medco, JOTRE, KTP	main, staging, development	branch work-item dipotong dari origin/main, satu PR per target
Timas, Tomori	main, development	sama, tanpa PR staging

Medco dan JOTRE punya branch staging, tetapi workflow deploy-nya tidak men-deploy-nya. Merge ke sana tidak mengubah apa pun di server mana pun. Aturan branch dan PR selebihnya ada di standar Git Workflow.

3. Apakah fiturnya memang ada

Fork-fork nyaris identik, tetapi mereka menyimpang, dan fitur yang ada di satu fork bisa hilang, berganti nama atau mati di fork lain. Sebelum berasumsi, grep sibling-nya:

for d in /path/to/www/*/; do
  grep -rli "<fitur>" --include="*.php" "$d" | grep -v /vendor/
done

Dua jebakan yang menangkap semua orang:

• Fungsi bisa ada dan mati. Helper legacy iw_mysql_query() melempar exception begitu masuk di master, Jadestone, Medco dan Timas. Jalur apa pun yang masih memanggilnya mati di sana. JOTRE pengecualiannya. Halaman modul mencantumkan jalur yang terdampak per modul.
• Key config bisa ada di seed tetapi tidak di tabel live, atau sebaliknya. Pastikan terhadap database instance-nya. Setiap halaman instance mencantumkan perbedaan seed-nya.

4. Reproduksi pada data yang tepat

Checkout setiap fork menunjuk database uji di host dev bersama, lihat Setup lokal. Database uji master hampir kosong; query yang bergantung pada tabel yang jarang terisi terlihat baik di sana tetapi tetap salah di produksi. Snapshot Medco dan Jadestone adalah salinan produksi dan tempat yang lebih baik untuk mencoba data nyata. Kalau tiket menyebut kode project, itu biasanya memberi tahu snapshot mana yang dipakai.

Layar-layarnya adalah halaman yang dirender server dengan dhtmlxGrid di atasnya. Pengurutan grid, isi dropdown dan pengkabelan template hanya menunjukkan perilaku sebenarnya di browser. Uji layarnya, bukan hanya fungsinya.

5. Buat perubahannya portabel

Setiap instance harus jalan di MySQL, PostgreSQL dan SQL Server. Pakai $pdo, jangan pernah helper legacy, dan ikuti aturan Portabilitas database. Migrasi masuk ke db/migrations/ sebagai class phinx; seed ke db/seeds/.

6. Port ke sibling

Perbaikan yang berguna secara umum dikerjakan di satu instance, lalu di-clone sebagai work item ke project Jira setiap sibling dan di-port repository per repository. Target port default adalah big five: master, Jadestone, Medco, JOTRE dan Prima Energy. Timas, Tomori dan KTP hanya mendapat port kalau work item mereka sendiri meminta. Jangan terapkan diff yang sama secara buta; cari titik jangkar yang setara di setiap fork dan sesuaikan, karena file-nya berbeda.

Hubungan clone dicatat sebagai tautan Jira. Jangan pernah menaruh key work item project lain di body commit atau PR; aplikasi GitHub for Jira akan menautkan PR ke tiket yang salah.

7. Commit, PR, deploy

Aturan commit dan PR adalah standar perusahaan: id tiket di subjek, awalan [target] di judul PR, merge biasa, branch work-item hidup sampai produksi. Di INACT fakta tambahannya:

• Dev dan staging deploy sendiri. Push ke development menjalankan producer, menyinkronkan twin terenkripsi, dan consumer menarik situs QA dan menjalankan phinx migrate. Jangan cantumkan "jalankan migrasi di dev" sebagai tugas terbuka.
• Produksi berbeda per klien. Ada yang menarik dari INARTS, ada yang mendapat zip rilis, satu migrate sendiri. Lihat Environment dan deploy dan halaman instance.
• Twin terenkripsi adalah salinan referensi di Mac. Kamu tidak pernah mengeditnya; deployer yang menyinkronkannya. Uji build ter-encode di situs QA -encrypted.bdt.dev.
• Perubahan pada main.php menghentikan sinkronisasi sampai seseorang meng-encode ulang. Hindari menyentuhnya kecuali tiketnya memang tentang itu.

8. Tuliskan

Kalau tiket menyentuh modul yang belum punya halaman di hub ini, atau mengubah sesuatu yang dijelaskan sebuah halaman, halaman itu bagian dari tiket. Frontmatter membawa last_verified dan verified_on; perbarui. Panduan kontribusi punya template-nya.