Untuk semuanya, 50 cangkir kopi sudah cukup.
Selain aturan praktis yang diuraikan di atas, kami menerbitkan catatan singkat tentang poin-poin yang perlu diperhatikan agar tidak ada yang pecah dalam pertempuran dan dalam proses. Catatan itu dibuat dalam pengejaran tentang rilis layanan seluler yang sepenuhnya bermigrasi ke .Net Core (awalnya ada di sini ). Kami berhasil melakukan operasi ini tanpa disadari oleh pelanggan, hampir tanpa menghentikan proses pengembangan utama.
Di bawah ini adalah rencana aksi yang sudah jadi, akan ada daftar tes yang sangat luas, gambar ini akan ada di sini untuk suasana hati:
Jadi, dalam langkah-langkah:
1. Rencanakan sprint panjang dengan fitur besar dan / atau regresi
Dengan penulisan ulang kode mendasar, layanan akan membutuhkan waktu untuk mendesak selama mungkin agar memiliki waktu untuk memperbaiki semua kelemahan pada lingkungan pengujian.
2. Pada sprint yang tepat untuk menulis ulang kode pada .Net Core
Mengapa penting untuk tidak memulai bisnis ini sebelumnya? Karena Anda harus menarik dua cabang kode dengan .net baru dan lama, karena kapan pun burung yang mendesak dapat terbang atau Anda perlu melakukan demo fitur baru, dan kemudian Anda perlu melakukan perubahan pada cabang stabil lama. Untuk mengalami keprihatinan minimal tentang hal ini, lebih baik mempersingkat momen kondisi transisi.
Ngomong-ngomong, ketika bekerja dengan kode, kami dengan cepat sampai pada kesimpulan bahwa lebih baik menyimpan dua salinan repositori secara lokal. Lebih mudah dan lebih nyaman daripada mengganti dua cabang besar.
- Jika memungkinkan, tulis ulang antarmuka WCF di webapi dalam layanan yang digunakan
Implementasi .Net Core dari klien WCF masih jauh dari ideal. Terlepas dari kenyataan bahwa luka lama dalam beberapa cara diperbaiki, dalam versi baru Anda masih harus menggunakan solusi ( 1 , 2 ).
Untuk cerita: di .Net Core 2.0, versi stabil WCF adalah 4.4.2 dari repositori myget. Dia, misalnya, tidak memiliki masalah dengan batas waktu lebih awal
Di awal migrasi, kami menggunakan versi .Net Core 2.0. Sementara itu, Microsoft telah merilis .Net Core 2.1. Siapa yang tertarik untuk mengagumi keberhasilan orang-orang Redmond dalam mengoptimalkan platform, silakan baca apa kemajuan yang dibuat mesin pencari Bing ketika meningkatkan ke versi baru (spoiler: latensi turun 34%!)
Kami juga meningkatkan ke .Net Core 2.1 dan WCF 4.5.3. Dan kami tidak lupa untuk menentukan di Dockerfile basis microsoft / dotnet image baru: 2.1-aspnetcore-runtime. Apa yang mengejutkan ketika, alih-alih 1.4GB, mereka melihat ukuran gambar 0,5GB (kita berbicara tentang gambar Windows, jika tiba-tiba).
3. Bersiap untuk tes dan demo
Kami memiliki dua lingkungan yang tersedia. Kami meninggalkan demo dengan versi lama sebagai referensi. Layanan baru dikerahkan ke lingkungan pengujian - dijalankan pada pengembang dan penguji.
Ada beberapa kebingungan karena fakta bahwa pengembang biasanya bekerja dengan tes, dan penguji terutama dengan demo. Jika perlu untuk menyegarkan kembali layanan yang lama, situasinya persis kebalikan dari yang normal. Karenanya, diskusi dan lembar contekan tentang di mana dan apa yang harus dicari berguna.
Untuk menjalankan layanan .Net Core di IIS, Anda harus menginstal modul yang menyertai runtime.
AppPool beralih ke CLR Runtime = Tidak Ada Kode yang Dikelola.
Dalam solusi di web.config standar , penting untuk tidak lupa mengatur requestTimeout yang diinginkan dan menonaktifkan modul WebDAV, jika ada metode DELETE.
Lebih lanjut, ada dua opsi untuk menerbitkan layanan di IIS:
- Anda melakukan sinkronisasi MSDeploy - itu berarti Anda juga perlu beralih -enableRule: AppOffline
- Anda mempublikasikan file - itu artinya tepat sebelum publikasi Anda harus meletakkan file app_offline.htm di direktori layanan, dan setelah publikasi hapus
Baik itu, dan yang lain memungkinkan untuk menghentikan proses kerja dan untuk membuka file yang dapat dieksekusi. Jika tidak, akan terjadi kesalahan bahwa file tidak tersedia untuk ditimpa.
Kami menolak logging melalui Nlog yang mendukung Serilog, dan kehilangan kompresi log otomatis - di Serilog tidak ada fitur seperti itu. Dalam hal ini, Anda dapat disimpan menggunakan alat Windows biasa dan menginstal kompresi NTFS di properti direktori.
4. Tes
Berikut adalah daftar periksa paling menyusut untuk tempat-tempat yang paling rapuh:
- periksa kembalinya kode status Permintaan buruk, Tidak Sah, Tidak diubah, Tidak ditemukan - semua yang dapat diberikan API
- periksa permintaan login untuk semua kode status
- membuat diagram ketergantungan eksternal; sebagai aturan, semua informasi yang diperlukan ada di pengaturan aplikasi
- usir metode yang memengaruhi pekerjaan mereka
- periksa pencatatan permintaan eksternal
- periksa fungsi pengaturan untuk parameter pengaturan aplikasi; coba ubah mereka menjadi panas
- periksa caching http untuk kode status positif dan negatif
- Header ETag
- kontrol cache header
- periksa permintaan lama dan batas waktu
- periksa permintaan dengan jawaban kosong
- periksa metode DELETE (WebDAV dinonaktifkan atau tidak)
- periksa pekerjaan dengan konten mentah
- unggah dan unduh satu / beberapa file
- unggah file dengan ukuran di atas batas
- tata letak header Content-Disposition
- periksa semua tajuk lainnya; menempatkan semuanya dalam kode cukup mudah
- periksa eksekusi kode kondisional ketika berpindah lingkungan
if (env.IsDevelopment()) - periksa putuskan sambungan dari klien dan server
- bandingkan dengan standar swagger.json - akan membantu mendeteksi perbedaan dalam bidang yang ditransmisikan
Aplikasi seluler kami menggunakan generator kode untuk bekerja dengan API berdasarkan deskripsi swagger.json, jadi penting bahwa perbedaan dari deskripsi asli minimal. Dalam versi terbaru dari Swashbuckle.AspNetCore, antarmuka dan swagger.json yang dihasilkan telah banyak berubah. Saya harus memutar kembali ke versi lusuh Swashbuckle.AspNetCore 1.2.0 dan menambahkan beberapa filter.
5. Pelana untuk berkelahi sambil minum kopi
Dalam kasus kami, lingkungan tempur terdiri dari dua node: aktif dan pasif.
Agar peralihan ke layanan baru terjadi tanpa disadari, kami menggandakan kumpulan dan situs pada setiap node, dan menulis skrip untuk mengalihkan ikatan antara yang lama dan situs yang baru.
Jadi, jika terjadi keadaan darurat, kami dapat dengan cepat beralih ke versi yang lama.
Selanjutnya, setelah penyebaran ke pertempuran, dalam waktu seminggu kami menjadi yakin akan kelayakan layanan dan menyalakan lampu hijau untuk rilis aplikasi mobile. Kehidupan di proyek dengan aman kembali ke program sebelumnya.
Subtotal
Sekarang layanan kami sepenuhnya siap untuk menumbuhkan wadah buruh pelabuhan untuk pengiriman ke cluster. Kami siap untuk ditempatkan di Kubernetes dan Service Fabric.
Sekarang persiapan sedang dilakukan untuk penyajian infrastruktur baru kepada pelanggan. Kami akan menceritakan tentang pencapaian kami di seri berikutnya, jaga terus denyut nadi Anda;)