EVE Online Pindah ke Python 3: Pelajaran Migrasi 2,4 Juta Baris Kode untuk Developer

EVE Online adalah salah satu game MMO paling ambisius yang pernah dibuat. Server-nya melayani ratusan ribu pemain dalam satu dunia yang sama, dengan ekonomi yang kompleks dan pertempuran luar angkasa yang bisa melibatkan ribuan karakter sekaligus. Dan di balik semua itu, ada satu detail teknis yang menarik perhatian developer: game ini berjalan di atas Python, dan baru sekarang, lebih dari dua dekade setelah rilis, mereka mulai pindah ke Python 3.

Pengumuman resmi dari tim EVE Online mengonfirmasi dimulainya proses migrasi yang mereka sebut "The Move to Python 3". Pertanyaannya yang langsung muncul di kepala developer mana pun: bagaimana cara memindahkan 2,4 juta baris kode dari Python 2 ke Python 3 tanpa menghentikan layanan yang hidup 24/7?

Kenapa EVE Online Masih Pakai Python 2?

EVE Online pertama kali dirilis pada tahun 2003. Saat itu Python 2 adalah standar industri untuk server game, dan tim EVE membangun Stackless Python, varian Python yang dioptimalkan untuk ribuan task konkuren, sebagai fondasi server-nya. Stackless Python memungkinkan jutaan objek ringan (microthreads) berjalan bersamaan, sesuatu yang sangat penting untuk mensimulasikan dunia EVE yang selalu hidup.

Selama bertahun-tahun, kombinasi Python 2 dan Stackless terbukti sangat stabil. Ini bukan keputusan malas; ini keputusan pragmatis. Server yang berjalan baik tidak perlu diubah, dan mengubah bahasa pemrograman inti dari sistem yang melayani jutaan pemain adalah risiko yang sangat besar.

Masalahnya, Python 2 resmi berakhir masa dukungannya pada Januari 2020. Sejak saat itu, tidak ada lagi patch keamanan resmi dari Python Software Foundation. Tim EVE menunda migrasi selama beberapa tahun dengan berbagai alasan yang masuk akal, tapi akhirnya tekanan keamanan, ketidakmampuan memakai library modern, dan kesulitan merekrut developer yang masih nyaman dengan Python 2 membuat migrasi tidak bisa ditunda lagi.

Skala Masalahnya

Untuk memahami mengapa migrasi ini bukan pekerjaan akhir pekan, lihat angkanya:

• 2,4 juta baris kode server yang harus dimigrasi.
• Stackless Python yang merupakan fork khusus, bukan CPython standar.
• Server yang tidak bisa berhenti — downtime berarti dunia game berhenti, dan pemain di seluruh dunia protes.
• Integrasi mendalam dengan sistem lain: database, ekonomi dalam game, chat, dan simulasi fisika.

Perbedaan antara Python 2 dan Python 3 bukan hanya soal sintaks. Ada perubahan fundamental di cara string ditangani (Unicode), perilaku pembagian integer, generator, iterasi dictionary, dan banyak lagi. Kode yang ditulis dengan asumsi Python 2 bisa berperilaku berbeda total di Python 3.

Strategi Migrasi yang Mereka Pakai

Tim EVE tidak memilih strategi "big bang" — mematikan semuanya, migrasi semalam, lalu nyalakan kembali. Itu bunuh diri operasional. Sebaliknya, mereka memilih pendekatan bertahap yang jauh lebih aman.

Pendekatan yang umum untuk migrasi sebesar ini adalah dual-runtime: menjalankan Python 2 dan Python 3 secara berdampingan, lalu memindahkan modul-modul satu per satu. Komponen yang sudah dimigrasi berjalan di Python 3, sementara yang belum tetap di Python 2, dengan lapisan komunikasi di antara keduanya. Dengan cara ini, setiap langkah kecil bisa diuji dalam lingkungan produksi yang sebenarnya tanpa menghentikan layanan.

Prosesnya biasanya terbagi dalam beberapa fase:

• Audit kode — identifikasi semua modul, library, dan dependensi yang harus berubah. Buat peta ketergantungan antar modul.
• Otomatisasi deteksi — gunakan tool seperti 2to3 dan modernize untuk menemukan pola kode yang bermasalah, lalu review manual untuk yang tidak bisa diotomatisasi.
• Migrasi lapisan demi lapisan — mulai dari library internal yang paling sedikit dependensinya, naik perlahan ke modul yang lebih kompleks.
• Pengujian terus-menerus — setiap migrasi modul diikuti pengujian integrasi di environment staging yang meniru produksi.
• Monitoring ketat — setelah masuk produksi, pantau error rate, latency, dan penggunaan memori untuk menangkap regresi yang tidak terlihat di testing.

Untuk kasus EVE, tantangan ekstra adalah Stackless Python. Mereka harus memastikan fitur-fitur Stackless yang dipakai server (seperti tasklets dan channel) tetap berfungsi di Python 3, baik dengan mem-port Stackless itu sendiri atau menggantinya dengan pendekatan lain seperti asyncio.

Pelajaran yang Bisa Diambil Developer

Migrasi EVE Online bukan sekadar berita industri game; ini studi kasus nyata untuk semua developer yang memegang codebase lama yang masih dipakai:

1. Utang teknis tidak hilang, hanya menumpuk. Semakin lama migrasi ditunda, semakin besar biayanya. Setiap fitur baru yang ditulis di atas fondasi lama menambah beban migrasi di masa depan. EVE Online menunda hampir satu dekade setelah EOL Python 2, dan biayanya jelas lebih besar daripada kalau mulai lebih awal.

2. Jangan pernah migrasi big bang. Untuk sistem yang tidak bisa berhenti, pendekatan bertahap dengan dual-runtime adalah satu-satunya pilihan yang masuk akal. Pindahkan modul kecil dulu, uji, lalu lanjut. Setiap langkah harus bisa di-rollback.

3. Otomatisasi membantu, tapi tidak menggantikan review manusia. Tool konversi otomatis menangani kasus-kasus umum, tapi perubahan semantik (seperti perilaku Unicode dan integer division) butuh pemahaman konteks. Kode yang dikonversi otomatis harus di-review dengan asumsi ia salah.

4. Test coverage adalah penyelamat. Migrasi tanpa test coverage yang baik adalah judi. Kalau codebase Anda belum punya test yang cukup, tulis dulu sebelum migrasi, bukan sesudahnya. Test yang menangkap perilaku lama (characterization tests) sangat berharga karena mendokumentasikan perilaku aktual yang harus dipertahankan.

5. Monitoring di produksi sama pentingnya dengan testing. Ada hal-hal yang hanya muncul di produksi: race condition, perbedaan timing, perilaku di bawah beban. Pastikan observability (log, metrics, tracing) sudah kuat sebelum mulai migrasi.

Relevansi untuk Developer Indonesia

Di Indonesia, banyak perusahaan masih menjalankan sistem lama (legacy) yang dibangun bertahun-tahun lalu: aplikasi PHP 5, Java 8, Python 2, atau framework yang sudah end-of-life. Cerita EVE Online relevan karena menunjukkan bahwa migrasi besar itu mungkin dilakukan, tapi butuh disiplin, kesabaran, dan strategi yang benar.

Kalau Anda memegang codebase legacy, langkah pertama yang bisa dilakukan bukan langsung migrasi, tapi membangun fondasi: pastikan kode bisa di-build dan di-deploy secara reproducible, tambah test coverage untuk bagian kritis, dan buat peta dependensi. Dari sana, migrasi bertahap bisa dimulai dengan risiko yang terkendali.

Perangkap Umum saat Migrasi Bahasa Pemrograman

Migrasi EVE Online mengingatkan pada perangkap-perangkap yang hampir selalu muncul di proyek migrasi besar, apa pun bahasanya:

1. Menganggap tool otomatis cukup. Tool konversi otomatis menghasilkan kode yang terlihat benar tapi sering salah secara semantik. Perubahan perilaku integer division di Python, misalnya, tidak akan terlihat di diff konversi. Setiap hasil konversi otomatis harus di-review dengan asumsi ia salah sampai terbukti benar.

2. Melupakan dependensi tersembunyi. Kode sering bergantung pada perilaku implisit: urutan iterasi dictionary, encoding string default, atau perilaku library pihak ketiga yang sudah lama tidak diupdate. Peta dependensi yang lengkap harus dibuat sebelum migrasi dimulai, bukan ditemukan di tengah jalan.

3. Migrasi tanpa rollback plan. Setiap langkah migrasi harus punya jalur kembali. Kalau satu modul bermasalah di produksi, harus ada cara cepat mengembalikan ke versi sebelumnya tanpa menghentikan layanan.

4. Mengabaikan perbedaan performa. Bahasa yang sama di versi berbeda bisa punya profil performa yang berbeda. Kode yang dianggap "sama" bisa lebih lambat atau lebih boros memori di versi baru. Benchmark sebelum dan sesudah migrasi untuk modul kritis itu wajib.

5. Tidak melibatkan tim operasional sejak awal. Developer yang menulis migrasi sering lupa bertanya ke tim ops: bagaimana deploy, bagaimana rollback, bagaimana monitoring. Padahal di produksi, keputusan operasional ini yang menentukan sukses atau gagalnya migrasi.

Kapan Migrasi Layak Dilakukan, Kapan Tidak

Migrasi besar bukan keputusan yang harus diambil hanya karena teknologi lama sudah end-of-life. Ada kalanya migrasi layak, ada kalanya lebih baik bertahan dengan mitigasi:

Migrasi layak dilakukan kalau: teknologi lama tidak lagi mendapat patch keamanan dan sistemnya terekspos ke internet; tim kesulitan merekrut developer yang mau bekerja dengan teknologi lama; atau kebutuhan fitur baru tidak bisa dipenuhi tanpa upgrade.

Bertahan dengan mitigasi bisa jadi pilihan kalau: sistem terisolasi dari internet, footprint-nya kecil, dan biaya migrasi jauh lebih besar daripada risiko yang dimitigasi. Isolasi jaringan, monitoring ketat, dan kompensasi kontrol bisa memperpanjang umur sistem lama dengan biaya yang terkendali.

Keputusan ini harus berbasis data: hitung biaya migrasi (developer-time, risiko downtime, biaya testing), bandingkan dengan biaya bertahan (risiko keamanan, biaya lisensi, opportunity cost kesulitan rekrut). Jangan migrasi karena tren; migrasi karena angka.

Belajar dari Komunitas Migrasi Besar

EVE Online bukan satu-satunya yang pernah migrasi codebase raksasa. Instagram memigrasi dari Python 2 ke 3 dengan pendekatan serupa: bertahap, dual-runtime, dan pengujian ketat di setiap langkah. Dropbox juga melakukan migrasi besar dari Python 2 ke 3 di tengah operasional yang terus berjalan. Pelajaran dari mereka konsisten: komunikasi internal yang jelas, tooling yang baik, dan kesabaran.

Yang membedakan proyek yang sukses dari yang gagal biasanya bukan kecerdasan teknis, tapi disiplin proses. Tim yang sukses punya checklist yang jelas, metrik kemajuan yang terukur (berapa modul sudah dimigrasi, berapa persen kode sudah di Python 3), dan mekanisme untuk menghentikan migrasi sementara kalau ada tanda-tanda masalah tanpa harus rollback total.

Kalau Anda memulai migrasi, buat metrik yang bisa dipantau sejak hari pertama: persentase modul yang dimigrasi, jumlah test yang lulus di runtime baru, error rate di produksi, dan waktu respons tim terhadap regresi. Metrik ini memberi visibilitas ke manajemen dan menjaga semangat tim tetap realistis.

Kesimpulan

EVE Online memulai perjalanan panjang memindahkan 2,4 juta baris kode dari Python 2 ke Python 3. Ini bukan berita tentang satu game; ini tentang bagaimana organisasi menangani utang teknis yang sudah mengakar di sistem yang tidak bisa berhenti.

Pelajaran terbesarnya sederhana: migrasi besar bukan soal menulis ulang semuanya, tapi soal memindahkan sistem yang hidup selangkah demi selangkah, dengan pengujian dan monitoring yang ketat di setiap langkah. Dan semakin awal dimulai, semakin murah biayanya.

Jadi, kalau Anda masih memegang codebase yang berjalan di atas teknologi end-of-life, mungkin ini saatnya mulai merencanakan migrasi. Bukan besok, bukan bulan depan, tapi sekarang, sebelum utangnya semakin besar.