Bagaimana kami membangun alam semesta paralel untuk pipeline CI / CD kami (dan Anda) di Octopod

Halo, Habr! Nama saya Denis, dan saya akan memberi tahu Anda bagaimana kami disarankan untuk membuat solusi teknis guna mengoptimalkan proses pengembangan dan QA di Typeable kami. Ini dimulai dengan perasaan umum bahwa kami melakukan semuanya dengan benar, tetapi masih mungkin untuk bergerak lebih cepat dan lebih efisien - menerima tugas baru, menguji, kurang menyinkronkan. Semua ini mengarahkan kami pada diskusi dan eksperimen, yang menghasilkan solusi sumber terbuka kami, yang akan saya jelaskan di bawah dan sekarang tersedia untuk Anda.



Mari kita, bagaimanapun, tidak berlari di depan lokomotif, tetapi mulai dari awal dan memahami secara rinci apa yang saya bicarakan. Bayangkan situasi yang cukup standar - proyek dengan arsitektur tiga tingkat (penyimpanan, backend, frontend). Ada proses pengembangan dan proses jaminan kualitas di mana terdapat beberapa lingkungan (sering disebut garis besar) untuk pengujian:

• Produksi adalah lingkungan kerja utama tempat pengguna sistem pergi. 
• Pre-Production – - (, production, ; RC), production, production . Pre-production – , Production .
• Staging – , , , Production, .

Dengan Pra-produksi, semuanya menjadi cukup jelas: kandidat rilis secara konsisten pergi ke sana, riwayat rilis sama dengan di Produksi . Ada beberapa perbedaan dengan Pementasan :

1. ORGANISASI. Pengujian bagian penting mungkin memerlukan penundaan dalam menerbitkan perubahan baru; perubahan dapat berinteraksi dengan cara yang tidak terduga; kesalahan penelusuran menjadi sulit karena banyaknya aktivitas di server; terkadang ada kebingungan tentang versi apa yang diterapkan; terkadang tidak jelas akumulasi perubahan mana yang menyebabkan masalah.
2. . : production , «». staging , . . : , . , QA production , .
   
   
   
3. .
   
   
   
   
   
   
4. . . -. , . , . , .
5. . - , , , , . , , , . , . production , time-to-production time-to-market .

Masing-masing poin ini diselesaikan dengan satu atau lain cara, tetapi semua ini mengarah pada pertanyaan, apakah mungkin untuk menyederhanakan hidup kita jika kita beralih dari konsep satu staging stand ke nomor dinamisnya. Mirip dengan bagaimana kita memiliki pemeriksaan CI untuk setiap cabang di git, kita bisa mendapatkan singkatan pembayaran QA untuk setiap cabang. Satu-satunya hal yang menghentikan kami dari langkah tersebut adalah kurangnya infrastruktur dan alat. Secara kasar, untuk menerima fitur, pementasan terpisah dibuat dengan nama domain khusus, QA mengujinya, menerima atau mengembalikannya untuk direvisi. Sesuatu seperti ini: 





Dengan pendekatan ini, masalah lingkungan yang berbeda diselesaikan dengan cara alami:





Yang menarik, setelah diskusi, pendapat dalam tim dibagi menjadi "ayo coba, saya ingin lebih baik dari sekarang" dan "sepertinya sangat normal, saya tidak melihat masalah yang mengerikan," tetapi kita akan kembali ke ini nanti.

Jalan kami menuju solusi

Hal pertama yang kami coba adalah prototipe yang dibuat oleh DevOps kami: kombinasi docker-compose (orkestrasi), rundeck (manajemen) dan portainer (introspeksi), yang memungkinkan kami menguji keseluruhan arah pemikiran dan pendekatan. Ada masalah dengan kenyamanan:

1. Setiap perubahan memerlukan akses ke kode dan pemeriksaan ulang, yang dimiliki oleh pengembang, tetapi tidak dimiliki, misalnya, insinyur QA.
2. Ini dibesarkan pada satu mesin besar, yang segera menjadi tidak mencukupi, dan untuk langkah berikutnya, Kubernetes atau yang serupa sudah dibutuhkan.
3. Portainer memberikan informasi bukan tentang status staging tertentu, tetapi tentang sekumpulan container.
4. Saya harus terus-menerus menggabungkan file dengan deskripsi tahapannya, stand lama harus dihapus.

Bahkan dengan semua kekurangannya dan dengan beberapa ketidaknyamanan pengoperasian, pendekatan masuk dan mulai menghemat waktu dan tenaga tim proyek. Hipotesis itu diuji, dan kami memutuskan untuk melakukan semuanya dengan cara yang sama, tetapi dengan cara yang salah. Dalam mengejar tujuan untuk mengoptimalkan proses pengembangan, kami mengumpulkan persyaratan untuk yang baru dan memahami apa yang kami inginkan:

1. Gunakan Kubernetes untuk menskalakan ke sejumlah lingkungan pementasan dan memiliki seperangkat alat standar untuk DevOps modern.
2. Solusi yang mudah diintegrasikan ke dalam infrastruktur yang sudah menggunakan Kubernetes.
3. , Product QA-. , . – .
4. , CI/CD , . , Github Actions CI.
5. , DevOps .
6. , , / - .
7. Informasi lengkap dan daftar tindakan harus tersedia bagi pengguna super dalam personel insinyur dan pimpinan tim DevOps.

Dan kami mulai mengembangkan Octopod . Nama tersebut merupakan kebingungan dari beberapa pemikiran tentang K8S, yang kami gunakan untuk mengatur semua yang ada di proyek: banyak proyek di ekosistem ini mencerminkan estetika dan tema laut, dan kami membayangkan semacam gurita yang mengatur banyak wadah bawah air dengan tentakel. Ditambah lagi, Pod adalah salah satu entitas pendiri di Kubernetes.



Pada tumpukan teknis, Octopod adalah Haskell, Rust, FRP, kompilasi ke JS, Nix. Tapi secara umum ceritanya bukan tentang ini, jadi saya tidak akan membahas ini lebih detail.



Model baru ini dikenal sebagai Multi-staging di dalam perusahaan kami. Mengoperasikan beberapa lingkungan pementasan secara bersamaan mirip dengan perjalanan melintasi alam semesta paralel dan dimensi dalam fiksi ilmiah (dan tidak terlalu banyak). Di dalamnya, alam semesta mirip satu sama lain dengan pengecualian satu detail kecil: di suatu tempat pihak yang berbeda memenangkan perang, di suatu tempat terjadi revolusi budaya, di suatu tempat terjadi terobosan teknologi. Premisnya mungkin kecil, tetapi perubahan apa yang dapat ditimbulkannya! Dalam proses kami, prasyarat ini adalah konten dari setiap cabang fitur yang terpisah.





Implementasi kami berlangsung dalam beberapa tahap dan dimulai dengan satu proyek. Ini termasuk menyesuaikan orkestrasi proyek dari sisi DevOps dan mengatur ulang proses pengujian dan komunikasi dari manajer proyek.



Sebagai hasil dari sejumlah iterasi, beberapa fitur Octopod sendiri telah dihapus atau diubah tanpa bisa dikenali. Misalnya, di versi pertama kami memiliki halaman dengan log penerapan untuk setiap sirkuit, tetapi inilah nasib buruknya - tidak setiap tim menerima bahwa kredensial dapat mengalir melalui log ini ke semua karyawan yang terlibat dalam pengembangan. Akibatnya, kami memutuskan untuk menyingkirkan fungsionalitas ini, dan kemudian mengembalikannya dalam bentuk yang berbeda - sekarang dapat disesuaikan (dan karenanya opsional) dan diimplementasikan melalui integrasi dengan dasbor kubernetes .



Ada juga poin lain: dengan pendekatan baru, kami menggunakan lebih banyak sumber daya komputasi, disk, dan nama domain untuk mendukung infrastruktur, yang menimbulkan pertanyaan tentang pengoptimalan biaya. Jika Anda menggabungkan ini dengan kehalusan DevOps, maka materi akan diketik di pos terpisah, atau bahkan dua, jadi saya tidak akan melanjutkannya di sini.



Sejalan dengan pemecahan masalah yang muncul pada satu proyek, kami mulai mengintegrasikan solusi ini ke yang lain, ketika kami melihat minat dari tim lain. Hal ini memungkinkan kami memastikan bahwa solusi kami dapat disesuaikan dan cukup fleksibel untuk kebutuhan berbagai proyek. Saat ini, Octopod telah banyak digunakan di negara kita selama tiga bulan.

Hasil dari

Akibatnya, sistem dan proses diimplementasikan dalam beberapa proyek, ada minat dari satu proyek lagi. Menariknya, bahkan kolega yang tidak melihat adanya masalah dengan skema lama sekarang tidak ingin beralih kembali ke skema tersebut. Ternyata untuk beberapa kami memecahkan masalah yang bahkan tidak mereka ketahui!



Yang paling sulit, seperti biasa, adalah implementasi pertama - sebagian besar masalah teknis dan masalah terkait dengannya. Umpan balik dari pengguna memungkinkan untuk lebih memahami apa yang perlu ditingkatkan di tempat pertama. Di versi terbaru, antarmuka dan pekerjaan dengan Octopod terlihat seperti ini:





Bagi kami, Octopod telah menjadi jawaban untuk pertanyaan prosedural, dan saya akan menyebut keadaan saat ini sebagai kesuksesan yang tegas - fleksibilitas dan kenyamanan telah meningkat dengan jelas. Masih ada masalah yang belum terselesaikan sepenuhnya: kami menyeret otorisasi Octopod itu sendiri dalam cluster ke Atlassian oauth untuk beberapa project, dan proses ini ditunda. Namun, ini tidak lebih dari masalah waktu, secara teknis masalah tersebut telah diselesaikan pada pendekatan pertama.

Sumber terbuka

Kami berharap Octopod akan bermanfaat tidak hanya untuk kami. Kami akan dengan senang hati menerima saran, permintaan tarik, dan informasi tentang bagaimana Anda mengoptimalkan proses serupa. Jika proyek menarik bagi audiens, kami akan menulis tentang fitur orkestrasi dan pengoperasian bersama kami.



Semua kode sumber dengan contoh konfigurasi dan dokumentasi tersedia di repositori di Github .