Amalan DevOps berfungsi. Kami sendiri yakin akan hal ini apabila kami mengurangkan masa pemasangan keluaran sebanyak 10 kali. Dalam sistem Profil FIS, yang kami gunakan di VTB, pemasangan kini mengambil masa 90 minit berbanding 10. Masa binaan keluaran telah berkurangan daripada dua minggu kepada dua hari. Bilangan kecacatan pelaksanaan yang berterusan telah menurun kepada hampir minimum. Untuk menjauhkan diri daripada "kerja manual" dan menghapuskan pergantungan kepada vendor, kami terpaksa bekerja dengan tongkat dan mencari penyelesaian yang tidak dijangka. Di bawah potongan adalah cerita terperinci tentang cara kami membina pembangunan dalaman sepenuhnya.
Prolog: DevOps ialah falsafah
Sepanjang tahun lalu, kami telah melakukan banyak kerja untuk mengatur pembangunan dalaman dan pelaksanaan amalan DevOps di VTB:
- Kami membina proses pembangunan dalaman untuk 12 sistem;
- Kami melancarkan 15 saluran paip, empat daripadanya telah dibawa ke pengeluaran;
- Automatik 1445 senario ujian;
- Kami berjaya melaksanakan beberapa keluaran yang disediakan oleh pasukan dalaman.
Salah satu yang paling sukar untuk mengatur pembangunan dalaman dan pelaksanaan amalan DevSecOps ternyata adalah sistem Profil FIS - pemproses produk runcit pada DBMS bukan perhubungan. Namun begitu, kami dapat membina pembangunan, melancarkan saluran paip, memasang pakej bukan keluaran individu pada produk dan mempelajari cara memasang keluaran. Tugas itu tidak mudah, tetapi menarik dan tanpa sekatan yang jelas dalam pelaksanaan: berikut adalah sistem - anda perlu membina pembangunan dalaman. Satu-satunya syarat ialah menggunakan CD sebelum persekitaran yang produktif.
Pada mulanya, algoritma pelaksanaan kelihatan mudah dan jelas:
- Kami membangunkan kepakaran pembangunan awal dan mencapai tahap kualiti yang boleh diterima daripada pasukan kod tanpa kecacatan yang teruk;
- Kami mengintegrasikan ke dalam proses sedia ada sebanyak mungkin;
- Untuk memindahkan kod antara peringkat yang jelas, kami memotong saluran paip dan menolak salah satu hujungnya ke dalam sambungan.
Pada masa ini, pasukan pembangunan saiz yang diperlukan mesti membangunkan kemahiran dan meningkatkan bahagian sumbangannya kepada keluaran ke tahap yang boleh diterima. Dan itu sahaja, kita boleh menganggap tugas itu selesai.
Nampaknya ini adalah laluan yang cekap tenaga sepenuhnya ke hasil yang diperlukan: inilah DevOps, berikut ialah metrik prestasi pasukan, inilah kepakaran terkumpul... Tetapi dalam amalan, kami menerima satu lagi pengesahan bahawa DevOps masih mengenai falsafah , dan tidak "dilekatkan pada proses gitlab, ansible, nexus dan seterusnya ke bawah senarai."
Setelah menganalisis pelan tindakan sekali lagi, kami menyedari bahawa kami sedang membina sejenis vendor sumber luar dalam diri kami. Oleh itu, kejuruteraan semula proses telah ditambahkan pada algoritma yang diterangkan di atas, serta pembangunan kepakaran sepanjang keseluruhan laluan pembangunan untuk mencapai peranan utama dalam proses ini. Bukan pilihan yang paling mudah, tetapi ini adalah jalan pembangunan yang betul dari segi ideologi.
Di manakah pembangunan dalaman bermula?
Ia bukan sistem yang paling mesra untuk digunakan. Dari segi seni bina, ia adalah satu DBMS bukan hubungan yang besar, terdiri daripada banyak objek boleh laku yang berasingan (skrip, prosedur, kelompok, dll.), yang dipanggil mengikut keperluan, dan bekerja pada prinsip kotak hitam: ia menerima permintaan dan isu. sesuatu tindak balas. Kesukaran lain yang perlu diberi perhatian termasuk:
- Bahasa eksotik (MUMPS);
- Antara muka konsol;
- Kekurangan penyepaduan dengan alat dan rangka kerja automasi yang popular;
- Jumlah data dalam berpuluh-puluh terabait;
- Muatan lebih 2 juta operasi sejam;
- Kepentingan - Kritis Perniagaan.
Pada masa yang sama, tiada repositori kod sumber di pihak kami. sama sekali. Terdapat dokumentasi, tetapi semua pengetahuan dan kecekapan utama berada di sisi organisasi luar.
Kami mula menguasai pembangunan sistem hampir dari awal, dengan mengambil kira ciri-cirinya dan pengedaran yang rendah. Bermula pada Oktober 2018:
- Mempelajari dokumentasi dan asas penjanaan kod;
- Kami mempelajari kursus pendek mengenai pembangunan yang diterima daripada vendor;
- Menguasai kemahiran pembangunan awal;
- Kami menyusun manual latihan untuk ahli pasukan baharu;
- Kami bersetuju untuk memasukkan pasukan dalam mod "pertempuran";
- Menyelesaikan isu dengan kawalan kualiti kod;
- Kami menganjurkan pendirian untuk pembangunan.
Kami menghabiskan masa selama tiga bulan untuk membangunkan kepakaran dan melibatkan diri dalam sistem, dan sejak awal 2019, pembangunan dalaman memulakan pergerakannya ke arah masa depan yang cerah, kadangkala dengan kesukaran, tetapi dengan yakin dan bermatlamat.
Penghijrahan repositori dan autotest
Tugas DevOps pertama ialah repositori. Kami dengan cepat bersetuju untuk menyediakan akses, tetapi adalah perlu untuk berhijrah daripada SVN semasa dengan satu cawangan batang ke sasaran Git kami dengan peralihan kepada model beberapa cawangan dan pembangunan Git Flow. Kami juga mempunyai 2 pasukan dengan infrastruktur mereka sendiri, serta sebahagian daripada pasukan vendor di luar negara. Saya terpaksa hidup dengan dua Gits dan memastikan penyegerakan. Dalam keadaan sedemikian, ia adalah yang lebih rendah daripada dua kejahatan.
Penghijrahan repositori berulang kali ditangguhkan; ia selesai hanya pada bulan April, dengan bantuan rakan sekerja dari barisan hadapan. Dengan Git Flow, kami memutuskan untuk memastikan perkara mudah sebagai permulaan dan menyelesaikan skema klasik dengan hotfix, membangun dan melepaskan. Mereka memutuskan untuk meninggalkan tuan (aka prod-like). Di bawah ini kami akan menerangkan mengapa pilihan ini ternyata optimum untuk kami. Repositori luaran kepunyaan vendor, biasa untuk dua pasukan, telah digunakan sebagai pekerja. Ia disegerakkan dengan repositori dalaman mengikut jadual. Kini dengan Git dan Gitlab adalah mungkin untuk mengautomasikan proses.
Isu autoujian telah diselesaikan dengan sangat mudah - kami dibekalkan dengan rangka kerja siap sedia. Dengan mengambil kira keistimewaan sistem, memanggil operasi berasingan adalah bahagian yang boleh difahami dalam proses perniagaan dan pada masa yang sama berfungsi sebagai ujian unit. Apa yang tinggal ialah menyediakan data ujian dan menetapkan susunan yang dikehendaki untuk memanggil skrip dan menilai keputusan. Apabila senarai senario, dibentuk berdasarkan statistik operasi, tahap kritikal proses dan metodologi regresi sedia ada, diisi, ujian automatik mula muncul. Sekarang kita boleh mula membina saluran paip.
Bagaimana keadaannya: model sebelum automasi
Model proses pelaksanaan yang sedia ada adalah cerita yang berasingan. Setiap pengubahsuaian telah dipindahkan secara manual sebagai pakej pemasangan tambahan yang berasingan. Seterusnya pendaftaran manual dalam Jira dan pemasangan manual pada persekitaran. Untuk pakej individu, semuanya kelihatan jelas, tetapi dengan penyediaan pelepasan, perkara menjadi lebih rumit.
Perhimpunan telah dijalankan pada tahap penghantaran individu, yang merupakan objek bebas. Sebarang perubahan adalah penghantaran baharu. Antara lain, 60β70 versi teknikal telah ditambahkan pada 10-15 pakej komposisi keluaran utama - versi yang diperoleh apabila menambah atau mengecualikan sesuatu daripada keluaran dan mencerminkan perubahan dalam jualan di luar keluaran.
Objek dalam penghantaran bertindih antara satu sama lain, terutamanya dalam kod boleh laku, yang kurang daripada separuh unik. Terdapat banyak kebergantungan pada kod yang telah dipasang dan pada kod yang pemasangannya baru dirancang.
Untuk mendapatkan versi kod yang diperlukan, adalah perlu mengikut perintah pemasangan dengan ketat, di mana objek ditulis semula secara fizikal berkali-kali, kira-kira 10-12 kali.
Selepas memasang sekumpulan pakej, saya terpaksa mengikut arahan secara manual untuk memulakan tetapan. Keluaran telah dipasang dan dipasang oleh vendor. Komposisi keluaran telah dijelaskan hampir sebelum saat pelaksanaan, yang memerlukan penciptaan pakej "decoupling". Akibatnya, sebahagian besar bekalan berpindah dari pelepasan ke pelepasan dengan ekor "decoupling" sendiri.
Kini jelas bahawa dengan pendekatan ini - memasang teka-teki keluaran pada peringkat pakej - satu cawangan induk tidak mempunyai makna praktikal. Pemasangan pada pengeluaran mengambil masa dari satu setengah hingga dua jam buruh manual. Adalah baik bahawa sekurang-kurangnya pada peringkat pemasang susunan pemprosesan objek ditentukan: medan dan struktur telah dimasukkan sebelum data untuknya dan prosedur. Walau bagaimanapun, ini hanya berfungsi dalam pakej yang berasingan.
Hasil logik pendekatan ini adalah kecacatan pemasangan wajib dalam bentuk versi objek yang bengkok, kod yang tidak perlu, arahan yang hilang dan tidak diambil kira untuk pengaruh bersama objek, yang telah dihapuskan dengan demam selepas dibebaskan.
Kemas kini pertama: lakukan pemasangan dan penghantaran
Automasi bermula dengan menghantar kod melalui paip di sepanjang laluan ini:
- Ambil penghantaran siap dari storan;
- Pasangnya pada persekitaran khusus;
- Jalankan autotest;
- Menilai hasil pemasangan;
- Panggil saluran paip berikut di sebelah arahan ujian.
Saluran paip seterusnya harus mendaftarkan tugas dalam Jira dan menunggu arahan untuk diedarkan kepada gelung ujian terpilih, yang bergantung pada masa pelaksanaan tugas. Pencetus - surat mengenai kesediaan untuk penghantaran ke alamat yang diberikan. Ini, sudah tentu, adalah tongkat yang jelas, tetapi saya terpaksa bermula di suatu tempat. Pada Mei 2019, pemindahan kod bermula dengan semakan pada persekitaran kami. Proses telah bermula, yang tinggal hanyalah untuk membawanya ke dalam bentuk yang baik:
- Setiap pengubahsuaian dilakukan dalam cawangan berasingan, yang sepadan dengan pakej pemasangan dan bergabung ke dalam cawangan induk sasaran;
- Pencetus pelancaran saluran paip ialah kemunculan komitmen baharu dalam cawangan induk melalui permintaan gabungan, yang ditutup oleh penyelenggara daripada pasukan dalaman;
- Repositori disegerakkan sekali setiap lima minit;
- Pemasangan pakej pemasangan dimulakan - menggunakan pemasang yang diterima daripada vendor.
Selepas ini, sudah ada langkah sedia ada untuk menyemak dan memindahkan kod, untuk melancarkan paip dan memasang di sebelah kami.
Pilihan ini telah dilancarkan pada bulan Julai. Kesukaran peralihan mengakibatkan beberapa rasa tidak puas hati di kalangan vendor dan barisan hadapan, tetapi pada bulan berikutnya kami berjaya menghapuskan semua kelebihan kasar dan mewujudkan proses di kalangan pasukan. Kami kini mempunyai perhimpunan mengikut komitmen dan penghantaran.
Pada bulan Ogos, kami berjaya menyelesaikan pemasangan pertama pakej berasingan pada pengeluaran menggunakan saluran paip kami, dan sejak September, tanpa pengecualian, semua pemasangan pakej bukan keluaran individu telah dilakukan melalui alat CD kami. Di samping itu, kami berjaya mencapai bahagian tugas dalaman dalam 40% komposisi keluaran dengan pasukan yang lebih kecil daripada vendor - ini adalah kejayaan yang pasti. Tugas yang paling serius kekal - untuk memasang dan memasang pelepasan.
Penyelesaian terakhir: pakej pemasangan kumulatif
Kami memahami dengan baik bahawa skrip arahan vendor adalah automasi yang sangat; kami perlu memikirkan semula proses itu sendiri. Penyelesaiannya adalah jelas - untuk mengumpul bekalan terkumpul dari cawangan keluaran dengan semua objek versi yang diperlukan.
Kami bermula dengan bukti konsep: kami memasang sendiri pakej keluaran mengikut kandungan pelaksanaan yang lalu dan memasangnya pada persekitaran kami. Semuanya berjaya, konsep itu ternyata berdaya maju. Seterusnya, kami menyelesaikan isu menskrip tetapan permulaan dan memasukkannya dalam komit. Kami menyediakan pakej baharu dan mengujinya dalam persekitaran ujian sebagai sebahagian daripada kemas kini kontur. Pemasangan berjaya, walaupun dengan pelbagai ulasan daripada pasukan pelaksana. Tetapi perkara utama ialah kami diberi kebenaran untuk memulakan pengeluaran pada keluaran November dengan pemasangan kami.
Dengan lebih daripada sebulan lagi, bekalan yang dipilih sendiri jelas membayangkan bahawa masa semakin suntuk. Mereka memutuskan untuk membuat binaan daripada cawangan keluaran, tetapi mengapa ia perlu dipisahkan? Kami tidak mempunyai Prod-like, dan cawangan sedia ada tidak bagus - terdapat banyak kod yang tidak diperlukan. Kami perlu segera mengurangkan prod-like, dan ini melebihi tiga ribu komitmen. Memasang dengan tangan bukanlah pilihan sama sekali. Kami melakar skrip yang dijalankan melalui log pemasangan produk dan mengumpul komitmen kepada cawangan. Kali ketiga ia berfungsi dengan betul, dan selepas "selesai dengan fail" cawangan itu sudah siap.
Kami menulis pembina kami sendiri untuk pakej pemasangan dan menyelesaikannya dalam seminggu. Kemudian kami terpaksa mengubah suai pemasang daripada fungsi teras sistem, kerana ia adalah sumber terbuka. Selepas beberapa siri semakan dan pengubahsuaian, hasilnya dianggap berjaya. Sementara itu, komposisi keluaran terbentuk, untuk pemasangan yang betul diperlukan untuk menyelaraskan litar ujian dengan pengeluaran, dan skrip berasingan telah ditulis untuk ini.
Sememangnya, terdapat banyak komen mengenai pemasangan pertama, tetapi secara keseluruhan kod itu berfungsi. Dan selepas kira-kira pemasangan ketiga semuanya mula kelihatan baik. Kawalan komposisi dan kawalan versi objek dipantau secara berasingan dalam mod manual, yang pada peringkat ini agak wajar.
Cabaran tambahan ialah bilangan besar bukan keluaran yang perlu diambil kira. Tetapi dengan cawangan seperti Prod dan Rebase, tugas itu menjadi telus.
Kali pertama, cepat dan tanpa kesilapan
Kami mendekati pelepasan dengan sikap optimis dan lebih daripada sedozen pemasangan yang berjaya pada litar yang berbeza. Tetapi secara literal sehari sebelum tarikh akhir, ternyata vendor belum menyelesaikan kerja untuk menyediakan pelepasan untuk pemasangan dengan cara yang diterima. Jika atas sebab tertentu binaan kami tidak berfungsi, keluaran akan terganggu. Lebih-lebih lagi, melalui usaha kami, yang sangat tidak menyenangkan. Kami tidak mempunyai cara untuk berundur. Oleh itu, kami memikirkan pilihan alternatif, menyediakan pelan tindakan dan memulakan pemasangan.
Yang menghairankan, keseluruhan keluaran, yang terdiri daripada lebih daripada 800 objek, bermula dengan betul, kali pertama dan hanya dalam 10 minit. Kami menghabiskan satu jam menyemak log mencari ralat, tetapi tidak menemui apa-apa.
Sepanjang hari berikutnya terdapat senyap dalam sembang keluaran: tiada masalah pelaksanaan, versi bengkok atau kod "tidak sesuai". Ia juga entah bagaimana janggal. Kemudian, beberapa komen muncul, tetapi berbanding dengan sistem lain dan pengalaman sebelumnya, bilangan dan keutamaan mereka adalah lebih rendah.
Kesan tambahan daripada kesan kumulatif ialah peningkatan dalam kualiti pemasangan dan ujian. Disebabkan oleh pelbagai pemasangan keluaran penuh, kecacatan binaan dan ralat penggunaan telah dikenal pasti tepat pada masanya. Pengujian dalam konfigurasi keluaran penuh membolehkan untuk mengenal pasti kecacatan dalam pengaruh bersama objek yang tidak muncul semasa pemasangan tambahan. Ia sememangnya satu kejayaan, terutamanya memandangkan sumbangan 57% kami kepada keluaran itu.
Keputusan dan kesimpulan
Dalam masa kurang dari setahun kami berjaya:
- Membina pembangunan dalaman sepenuhnya menggunakan sistem eksotik;
- Menghapuskan pergantungan vendor kritikal;
- Lancarkan CI/CD untuk legasi yang sangat tidak mesra;
- Meningkatkan proses pelaksanaan ke tahap teknikal yang baharu;
- Mengurangkan masa penggunaan dengan ketara;
- Mengurangkan bilangan ralat pelaksanaan dengan ketara;
- Dengan yakin mengisytiharkan diri anda sebagai pakar pembangunan terkemuka.
Sudah tentu, kebanyakan perkara yang diterangkan kelihatan seperti omong kosong, tetapi ini adalah ciri sistem dan batasan proses yang wujud di dalamnya. Pada masa ini, perubahan mempengaruhi produk dan perkhidmatan Profil IS (akaun induk, kad plastik, akaun simpanan, eskrow, pinjaman tunai), tetapi kemungkinan pendekatan itu boleh digunakan pada mana-mana IS yang tugas melaksanakan amalan DevOps ditetapkan. Model kumulatif boleh direplikasi dengan selamat untuk pelaksanaan berikutnya (termasuk yang tidak dikeluarkan) daripada banyak penghantaran.
Sumber: www.habr.com