Menghilangkan waktu henti melalui pembaruan layanan berversi

Secara historis, administrator perlu membuat server offline untuk memperbarui dan meningkatkan perangkat lunak lokal. Namun, waktu henti adalah nonstarter lengkap untuk layanan 24×7 global. Banyak layanan cloud modern adalah dependensi penting bagi pengguna untuk menjalankan bisnis mereka. Tidak pernah ada waktu yang tepat untuk menurunkan sistem, jadi bagaimana tim dapat memberikan layanan berkelanjutan sambil menginstal pembaruan keamanan dan fitur penting?

Dengan menggunakan pembaruan versi, layanan penting ini dapat ditransisikan dengan mulus dari satu versi ke versi lain saat pelanggan secara aktif menggunakannya. Tidak semua pembaruan sulit. Memperbarui tata letak atau gaya front-end itu mudah. Perubahan pada fitur bisa rumit, tetapi ada praktik terkenal dengan untuk mengurangi risiko migrasi. Namun, perubahan yang berasal dari tingkat data memperkenalkan kelas tantangan baru yang memerlukan pertimbangan khusus.

Memperbarui lapisan secara terpisah

Dengan layanan online terdistribusi di beberapa pusat data dan penyimpanan data terpisah, tidak semuanya dapat berubah secara bersamaan. Jika layanan umum dibagi menjadi kode aplikasi dan database, yang mungkin dibuat versinya secara independen satu sama lain, salah satu sisi tersebut perlu menyerap kompleksitas penanganan penerapan versi.

Seringkali, penerapan versi lebih mudah ditangani dalam kode aplikasi. Sistem yang lebih besar biasanya memiliki sedikit kode warisan, seperti SQL yang berada di dalam databasenya. Daripada lebih mempersulit SQL ini, kode aplikasi harus menangani kompleksitas. Secara khusus, Anda dapat membuat sekumpulan kelas pabrik yang memahami penerapan versi SQL.

Selama setiap sprint, buat antarmuka baru dengan versi tersebut sehingga selalu ada kode yang cocok dengan setiap versi database. Anda dapat dengan mudah mengembalikan biner apa pun selama penyebaran. Jika terjadi kesalahan setelah menyebarkan biner baru, kembali ke kode sebelumnya. Jika penyebaran biner berhasil, mulai layanan database.

Jadi bagaimana cara kerjanya? Misalnya, asumsikan bahwa tim Anda saat ini menyebarkan Sprint 123. Biner memahami skema database Sprint 123 dan mereka memahami skema Sprint 122. Pola umumnya adalah bekerja dengan versi/sprint N dan N-1 dari skema SQL. Biner mengkueri database, menentukan versi skema mana yang mereka bicarakan, lalu memuat pengikatan yang sesuai. Kemudian, kode aplikasi menangani kasus ketika skema data baru belum tersedia. Setelah versi baru tersedia, kode aplikasi dapat mulai menggunakan fungsionalitas baru yang diaktifkan oleh versi database terbaru.

Bergulir maju hanya dengan tingkat data

Setelah database ditingkatkan, layanan berada dalam situasi roll-forward jika terjadi masalah. Migrasi database online rumit dan sering kali multi-langkah, jadi bergulir ke depan biasanya merupakan cara terbaik untuk mengatasi masalah. Dengan kata lain, jika peningkatan gagal, pemutaran kembali kemungkinan juga akan gagal. Ada sedikit nilai dalam berinvestasi dalam upaya untuk membangun dan menguji kode putar kembali yang tidak pernah diharapkan oleh tim Anda untuk digunakan.

Urutan penyebaran

Pertimbangkan skenario di mana Anda perlu menambahkan sekumpulan kolom ke database dan mengubah beberapa data. Transisi ini harus tidak terlihat oleh pengguna, yang berarti menghindari kunci tabel sebanyak mungkin dan kemudian menahan kunci untuk waktu sesingkat mungkin sehingga tidak terlihat.

Hal pertama yang kita lakukan adalah memanipulasi data, mungkin dalam tabel paralel menggunakan pemicu SQL untuk menjaga data tetap sinkron. Migrasi dan transformasi data besar terkadang harus multi-langkah atas beberapa penyebaran di beberapa sprint.

Setelah data tambahan atau skema baru dibuat secara paralel, tim masuk ke mode penyebaran untuk kode aplikasi. Dalam mode penyebaran, ketika kode melakukan panggilan ke database, kode pertama-tama mengambil kunci pada skema dan kemudian merilisnya setelah menjalankan prosedur tersimpan. Database tidak dapat berubah antara waktu panggilan ke database dikeluarkan dan ketika prosedur tersimpan berjalan.

Kode peningkatan berfungsi sebagai penulis skema dan meminta kunci penulis pada skema. Kode aplikasi lebih diprioritaskan dalam mengambil kunci pembaca, dan kode peningkatan berada di latar belakang yang mencoba memperoleh kunci penulis. Di dalam kunci penulis, hanya sejumlah kecil operasi yang sangat cepat yang diizinkan pada tabel. Kemudian kunci dirilis dan aplikasi merekam versi baru database yang digunakan dan menggunakan antarmuka yang cocok dengan versi database baru.

Peningkatan database semuanya dilakukan menggunakan pola migrasi. Sekumpulan kode dan skrip melihat versi database lalu membuat perubahan bertambah bertahap untuk memigrasikan skema dari versi lama ke versi baru. Semua migrasi diotomatisasi dan diluncurkan melalui layanan manajemen rilis.

UI web juga harus diperbarui tanpa mengganggu pengguna. Saat meningkatkan file JavaScript, lembar gaya, atau gambar, hindari mencampur versi lama dan baru yang dimuat oleh klien. Hal ini dapat menyebabkan kesalahan yang dapat kehilangan pekerjaan yang sedang dalam proses, seperti bidang yang sedang diedit oleh pengguna. Oleh karena itu, Anda harus membuat versi semua file JavaScript, CSS, dan gambar dengan menempatkan semua file yang terkait dengan penyebaran ke dalam folder versi terpisah. Ketika UI web melakukan panggilan kembali ke tingkat aplikasi, aset dengan versi tertentu dimuat. Hanya saat tindakan pengguna menghasilkan refresh halaman penuh, antarmuka pengguna web baru akan dimuat ke browser. Pengalaman pengguna tidak terganggu oleh peningkatan.

Langkah berikutnya

Microsoft telah menjadi salah satu perusahaan pengembangan perangkat lunak terbesar di dunia selama beberapa dekade. Pelajari cara Microsoft mengoperasikan sistem yang andal dengan DevOps.