Ubah sistem yang sudah ada dengan aman

Identifikasi kontrak di sekitar perubahan

Perangkat lunak yang sudah ada memiliki komponen pemanggil, data tersimpan, job terjadwal, dan prosedur operasi. Sebagian dependensi tidak terlihat dalam file yang ingin diedit. Agen dapat menghasilkan perubahan yang benar secara lokal tetapi merusak salah satu kontrak ini.

Sebelum implementasi, identifikasi komponen yang membaca dan menulis data yang terdampak. Periksa route, job latar belakang, laporan, dan integrasi eksternal. Periksa apakah tim lain atau versi klien lama bergantung pada perilaku saat ini.

Minta agen menunjukkan bukti untuk pemetaan ini. Hasil pencarian merupakan titik awal yang berguna, tetapi panggilan dinamis dan komponen pemakai eksternal mungkin memerlukan konfirmasi dependensi dari penanggung jawabnya.

Buat perilaku saat ini dapat diamati

Untuk modul dengan dokumentasi yang kurang, tambahkan pemeriksaan terarah pada perilaku yang harus tetap stabil. Pemeriksaan ini menjelaskan kontrak saat ini. Pemeriksaan tersebut tidak membuktikan bahwa setiap perilaku yang ada memang diinginkan.

Jika perilaku saat ini bertentangan dengan persyaratan, catat pertentangannya. Jangan pertahankan cacat keamanan hanya karena suatu pengujian merekam perilaku itu. Dapatkan keputusan yang diperlukan untuk membedakan perilaku yang dimaksud dari cacat.

Gunakan fixture yang realistis tanpa informasi sensitif. Sertakan bentuk data lama dan catatan tidak lengkap jika kondisi tersebut dapat terjadi. Skema baru yang hanya diuji dengan data baru dapat menyembunyikan masalah migrasi.

Tinjau transisi antarversi

Pertimbangkan penggantian nama fiktif dari customer_name menjadi display_name. Penggantian langsung dapat merusak instance aplikasi lama selama deployment. Memperbarui kedua file dalam satu pull request tidak membuat deployment menjadi atomik.

Pendekatan bertahap dapat mempertahankan kompatibilitas:

1. Tambahkan field baru tanpa menghapus field lama.
2. Tentukan cara penulisan baru menjaga konsistensi nilai yang diperlukan.
3. Isi data yang sudah ada pada field baru dengan proses yang dapat dijalankan ulang.
4. Verifikasi kelengkapan dan perilaku komponen pembaca data.
5. Alihkan komponen pembaca ke field baru.
6. Hapus field lama hanya setelah tidak ada lagi komponen yang menggunakannya.

Metode tepatnya bergantung pada database dan pola penulisan. Penulisan ke dua lokasi dapat menimbulkan ketidakkonsistenan jika satu penulisan gagal. Transaksi database atau metode sinkronisasi eksplisit lainnya mungkin diperlukan. Jangan terapkan contoh ini tanpa memeriksa jaminan sistem.

Martin Fowler menjelaskan transisi umum ini sebagai parallel change, yang juga disebut expand-and-contract. Gagasan utamanya adalah transisi yang kompatibel sebelum penghapusan.

Rencanakan pemulihan secara terpisah dari rollback

Rollback kode mengembalikan versi aplikasi sebelumnya. Rollback tidak otomatis membatalkan migrasi data. Versi lama mungkin tidak memahami data baru. Migrasi destruktif dapat menghapus informasi yang tidak dapat dipulihkan oleh rollback kode.

Identifikasi tindakan pemulihan untuk setiap langkah. Pengisian data lama dengan proses yang dapat dijalankan ulang mungkin aman untuk dilanjutkan. Transformasi yang salah mungkin memerlukan perbaikan dari data sumber yang disimpan. Operasi destruktif mungkin memerlukan prosedur pemulihan yang terverifikasi.

Tanyakan siapa yang bertanggung jawab atas keputusan pemulihan dan berapa lama prosesnya dapat berlangsung. Jangan perlakukan “kami memiliki cadangan” sebagai bukti bahwa pemulihan memenuhi kebutuhan layanan.

Jaga agar perubahan dapat ditinjau

Pisahkan perapian yang tidak terkait dari perubahan fungsional. Sertakan rencana kompatibilitas, hasil verifikasi, dan syarat penghapusan dalam pull request. Tandai titik setelahnya rollback memerlukan pekerjaan tambahan.

Agen dapat membantu memeriksa komponen pemakai dan menyiapkan kode migrasi. Penanggung jawab tetap harus menerima rencana transisi dan pemulihan. Desain akhir hanyalah satu bagian dari perubahan yang aman.