[🛠] Operations Automation #3: Migrasi otomasi cuti lama ke NAS dan koneksi HTTPS eksternal

✨ Ringkasan GPT-5.6 Sol

Catatan tentang memindahkan fungsi dan data cuti yang sudah ada ke lingkungan NAS baru, lalu memperbaiki cacat UI yang terlihat di perangkat seluler nyata setelah koneksi HTTPS eksternal tersambung.

Saya membawa fungsi dan data dari otomasi cuti lama ke lingkungan NAS baru, lalu menyambungkan jalur yang memungkinkan permintaan HTTPS eksternal mencapai aplikasi di dalam NAS. Ini bukan sekadar menjalankan container, melainkan memindahkan alur kerja yang sudah ada ke lingkungan operasional baru.

Namun, munculnya layar baru belum cukup untuk menyatakan migrasi selesai. Data karyawan dan cuti harus terlihat, sedangkan sasaran pengingat dan isi pesan harus sama dengan sistem lama. Pesan yang melewati batas harian 130 harus diteruskan ke hari berikutnya, dan queue pengiriman serta riwayatnya juga harus tetap berlanjut. Jika satu saja hilang, hasilnya akan menjadi layanan lain yang hanya memakai nama yang sama.

Saat sebelumnya saya kembali memisahkan otomasi penjualan dari administrasi karyawan, saya memutuskan untuk mereproduksi fungsi pengingat cuti yang ada terlebih dahulu sebelum memindahkannya. Setelah mulai dikerjakan, urutan itu ternyata semakin penting. Deploy ke NAS saya tunda untuk sementara.

Mereproduksi fungsi lokal dan memulihkan data

Saya lebih dahulu menjalankan FastAPI, Next.js, dan MariaDB di lingkungan Compose lokal yang terisolasi. Agar tidak bertabrakan dengan layanan yang ada, port, network, volume, dan credential juga saya pisahkan. Setelah login sebagai administrator dan membuka data karyawan serta cuti, saya mencocokkan sasaran pengingat, teks yang dihasilkan, pesan terjadwal di atas batas 130, queue, dan riwayat dengan alur lama.

Saya tidak ingin langsung menyentuh DB production. Backup SQL lama saya pulihkan ke MariaDB yang terpisah, lalu saya bandingkan schema dan jumlah data pada table utama. Saya juga memastikan data tetap ada setelah backend dinyalakan ulang. Baru setelah itu saya memiliki patokan perilaku lokal. Jika kemudian muncul masalah di NAS, saya dapat membedakan apakah kodenya berubah atau image maupun network yang salah.

Pulihnya backup belum berarti transisi operasional selesai. Akun administrator, ponsel kerja, dan pesan SMS nyata belum melewati jalur baru tersebut.

Dua lapis pembatasan pada jalur pengiriman SMS nyata

Hambatan berikutnya adalah SMS nyata. Tanpa mengirim pesan, saya tidak bisa melihat jalur menuju ponsel Android kerja sampai selesai. Namun, saya juga tidak bisa membiarkan pengiriman production terbuka hanya untuk pengujian.

Karena itu, mode pengiriman server saya bagi menjadi tiga.

NO_SEND
ALLOWLIST_SEND
PRODUCTION

Kondisi normalnya adalah NO_SEND. Hanya saat pengujian, satu penerima yang diizinkan saya masukkan ke ALLOWLIST_SEND. Target dicocokkan menggunakan hash SHA-256, bukan nomor telepon dalam teks biasa, dan jumlah pesan yang dapat di-claim server dibatasi menjadi satu. Di dalam aplikasi Android saya juga memasang budget terpisah sebanyak satu pesan. Saya ingin memastikan kesalahan pengoperasian pada server atau aplikasi tetap tidak dapat mengirim pesan kedua.

Saya tidak memvalidasi keadaan ini hanya dengan membaca kode. Dengan Computer Use, saya membuka layar administrasi yang sebenarnya dan memeriksa NO_SEND, jumlah yang saat itu dapat di-claim, queue, dan riwayat. Pada layar yang sama, saya juga membandingkan hasil kerja Codex dengan kode implementasinya.

Saya juga membuat package pengujian terpisah agar tidak langsung menyentuh aplikasi operasional. Pada perangkat Android yang terhubung melalui USB, saya memakai adb reverse untuk menghubungkannya dengan endpoint lokal. Dengan demikian, satu SMS nyata selesai dengan status SUCCESS, dan saya melihat pesannya tiba di perangkat penerima.

Ada satu hasil yang ambigu. Pengguna menerima pesannya, tetapi delivery callback Android tidak tertangkap. SUCCESS berarti operator menerima permintaan pengiriman, bukan berarti delivery callback sudah selesai. Jika penerimaan nyata dan status callback dianggap sebagai keberhasilan yang sama, nanti akan semakin membingungkan untuk menentukan cara menangani kasus UNKNOWN.

Setelah melihat satu pesan, saya langsung mengembalikan sistem ke NO_SEND. Android readiness bernilai 0, dan claim server menghasilkan 204 No Content. Pengujian berakhir dalam keadaan ketika tindakan tambahan yang tidak sengaja tidak dapat mengirim pesan berikutnya.

Migrasi image Docker linux/amd64 ke NAS

Saya hanya memasang layanan otomasi cuti di NAS, bukan seluruh platform otomasi. Source tidak di-build ulang di NAS; saya membuat image linux/amd64 di Mac, memeriksa hash-nya, lalu memindahkannya. Project Compose juga dipisahkan dari stack yang sudah ada. Dengan susunan ini, mengganti satu backend tidak akan ikut membuat ulang MariaDB dan Frontend.

Menghubungkan HTTPS eksternal dan Reverse Proxy

Layar login terbuka di alamat baru, dan data karyawan serta cuti lama juga terlihat. Namun, penjelasan tertulis saja tidak cukup untuk menunjukkan sekilas bagaimana permintaan dari browser eksternal mencapai MariaDB. Terutama ketika menjelaskan apakah 3101 adalah port yang terbuka ke Internet atau hanya digunakan di dalam NAS, batas keduanya terus bercampur. Saya menggambar jalur permintaannya.

Setelah digambar, terlihat jelas bahwa dari luar hanya HTTPS 443 yang diperlukan. Router meneruskan 443 ke NAS, lalu reverse proxy NAS memeriksa hostname dan mengirim permintaan ke Frontend di 127.0.0.1:3101. Backend 8000 dan MariaDB 3306 hanya terhubung di dalam Docker network. Karena 3101 juga hanya terikat pada loopback NAS, port itu tidak dapat diakses langsung dari Internet.

Cloudflare tidak dimasukkan ke jalur utama karena alasan yang sama. Saya sudah memiliki authoritative DNS, IP publik tetap, dan kendali langsung atas Router. Dengan hanya menambahkan A record layanan dan mengelola sertifikat di NAS, satu komponen perantara dapat dihilangkan. Sebagai gantinya, pembaruan sertifikat dan port forwarding harus saya kelola sendiri. Selain port 80 untuk penerbitan dan pembaruan sertifikat, permintaan layanan nyata hanya diterima melalui 443.

Verifikasi di perangkat seluler nyata dan perbaikan UI responsif

Terbukanya alamat HTTPS eksternal belum berarti migrasi selesai. Pada perangkat Android nyata yang terhubung melalui USB, saya mengakses alamat baru lewat jaringan seluler dan mencoba langsung alur login, dashboard, daftar karyawan, riwayat SMS, serta pengelolaan cuti. Layarnya terbuka, tetapi belum layak digunakan apa adanya.

Masalah yang luput ketika saya hanya mempersempit browser PC muncul sekaligus di perangkat nyata. Pada dashboard, sidebar desktop memenuhi sebagian besar layar sehingga card dan teks terjepit menjadi kolom vertikal yang sempit.

Pada semua gambar perbandingan di bawah, sisi kiri adalah sebelum perbaikan dan sisi kanan adalah sesudahnya.

Pada daftar karyawan, judul dan button terpotong per karakter, sedangkan table yang lebar dipaksa masuk ke ruang sempit. Saya mempertahankan aliran horizontal pada judul dan area tindakan, lalu membiarkan table digeser ke samping sejauh yang diperlukan, bukan memampatkan isinya.

Filter pada riwayat SMS dan pengelolaan cuti mengalami masalah yang sama. Beberapa kolom input dan rentang tanggal dipaksakan ke dalam satu baris. Pada layar kecil, saya mengaturnya terutama dalam dua kolom dan memindahkan rentang tanggal ke baris terpisah agar setiap bagian bisa dibaca dan disentuh.

Setelah perbaikan, saya kembali melakukan deploy Docker image baru dan login lagi melalui ponsel yang sama. Saya membuka menu, menggulir layar, lalu melihat langsung setiap filter dan table untuk memastikan cacat yang pertama kali terlihat sudah hilang. Pengujian yang awalnya hanya untuk melihat apakah network eksternal mencapai container di NAS akhirnya berlanjut hingga memperbaiki layar yang benar-benar digunakan.

Status migrasi per tahap dan verifikasi UI administrator/E2E

Setelah migrasi NAS, akses eksternal, dan satu SMS internal tersambung, saya membuka kembali keseluruhan roadmap dan melihat bahwa tahap 1 sampai 3 telah dilewati. Posisi saat ini adalah tahap 4: melakukan deploy UI administrator yang telah diperbaiki sebagai image baru, lalu memeriksa kembali semua page melalui ADB dan perangkat nyata.

Setelah diagram ini dipasang, batas pekerjaan berikutnya juga menjadi jelas. Akses eksternal memang sudah lolos, tetapi dogfooding di kantor pusat belum dapat dimulai sebelum verifikasi ulang layar administrator pada perangkat nyata selesai. Jadi, tahap selanjutnya bukan menambahkan fitur baru, melainkan memeriksa sampai tuntas bahwa UI yang diperbaiki mempertahankan alur kerja yang sama di desktop dan seluler.

Kondisi aman dan rollback sebelum transisi operasional

Untuk saat ini, stack baru sengaja dikonfigurasi agar tidak melakukan apa pun secara otomatis.

ENABLE_SCHEDULER=False
SMS_SEND_MODE=NO_SEND
SMS_ALLOWLIST_MAX_CLAIMS=0

Credential administrator tidak saya tulis di Compose maupun image. Di NAS, credential diberikan melalui secret file dengan izin 0600; di Mac, saya menyimpannya di Keychain.

Saya sudah dapat login di alamat baru dan membaca data, dan dalam kondisi terbatas satu SMS juga berhasil tiba. Melalui jaringan seluler eksternal, saya memeriksa seluruh alur dari login, pembacaan data, hingga pengoperasian layar. Meski begitu, sebelum menghapus layanan pesan cuti lama, masih perlu ditentukan cara pemulihan untuk pengiriman tanpa delivery callback serta mendapatkan persetujuan atas kondisi pengiriman nyata.

Karena itu, container dan volume lama hanya saya hentikan dan tetap dibiarkan utuh. Yang dibutuhkan selanjutnya bukan menambah konfigurasi. Saya perlu menentukan cara memulihkan pengiriman tanpa callback, lalu membuka pengiriman nyata mulai dari jumlah terbatas dalam kondisi yang telah disetujui.

Terpisah dari migrasi teknis, saya menulis perubahan yang saya rasakan ketika AI dapat ikut melihat ponsel nyata serta layar administrasi Router dan NAS di Saat tahu cara memanfaatkan AI secara aktif, hal-hal yang bisa dilakukan terasa tak terbatas.