Versi Rusia

Bayangkan Anda sedang mengembangkan perangkat lunak dan perangkat keras. Alat ini terdiri dari OS kustom distributif, server kelas atas, banyak logika bisnis, sehingga harus menggunakan perangkat keras nyata. Jika Anda melepaskan alat yang rusak, pengguna Anda tidak akan senang. Bagaimana cara melakukan rilis stabil?

Saya ingin membagikan kisah saya bagaimana kami menghadapinya.

Bukti konsep

Jika Anda tidak tahu tujuan, akan sangat sulit untuk menyelesaikan tugas. Varian penerapan pertama tampak seperti bash :

make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done 

Script disederhanakan hanya untuk menunjukkan ide utama: tidak ada CI / CD. Aliran kami adalah:

1. Dibangun di atas host pengembang.
2. Digunakan untuk menguji lingkungan untuk demo.

Pada tahap saat ini pengetahuan bagaimana hal itu disediakan, semua kludges dikenal adalah sihir kotor di dalam pikiran pengembang. Itu adalah masalah nyata bagi kami karena pertumbuhan tim.

Lakukan saja

Kami telah menggunakan TeamCity untuk proyek kami & gitlab belum populer, jadi kami memutuskan untuk menggunakan TeamCity. Kami secara manual membuat VM. Kami menjalankan tes di dalam VM.

Ada beberapa langkah dalam aliran build:

1. Instal beberapa utilitas di dalam lingkungan yang disiapkan secara manual.
2. Periksa apakah itu berfungsi.
3. Jika tidak apa-apa, maka terbitkan RPM.
4. Perbarui pementasan ke versi baru.

 make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish 

Kami menerima hasil sementara:

1. Sesuatu yang bisa dijalankan ada di cabang utama.
2. Itu berhasil di suatu tempat.
3. Kami dapat mendeteksi beberapa masalah kasual.

Apakah Anda merasakan baunya?

1. Ada neraka ketergantungan dengan RPM.
2. Setiap orang memiliki lingkungan pengembangan hewan peliharaannya sendiri.
3. Tes berjalan di dalam lingkungan yang tidak dikenal.
4. Ada tiga entitas yang sama sekali tidak terikat: OS build, ketentuan instalasi & tes.

Kurangi sihir kotor

Kami mengubah arus & proses:

1. Kami telah membuat paket meta RPM & menghapus neraka ketergantungan.
2. Kami membuat templat VM pengembangan melalui gelandangan.
3. Kami memindahkan skrip bash ke ansible.
4. Di satu sisi, kami membuat kerangka tes integrasi, tetapi di sisi lain, kami menggunakan serverpec .

Akibatnya untuk tahap saat ini kami menerima:

1. Semua lingkungan pengembangan kami identik.
2. Kode aplikasi & logika penyediaan disinkronkan dengan masing-masing.
3. Kami mempercepat proses pengembang baru onboarding.

Di satu sisi, build sangat lambat (sekitar 30-60 menit), tetapi di sisi lain cukup bagus & berhasil menangkap sebagian besar masalah sebelum jaminan kualitas manual. Namun kami menghadapi masalah baru yang berbeda, yaitu kemudian kami memperbarui kernel atau kemudian kami memutar kembali sebuah paket.

Tingkatkan itu

Kami memecahkan banyak masalah berbeda:

1. Tes integrasi bekerja lebih lambat dan lebih lambat karena templat VM dev lebih tua dari RPM aktual. Kami membangun kembali templat secara manual, lalu kami memutuskan untuk mengotomatiskannya:
   
   • Buat VMDK secara otomatis.
   • Pasang VMDK ke VM.
   • Kemas VM & unggah ke s3.
2. Dalam kasus penggabungan, tidak mungkin mendapatkan status build, akibatnya, kami pindah ke gitlab.
3. Kami biasa melakukan rilis manual setiap minggu, kami mengotomatiskannya.
   
   • Versi peningkatan otomatis.
   • Hasilkan catatan rilis berdasarkan masalah tertutup.
   • Perbarui changelog.
   • Buat permintaan penggabungan.
   • Buat tonggak baru.
4. Kami memindahkan beberapa langkah ke buruh pelabuhan (serat, menjalankan beberapa tes, mengirim pesan, membuat dokumen, dll.).

Akibatnya pada skema tahap saat ini tampak seperti:

1. Ada banyak repositori RPM / DEB untuk paket.
2. Ada s3 sebagai gudang artefak.
3. Jika Anda menjalankan build dua kali untuk cabang yang sama, Anda akan menerima hasil yang berbeda, karena dependensi paket meta tidak hardcoded.
4. Ada batas-batas yang tidak jelas (garis berwarna merah) di seluruh bangunan.

Namun, kami dapat menghasilkan rilis setiap minggu & meningkatkan kecepatan pengembangan.

Kesimpulan

Hasilnya tidak ideal, tetapi perjalanan seribu li dimulai dengan satu langkah ©.

PS itu adalah crosspost