Tim kami bertanggung jawab untuk pengoperasian dan pengembangan produk perusahaan besar.
Pada awal 2017, mengambil istirahat dari implementasi besar dan membaca kembali "pelajaran yang dipetik", kami dengan tegas memutuskan untuk meninjau pengembangan dan pengiriman aplikasi kami. Kami khawatir tentang kecepatan rendah dan kualitas pengiriman, tidak memungkinkan kami untuk memberikan tingkat layanan yang diharapkan pelanggan dari kami.

Sudah waktunya untuk beralih dari kata-kata ke perbuatan - untuk mengubah proses.

Artikel ini akan membahas secara singkat di mana kita mulai, apa yang kita lakukan, apa situasinya sekarang, kesulitan apa yang kita hadapi, apa yang harus kita tinggalkan, apa lagi yang kita rencanakan untuk dilakukan.

Mulai

Sedikit tentang sistem

Aplikasi ini adalah contoh klasik dari aplikasi perusahaan monolitik dari "tumpahan arsitektur tahun 2000-an":

• Dioperasikan dan dikembangkan lebih dari 15 tahun.
• Ini adalah satu set satu setengah lusin WinForms, layanan windows dan ASP. Aplikasi Net diikat ke database MS SQL tunggal.
• Ukuran basis kode: ~ 1MLOC untuk C #, ~ 9000 objek basis data. Sebagian besar logika bisnis berjalan di sisi basis data.
• Aplikasi ini terdiri dari ~ 250+ solusi untuk membuat win / web client (satu solusi per kelompok formulir terkait). Ini adalah warisan dari proses pengembangan sebelumnya dan arsitektur klien.
• Aplikasi ini mendukung beberapa jenis proses (klien) dengan mengubah konfigurasi internal: proses pengaturan, izin, bidang fleksibel, dll., Dalam tabel konfigurasi basis data sistem. Pada saat yang sama, basis kode aplikasi adalah sama untuk semua klien.
• Aplikasi ini digunakan dan didukung di 25+ situs (setiap situs adalah turunan independen dari sistem) dan melayani total beberapa ribu pengguna akhir di zona waktu yang berbeda.

Proses pengiriman sebelum transformasi

1. Pengembangan dan perakitan aplikasi yang sudah selesai dan komponennya dilakukan oleh kontraktor.
2. kode itu disimpan di sisi kontraktor (versi lokal MS TFS). Kode ditransmisikan ke pelanggan setiap bulan dalam bentuk arsip dari versi saat ini dari cabang repositori utama.
3. pengiriman dilakukan dengan pengiriman "pembaruan delta": untuk aplikasi (set dll, exe, dll.) dan komponen database (set skrip sql buat / ubah). Aplikasi dibangun dan paket delta disiapkan oleh kontraktor.
4. proses penyebaran didukung oleh sistem transportasi, perubahan diterapkan secara otomatis.

Pengiriman dilakukan sebagai bagian dari rilis bulanan (seperti yang telah saya atur, saya katakan sebelumnya di sini ).

Masalah yang ada

Kurangnya kontrol

• Meskipun kepemilikan formal kode, perakitan aplikasi yang sebenarnya oleh pelanggan tidak mungkin.
• akibatnya, tidak mungkin untuk memverifikasi operabilitas kode yang dikirimkan ke pelanggan.
• perubahan kode - tidak transparan kepada pelanggan. Tidak mungkin untuk mencocokkan perubahan yang diminta dan aktual dalam produk.
• analisis kode sulit untuk SQL, dan tidak mungkin untuk komponen C #

Masukan dan kesalahan tenaga kerja

• persiapan "paket delta" adalah prosedur yang memakan waktu untuk pengembangan, sumber kesalahan dan biaya proyek tertentu.
• Menyebarkan aplikasi Delta Packet membutuhkan pelacakan urutan paket. Kesalahan out-of-order paket adalah masalah penyebaran utama dan sumber insiden yang signifikan.
• Regresi secara teratur terjadi: kesalahan yang tampaknya telah diperbaiki dan diluncurkan koreksi ke produk muncul lagi.

Keterbatasan

• kemampuan untuk memulihkan keadaan sistem pada satu waktu di masa lalu (memutar kembali perubahan) hampir tidak ada.
• kemampuan untuk secara efektif mengukur pengembangan dan menguji sumber daya awal dengan menarik karyawan pelanggan praktis tidak ada.

Hasil yang Diharapkan

Pada awal proyek, kami menetapkan tujuan yang jelas bagi kami untuk menyelesaikan masalah yang diidentifikasi di atas.

• Transfer repositori kode ke kontrol pelanggan
• Pindahkan proses pembuatan aplikasi ke sisi pelanggan
• Memodifikasi proses distribusi perubahan, meninggalkan "delta perubahan" demi pembaruan lengkap

Selain itu, dengan menggunakan solusi yang diperoleh ketika dua tujuan pertama tercapai, kami menghitung:

• Meningkatkan kualitas teknis dari solusi yang dihasilkan melalui kontrol kode
• Tingkatkan keterlibatan pengujian dan kegunaan dengan menyediakan penyebaran swalayan.

Tahapan yang Jauh

Analisis kondisi proses pembangunan saat ini

Langkah pertama: menganalisis proses pengembangan kontraktor yang ada. Ini membantu merencanakan perubahan sehingga, jika mungkin, tidak mengganggu pekerjaan.

Sayangnya, kenalan dengan proses pengembangan menunjukkan bahwa dalam pemahaman industri TI saat ini, proses itu tidak ada.

1. Kode database dan logika bisnis untuk itu tidak dipertahankan dalam repositori yang terbaru. Alasan utama: kurangnya alat yang mengimplementasikan perakitan dari kode di repositori dan penyebaran hasilnya. Jadi, kode dalam repositori hanyalah dokumentasi.
2. Versi "nyata" dari kode basis data ada dalam "basis data pengembangan" yang sama, tempat puluhan pengembang bekerja.
3. Kode aplikasi klien (C #, ASP.NET) dipertahankan dalam repositori, tetapi kualitas dan ketepatan waktu dari komitmen tidak dijamin.
4. Perakitan komponen (bukan seluruh aplikasi) dilakukan di stasiun pengembang. Tidak sepenuhnya jelas bagaimana kode diperbarui sebelum perakitan. Komponen yang dirakit diletakkan di folder bersama bersama. Dari sana, "paket delta" dibentuk untuk pelanggan.
5. Kurangnya praktik mempertahankan cabang pembangunan. Dengan tanda-tanda tidak langsung, kami menduga ini untuk waktu yang lama - tetapi setelah menyelam ke dalam proses, semuanya menjadi jelas.

Beralih ke repositori dan sistem kontrol versi yang baru

Ketergantungan pada platform MS dan standar perusahaan menentukan pilihan lingkungan pengembangan - Team Foundation Server.
Namun, saat kami memulai proyek secara langsung (April 2017), versi Visual Studio Team Services baru saja dirilis. Produk ini tampak sangat menarik, ia ditunjuk sebagai arahan strategis untuk MS, ia menawarkan repositori git, perakitan dan penyebaran untuk on-prem dan cloud.

Corporate on-prem TFS tertinggal dari versi dan fungsionalitas VSTS, migrasi ke versi baru hanya dalam proses diskusi. Kami tidak mau menunggu. Kami memutuskan untuk segera beralih ke VSTS, karena ini mengurangi biaya overhead kami untuk mendukung platform dan memberi kami kontrol penuh atas bagaimana dan apa yang kami lakukan.

Pada saat awal perubahan, tim pengembangan memiliki pengalaman dengan TFSVC, kode aplikasi disimpan dalam repositori. Di sisi lain, GIT telah lama menjadi standar bagi komunitas TI - pelanggan dan konsultan pihak ketiga merekomendasikan untuk beralih ke sistem ini.
Kami ingin tim pengembangan terlibat dalam memutuskan sistem kontrol versi baru, dan membuat pilihan yang tepat.

Kami menggunakan dua proyek dalam VSTS dengan repositori yang berbeda - TFSVC dan GIT. Seperangkat skenario didefinisikan, yang diusulkan untuk menguji dan mengevaluasi kegunaan di masing-masing sistem.

Di antara skenario yang dievaluasi adalah:

• Buat dan gabungkan cabang
• Organisasi kerja bersama (pada satu atau cabang berbeda)
• Ubah operasi rantai (komit, batalkan)
• Integrasi pihak ketiga
• Kemampuan untuk terus bekerja ketika server tidak tersedia.

Akibatnya, seperti yang diharapkan, GIT dipilih, dan sejauh ini tidak ada yang menyesal.

Sebagai proses, kami mulai menggunakan GitFlow. Proses ini memberikan kontrol yang cukup atas perubahan dan memungkinkan pengiriman rilis, seperti yang biasa kita lakukan.

1. Kami membela cabang pengembangan dengan kebijakan yang menuntut agar semua perubahan melalui permintaan tarik.
2. Kami mencoba untuk mematuhi praktik "satu tiket - permintaan satu tarik". Perubahan dari tiket yang berbeda tidak pernah digabungkan dalam satu perubahan. Kami mencoba melakukan yang terbaik untuk menguji pada cabang fitur untuk menghindari situasi dengan koreksi di tarik tarik berikutnya.
3. Saat menggabungkan ke dalam pengembangan, semua perubahan digabung menjadi satu komit (squash).
4. Cabang rilis dibuat dari pengembangan.
5. Jika perlu, di cabang rilis, Anda dapat menambahkan perubahan terbaru secara selektif (cherry-pick) atau semua (rebase). Kami tidak melakukan koreksi langsung di cabang rilis.
6. Setelah menyebarkan rilis terbaru pada produk, ia akan dikuasai melalui push force (hanya beberapa orang yang memiliki hak ini)

Otomatisasi perakitan produk

Aplikasi itu sejumlah besar majelis, ratusan solusi. Ternyata selama proses audit, semua ini dikumpulkan secara terpisah dan "secara manual".
Pada tahap pertama, kami memutuskan untuk tidak mengulang semuanya dari awal (agar tidak menghentikan pengiriman yang ada), tetapi untuk "membungkus" perakitan dalam satu set skrip msbuild - satu skrip per komponen.
Dengan demikian, kami dengan cepat mendapatkan skrip yang melakukan semua artefak perantara yang diperlukan, dan pada akhirnya - produk jadi.

Cerita terpisah adalah desain basis data. Sayangnya, sistem mengandung beberapa komponen CLR yang tidak terstruktur dengan baik. Dependensi tidak memungkinkan basis penyebaran sederhana dengan konten. Saat ini, ini sedang diselesaikan oleh skrip pra-penempatan.
Selain itu, karena lanskap sistem yang tidak merata (SQL Server versi 2008 dan 2014 diinstal pada titik yang berbeda), maka perlu untuk mengatur perakitan proyek dasar untuk .Net versi 2.0 dan 4.0.

Setelah semua skrip siap dan diuji, mereka digunakan dalam skrip build VSTS.

Segera sebelum dimulainya perakitan, versi semua produk diperbarui ke nomor standar umum, termasuk nomor build-through dari build. Nomor yang sama disimpan dalam skrip pasca penempatan. Dengan demikian, semua komponen - database dan semua aplikasi klien - keluar secara konsisten dan bernomor sama.

Penempatan ke bangku tes

Setelah versi awal proses pembuatan selesai, kami melanjutkan persiapan skrip penempatan.

Diharapkan bahwa database adalah yang paling merepotkan.

Menyebarkan "top" salinan database nyata mengungkapkan banyak konflik antara majelis dan keadaan sistem nyata:

• Versi tidak konsisten dalam GIT dan dalam sistem nyata
• Skema basis data yang dimiliki oleh pengguna yang rencananya akan dihapus.

Stabilisasi proses pengembangan

Tentu saja, aneh untuk membicarakan hal ini, dan terlebih lagi menulis di sini, tetapi perubahan yang paling serius bagi pengembang adalah pengenalan prinsip "jika ini tidak ada dalam git, ini tidak ada." Sebelumnya, kode itu berkomitmen "untuk melaporkan kepada pelanggan." Sekarang - tanpa ini, tidak mungkin untuk memberikan apa pun.

Yang paling sulit adalah dengan kode database. Setelah beralih ke menggunakan database dari repositori, melalui perakitan dan penyebaran menggunakan sqlpackage, pendekatan "delta" digantikan oleh pendekatan "state yang diinginkan". Paket adalah sesuatu dari masa lalu, semuanya harus dikerahkan secara otomatis.

Tapi! Sampai transisi penuh ke proses penyebaran baru, perubahan masih perlu disampaikan. Dan itu perlu untuk melakukan ini dengan cara lama - "pembaruan delta".

Kami menghadapi tugas untuk memastikan konsistensi yang lengkap dan konstan dari kondisi sistem saat mengirimkan paket delta, dan isi repositori.

Untuk melakukan ini, kami mengatur proses berikut:

1. Secara teratur, kode dari repositori dikumpulkan dan digunakan ke database "model" kosong.
2. Atas dasar "model", autotest khusus sedang disiapkan. Untuk setiap objek database "model", checksum dihitung. Autotest berisi semua checksum ini dan pada saat startup ia menghitung checksum dari objek yang sesuai dari database "yang diperiksa". Setiap perbedaan dalam komposisi benda atau checksumnya menyebabkan penurunan dalam tes.
3. Tes "jatuh" secara otomatis melarang transfer paket dari lingkungan pengujian lebih jauh ke lanskap. Integrasi semacam itu telah diterapkan dalam sistem transportasi sebelumnya.

Dengan demikian, menggunakan kontrol otomatis, dimungkinkan untuk relatif cepat membawa kode basis data produk dalam git terbaru dan memeliharanya tanpa upaya tambahan dari pihak tim proyek. Pada saat yang sama, pengembang mulai terbiasa dengan kebutuhan untuk secara tepat dan tepat waktu mengkomit kode ke repositori.

Penempatan Produk pada Lingkungan Uji Integrasi

Setelah menyelesaikan tahap sebelumnya, kami melanjutkan langsung ke penerapan aplikasi pada lingkungan pengujian. Kami sepenuhnya berhenti menerapkan paket delta untuk menguji sistem dan beralih ke penerapan otomatis menggunakan VSTS.

Sejak saat itu, seluruh tim mulai menerima buah pertama dari upaya yang dikeluarkan sebelumnya: penyebaran dilakukan tanpa upaya tambahan. Kode khusus dikumpulkan, disebarkan, dan diuji secara otomatis.

Sayangnya, seperti yang kita pahami nanti, "penyelarasan repositori" mengarah pada fakta bahwa kami memiliki versi versi "berkembang" yang didukung secara stabil, tetapi versi "produksi" masih belum tersedia. Dan oleh karena itu, tidak ada yang melampaui lingkungan pengujian dengan QAS dan PRD.

Kode aplikasi di sisi database dapat dibandingkan dengan yang produktif dan memahami perbedaannya. Tidak ada yang bisa dibandingkan dengan aplikasi klien - hanya ada versi produktif terbaru dalam bentuk set file yang dapat dieksekusi, dan dari mana mereka dikompilasi, tidak mungkin untuk mengatakan dengan pasti.

Menguji produk sebagai hasil perakitan otomatis

Setelah mengubah pendekatan perakitan, produk harus menjalani pengujian regresi yang luas. Itu perlu untuk memastikan bahwa aplikasi itu berfungsi dan tidak ada yang hilang.
Saat pengujian, ternyata lebih mudah dengan fungsi yang terletak di sisi basis data. Untungnya, kami telah mengembangkan serangkaian autotes yang signifikan yang mencakup area kritis.

Tetapi tidak ada tes untuk C # - karena itu, semuanya diperiksa dengan tangan. Ini adalah jumlah pekerjaan yang signifikan, dan verifikasi membutuhkan waktu.

Leap of Faith - Penerapan Pilot Produktif

Meskipun pengujian, penerapan pada produk untuk pertama kalinya menakutkan.

Kami beruntung - kami baru saja merencanakan penyebaran sistem selanjutnya di situs baru. Dan kami memutuskan untuk menggunakan kesempatan ini untuk penyebaran pilot.
Pengguna tidak melihat, kemungkinan kesalahan perakitan baru mudah diperbaiki, pekerjaan produktif nyata belum dimulai.

Kami menyebarkan sistem, dan selama beberapa minggu berada dalam mode penggunaan pra-produktif (beban rendah, pola penggunaan tertentu yang dapat dilewati dalam produk). Selama waktu ini, beberapa cacat yang terlewatkan selama pengujian terungkap. Mereka dikoreksi saat ditemukan, dan versi baru segera diluncurkan untuk verifikasi.

Setelah peluncuran resmi dan satu minggu dukungan pasca peluncuran, kami mengumumkan bahwa ini adalah salinan pertama yang dikumpulkan dan dikirimkan "dengan cara yang baru."

Versi majelis ini menjadi versi stabil pertama dari cabang master, digantung dengan tag fisrt_deployment (kami tidak memesan ikon dengan hash dari commit).

Penempatan skala di seluruh lanskap produktif

Seperti yang dikatakan James Bond: "Kedua kalinya jauh lebih sederhana." Setelah keberhasilan penyebaran pilot, kami dengan cepat menghubungkan contoh sistem yang tersisa dari jenis yang sama.

Tetapi sistem memiliki beberapa jenis penggunaan - satu fungsi dapat digunakan untuk satu jenis, dan tidak digunakan dalam kasus lain. Dengan demikian, fungsionalitas yang diuji pada implementasi tipe pertama tidak selalu menjamin kesuksesan untuk kasus lain.

Untuk menguji fungsionalitas jenis penggunaan yang tersisa, kami mulai menggunakan proyek aktif yang sedang dikembangkan. Idenya serupa dan penyebaran pertama - kami mulai menggunakan rakitan otomatis, "menyelipkan" mereka kepada pengguna bersama dengan fungsionalitas desain. Dengan demikian, pengguna, yang bekerja dengan versi "proyek" produk, pada saat yang sama memeriksa fungsi lama.

Scaling sendiri mengungkapkan masalah teknis yang tidak terduga:

Lansekap sistem tidak homogen
Selain menerapkan aplikasi secara langsung, pertama-tama kami harus berhati-hati bahwa semuanya sama di mana saja -. Versi bersih, Powershell, dan modul. Itu semua membutuhkan waktu yang cukup lama.

Koneksi jaringan
Di beberapa situs, koneksi jaringan tidak memungkinkan memompa semua komponen perakitan. Ada batas waktu, kerusakan selama transfer. Kami memeriksa dan mencoba banyak hal - tidak terlalu berhasil.

Saya harus memikirkan solusi berikut: skrip build diselesaikan sehingga semua hasilnya dikemas menjadi satu arsip besar, yang kemudian dipotong-potong kecil (masing-masing 2 mb). Kami menyelesaikan skenario penyebaran untuk menghilangkan konkurensi saat mengunduh artefak, menerima semua fragmen 2 megabyte dan memulihkannya dari apa yang sudah dapat diperluas.

Konflik dengan antivirus
Masalah aneh lain yang kami temui adalah konflik antara perangkat lunak antivirus dan salah satu langkah penyebaran: ketika semua jenis file "mencurigakan", seperti .js, .dll, diekstrak dari arsip artefak, antivirus mulai memperhatikan mereka dengan seksama. Dan yang paling aneh adalah bahwa antivirus mulai tergesa-gesa ke file sebelum akhir pembongkaran dan proses pembongkaran turun dengan pesan "file sedang sibuk oleh proses lain". Meskipun kami berjuang dengan ini, mengecualikan folder lokal dengan artefak dari pemindaian, itu tidak terlalu baik, tetapi kami tidak menemukan yang lain.

Perbaikan proses

, " " — .

• (service-now.com) VSTS Work Items. develop — .
• CI feature . —
• "self-service"
• — . , .
• : , CI/CD ,
• ( )
• - ( ) . — , .
• VSTS , , .

Ringkasan

• MS VisualStudio Team Services ( — Azure Devops) . — GIT
• (/)
• git / GitFlow .
• code review .
• CI. , feature , .
• . , .
• ( ) — . - .
• - 1 . - .
• "" .

Total durasi - 14 bulan

Itu berlangsung, terutama pada tahap akhir, dalam banyak hal ditentukan oleh koordinasi, dan kalender yang disepakati untuk pemeliharaan sistem.

Biaya tenaga kerja

Total biaya karyawan yang terlibat dari pelanggan dan organisasi kontraktor untuk semua pekerjaan yang terkait dengan perubahan adalah sekitar 250 orang * hari.