Loading image 1...
PemeliharaanSistemSmartGym
Pemeliharaan dan Pengembangan Sistem Manajemen Gym Multi-Tenant di Atas Data Produksi yang Berjalan
Pemeliharaan Sistem SmartGym
Pemeliharaan Sistem SmartGym
Pemeliharaan dan Pengembangan Sistem Manajemen Gym Multi-Tenant di Atas Data Produksi yang Berjalan
Pemeliharaan dan Pengembangan Sistem Manajemen Gym Multi-Tenant di Atas Data Produksi yang Berjalan
Javapixa mengerjakan pemeliharaan dan pengembangan SmartGym, sistem manajemen gym yang sudah berjalan dengan member, pembayaran, dan catatan presensi yang nyata. Sistemnya terdiri dari tiga aplikasi CodeIgniter 4 yang di-deploy terpisah, yaitu back-office staf, portal member dan trainer, serta situs publik, yang semuanya membaca dan menulis ke satu database MySQL yang sama. Satu basis kode melayani beberapa gym sekaligus, masing-masing dengan database, pohon aset, dan subdomainnya sendiri, dan routing-nya bercabang berdasarkan host HTTP. Selama 101 commit dan 492 berkas aplikasi, pekerjaannya mencakup booking kelas, subdomain kasir, upgrade skema tenant, dan penulisan ulang situs publik, dan tidak satu pun dari itu boleh merusak data yang sudah ada.
Masalah
Ini bukan proyek dari nol. Kelas model diduplikasi di tiga aplikasi, sehingga perubahan skema di satu aplikasi bisa merusak dua lainnya. Skemanya sendiri tidak dapat direkonstruksi dari repositori: hanya ada tiga migrasi, dan tiga view yang dipakai kode setiap hari tidak dibuat oleh satu pun di antaranya, artinya dump database itulah yang sebenarnya menjadi disaster recovery. Hosting-nya shared, jadi hak akses SUPER dan SET_USER_ID tidak tersedia, padahal dump yang ada membawa klausa DEFINER yang menuntut hak itu. Aplikasinya juga bergantung pada konfigurasi database yang permisif, sehingga SQL lama langsung ditolak oleh server dengan only_full_group_by aktif.
Setiap perubahan diverifikasi lebih dulu di atas salinan yang dipulihkan, bukan di produksi. Skrip upgrade skema tenant dibangun dan diuji berulang dengan siklus tetap: pulihkan dump klien, sesuaikan dengan kondisi persis server live, jalankan upgrade, lalu jalankan SQL migrasi yang gagal di atasnya, dan tutup dengan diff information_schema terhadap skema referensi yang harus kembali kosong. Nilai enum yang berganti nama dimigrasikan dengan melebarkan enum lebih dulu, memindahkan datanya, baru menyempitkannya, agar 404 baris member tidak terhapus. Kolom created_at ditambahkan sebagai NULL, bukan DEFAULT CURRENT_TIMESTAMP, supaya riwayat bertahun-tahun tidak dicap tanggal hari ini. Di sisi front-end, situs publik dibangun ulang agar setiap bagian mengambil isinya dari database, dengan konten contoh yang menandai dirinya sendiri di dalam HTML sehingga tidak bisa tertinggal diam-diam di produksi.
PerjalananVisual
Showcase Proyek
Loading image 1...
Tangkapan Layar 1
Visualisasi proyek dan desain antarmuka
StackTeknologi
CodeIgniter 4
Framework PHP
PHP 8.3
Bahasa
MySQL / MariaDB
Database
Tailwind CSS
Styling
JavaScript
Frontend
LiteSpeed
Shared Hosting
FiturUtama
Subsistem Booking Kelas
Booking kelas dikerjakan menyeluruh: tabel baru, dua view langganan per baris, dan alur di sisi member. Di sinilah bentuk asli model langganan tersingkap, karena satu kontainer langganan bisa memuat beberapa produk dengan tanggal berakhir berbeda, sehingga status harus dinilai per baris, bukan per kontainer, dan laporan yang bergantung padanya ikut dikoreksi.
Subdomain Kasir Terisolasi
Subdomain kasir melayani layar point of sale dan tidak lebih dari itu, dengan tata letak minimal, sehingga staf kasir tidak dapat menjangkau back-office dari perangkat yang sama.
Skrip Upgrade Skema Tenant
Satu skrip berurutan yang membawa database tenant generasi lama ke skema yang dibutuhkan aplikasi saat ini: 23 tabel yang hilang, 74 pernyataan kolom, 8 perbedaan tipe dan enum, serta 7 view, dengan urutan dependensi view yang tidak boleh diubah.
Migrasi Enum Tanpa Kehilangan Data
Nilai enum mahasiswa berganti menjadi pelajar sementara 404 baris member masih memegang nilai lama. Menyempitkan enum lebih dulu akan mengosongkan baris-baris itu, jadi skrip melebarkan enum agar memuat keduanya, memindahkan datanya, baru menyempitkan.
Situs Publik Berbasis Data Nyata
Setiap bagian situs publik mengambil isinya dari database. Gym baru dengan database kosong tetap menampilkan halaman utuh lewat konten contoh, dan setiap contoh ditandai di dalam HTML yang dikirim beserta rute untuk menggantinya, sehingga tidak ada isi karangan yang bisa dikira nyata.
Render Defensif dan Cache Berversi
Nama berkas di database bisa hidup lebih lama dari berkasnya, jadi setiap URL gambar diperiksa keberadaannya di disk sebelum ditulis. Logo, favicon, ikon PWA, dan foto unggahan membawa stempel versi dari waktu modifikasi berkas itu sendiri, sehingga tidak ada langkah cache-busting manual yang bisa terlupa.
ProsesKami
Pandangan detail tentang bagaimana kami mewujudkan proyek ini dari konsep hingga kenyataan melalui metodologi kami yang terbukti.
Konsolidasi dan Koreksi
Menyatukan tiga aplikasi dan pohon aset bersama ke dalam satu repositori, lalu membangun harness pengembangan lokal berupa router yang memilih aplikasi dari header Host, karena produksi menyajikan setiap aplikasi dari document root sendiri dengan front controller di akar aplikasi. Dilanjutkan perbaikan status langganan, presensi, foto member, dan QR dinamis untuk akses gerbang.
Booking Kelas dan Skema Pendukungnya
Menambahkan booking kelas menyeluruh dengan tabel baru, view langganan per baris, dan alur di sisi member, disertai tiga migrasi. Pada tahap ini juga masuk manifest PWA per aplikasi, perbaikan privasi, dan penulisan ulang portal member ke desain mobile-native.
Manajemen Produk dan Sistem Antarmuka
Area terberat dalam riwayat repositori: editor produk kelas, dengan empat belas commit untuk form dan pembuat jadwalnya, mulai dari kartu hari, chip jam, input waktu native, sampai pop-up berlapis yang terpotong. Ditambah visibilitas produk per kanal, yaitu tampil di website atau di aplikasi member, dan rebrand ikon untuk gym kedua.
Point of Sale dan Perbaikan Kelas Bug Database
Memisahkan point of sale ke subdomain kasir, menambahkan halaman produk per kelas untuk publik dengan CTA booking, dan menata ulang dashboard member. Tiga perbaikan pada hari ini berbagi satu akar masalah yang layak disebut: aplikasi bergantung pada konfigurasi database yang permisif, sehingga SQL lama ditolak server dengan only_full_group_by.
Onboarding Gym Baru
Membawa gym ketiga ke kode terkini, dan ini adalah diagnosis terbesar dalam pekerjaan ini. Migrasi yang gagal ternyata hanya gejala: skema tenant itu memang satu generasi lebih lama, dan aplikasi menuntut kolom deleted_at terlepas dari migrasi apa pun karena semua model memakai soft delete. Diselesaikan dengan skrip upgrade yang diuji di atas salinan yang dipulihkan.
06 Hasil yang diserahkan
- 01Upgrade skema tenant mencakup 23 tabel, 74 pernyataan kolom, dan 7 view, diverifikasi terhadap salinan yang dipulihkan dengan nol selisih tersisa.
- 023.198 catatan member dan 3.198 UUID unik bertahan setelah backfill, dengan 404 baris biodata dan 33 baris produk berpindah nilai enum tanpa kehilangan data.
- 03Booking kelas dikerjakan menyeluruh, dengan view langganan per baris yang menilai status per produk, bukan per kontainer.
- 04Point of sale dipisahkan ke subdomain kasir khusus, sehingga staf kasir tidak dapat menjangkau back-office.
- 05Rating dan ulasan fiktif beserta foto profil stok dihapus dari situs publik, diganti jumlah member langsung dari database dan rating yang bersumber dari konfigurasi.
- 06Dump database dibuat portabel dengan menghapus klausa DEFINER, sehingga bisa diimpor oleh pengguna shared hosting mana pun.
Layanan Terkait
Ingin sesuatu seperti ini?
Berikut layanan Javapixa yang mengerjakan proyek ini.