Saat ini, banyak perusahaan beroperasi tanpa kemampuan untuk mengontrol secara langsung komposisi paket di repositori eksternal, bahkan jika mereka menggunakan mirroring, proxying, dan caching. Hal ini mengarah pada fakta bahwa lingkungan eksekusi terus berubah, khususnya, komposisi gambar buruh pelabuhan berubah lebih sering daripada yang dibutuhkan produksi.
Ada situasi ketika perubahan yang tidak diinginkan yang terkandung dalam dependensi eksternal dapat memengaruhi komposisi produk yang sedang dikembangkan. Ini terutama berlaku selama sertifikasi produk. Akibatnya, sertifikasi tertunda, pengujian malam hari dan pengujian integrasi gagal, produksi di lokasi (lingkungan produksi yang terletak di sumber daya organisasi sendiri) saat menjalankan perbaikan terbaru, dan sebagainya. Dalam artikel baru, kami telah menjelaskan pendekatan untuk menghindari masalah ini.
Apa yang ingin kami capai
Sebelum melanjutkan dengan deskripsi pendekatan, beberapa kata tentang tugas yang ingin kami selesaikan:
- Dapatkan kendali penuh atas komposisi paket eksternal dalam rilis (prediktabilitas).
- Perbaiki komposisi repositori eksternal untuk peluncuran cepat hotfix dengan pengujian tambahan minimal (kecepatan).
- Menyediakan produk QA berdiri dengan lingkungan yang berulang, dapat diprediksi, dan tetap (pengulangan).
- Independensi dari keberadaan saluran komunikasi eksternal (otonomi).
- Peralihan instan ke repositori resmi jika terjadi kegagalan (toleransi kesalahan).
- Validasi kunci yang dijamin untuk repositori eksternal di jalur perakitan (kepercayaan).
- Dan yang paling penting, transfer manajemen dan kontrol atas komposisi paket eksternal ke tangan tim produk dan manajer rilis (manajemen mandiri).
Fitur Build Life Cycle Analysis
Pendekatan kami memecahkan masalah dalam memperbaiki komposisi repositori eksternal untuk tanggal tertentu, untuk rilis atau fitur. Diagram berikut mengilustrasikan pengelolaan rilis, pembuatan fitur, dan siklus hidup hotfix.
Mari kita ambil repositori bersyarat Debian Stretch sebagai contoh. Pendekatan ini berlaku untuk repositori Docker, SaltStack, dll. Tiga irisan telah dicatat pada timeline untuk tanggal T1, T2 dan T3.
| T1 | T2 | T3 | |
|---|---|---|---|
| meregang | 20200305 | 20200420 | 20200615 |
| Fitur1 | 20200304 | 20200304 | 20200501 |
| Fitur2 | 20200304 | 20200304 | 20200601 |
| Fitur3 | 20200301 | 20200406 | 20200406 |
Kami telah membuat tabulasi konten penyimpanan Debian Stretch eksternal untuk membangun distribusi Feature1, Feature2, dan Feature3. Dari tabel tersebut Anda dapat melihat bahwa komposisi repositori eksternal dikontrol oleh masing-masing cabang secara independen. Kami telah membuat perjanjian untuk diri kami sendiri untuk menggunakan cabang utama untuk Debian Stretch setiap hari dan menandai setiap potongan dalam format YYYYMMDD, misalnya 2020304 untuk potongan 4 Maret 2020. Tabel merangkum snapshot dari repositori eksternal yang digunakan untuk distribusi di setiap cabang di tiga titik waktu yang berbeda dan komposisi di wizard untuk Debian Stretch. Tim untuk setiap fitur atau untuk setiap rilis memperbarui komposisi repositori eksternal sesuai kebijakannya dan sesuai dengan siklus pengembangannya.
Menggunakan Feature1 sebagai contoh: tim produk mulai mengembangkan fitur baru dan memperbaiki komposisi repositori eksternal mulai 20200228 di file konfigurasi (lihat diagram di atas).
Beralih ke 20200228
deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free
Selama pengembangan, karena kemunculan paket baru, maka perlu memperbarui database paket ke tanggal 20200304. Pindah repositori kerja ke tanggal yang diinginkan.
Beralih ke 20200304
deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free
Selanjutnya, peralihan lain dari basis paket ke tanggal 20200501.
Beralih ke 20200501
deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free
Jika sekarang kita menggambar irisan waktu, kita akan melihat bahwa pada saat pengembangan T1 dan T2 Feature1 sedang berlangsung pada basis paket dibekukan pada 4 Maret 2020. Dan dalam pemotongan T3, pengembangan sudah berlangsung dengan basis paket baru untuk 1 Mei 2020.
Manajemen ketergantungan multi-rilis produk
Sekarang mari kita lihat manajemen ketergantungan untuk beberapa rilis produk aktif. Ada tiga rilis dukungan, 2.5, 2.6 dan 2.7.
Dalam tabel, kita melihat korespondensi rilis dan tanggal pembuatan snapshot repositori. Ini menunjukkan snapshot mana dari komposisi repositori eksternal yang digunakan untuk membangun versi distribusi tertentu.
| Melepaskan | Komposisi |
|---|---|
| 2.5.128, 2.5.135, 2.5.207 | 20200301 |
| 2.6.201, 2.6.215, 2.6.315 | 20200301 |
| 2.7.210, 2.7.217, 2.7.305 | 20200404 |
Alih-alih memberi nama irisan berdasarkan tanggal YYYYMMDD, kami juga menggunakan penamaan tag dalam format <ProjectName.ReleaseVersion> (release_name.release_version produk, misalnya name.2.2) atau <ProjectName-FeatureNumber> (tambahkan nomor fitur, misalnya 3).
Snapshot untuk 2.5 pada 20200301
deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301
Jadi, selama pengembangan rilis 2.5, tim memperbaiki komposisi repositori dependen mulai 20200301. Di suatu tempat di bulan April, tim memulai rilis 2.6 baru dan memutuskan untuk menggunakan komposisi paket repositori eksternal dari 2.5. Buat snapshot 2.6 baru dari snapshot 2.5. Di masa mendatang, repositori untuk rilis 2.5 dan 2.6 dapat dengan mudah menyimpang. Kami telah membuat tag kami sendiri debian-stretch-projectname-2.6 untuk 2.6.
Snapshot untuk 2.6 pada 20200301
deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301
Dalam kasus rilis 2.7, tim dapat memulai pengembangan dari cabang master - cuplikan harian dari repositori asli.
Snapshot untuk 2.7 pada 20200404
deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404
Manajemen ketergantungan multi-produk
Mari kita lihat manajemen ketergantungan multi-produk menggunakan contoh dua produk dengan siklus rilis berbeda dan tim produk mereka sendiri: Stealth dan Infiniti.
Mari mengomentari tabel apa yang terjadi dan kapan.
| Produk | Melepaskan | Komposisi |
|---|---|---|
| stealth2.2 | r2.2.124 | 20200301 |
| stealth2.2 | r2.2.131, r2.2.162 | 20200305 |
| infiniti4.0 | r4.0.235, r4.0.241 | 20200303 |
| infiniti4.0 | r4.0.250 | 20200308 |
1. Biarkan pengembangan versi 2.2 dari proyek Stealth dimulai pada 1 Maret 2020, untuk ini dibuat snapshot dari komposisi database paket untuk tanggal saat ini. Rilis rilis 2.2.124 dibuat dengan database paket dari repositori eksternal dari 20200301.
Stealth 2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301
2. Pada hari kelima, database paket diperbarui. Repositori kerja debian-stretch-stealth-2.2 secara instan beralih ke tanggal yang diinginkan, rilis rilis 2.2.131 dan 2.2.162 dibuat dengan paket repositori eksternal dari 20200305. Tanpa manipulasi tambahan di lingkungan, semua 100500 layanan mikro produk langsung menerima lingkungan baru dalam jalur perakitan 20200305 ...
Stealth 2.2.0
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305
3. Paralel dengan hari ketiga, pengembangan proyek Infiniti versi 4.0 dimulai dan sepotong repositori untuk tanggal 20200303 dibuat untuknya. Versi 4.0.235 dan 4.0.241 dirilis dengan paket repositori eksternal untuk 20200303.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303
4. Setelah rilis versi 4.0.241, tim memutuskan untuk memperbarui komposisi repositori ke 20200308 dan merilis rilis baru dengan komposisi baru dari paket eksternal. Versi 4.0.250 keluar dengan bundel paket untuk 20200308.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308
Dua opsi untuk beralih di antara status repositori memungkinkan Anda memilih pendekatan yang sesuai untuk proses pengembangan. Dalam kasus pertama, kami beralih ke status yang diinginkan dengan menentukan snapshot dari repositori pada tanggal tertentu. Dalam kasus kedua, untuk produk multikomponen, kami menggunakan potongan bernama dan memindahkannya ke tanggal yang diinginkan. Mekanisme ini menyediakan cutoff switching satu kali di semua 100500 komponen produk.
Kami mengelola irisan setiap repositori eksternal dalam wadah Docker terpisah, jadi kapan saja kami dapat mengganti repositori tertentu untuk diunduh dari jaringan eksternal jika terjadi beberapa kecelakaan.
Unduh daftar semua repositori
# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.listPembuatan otomatis irisan repositori eksternal
Repositori diperbarui setiap malam sesuai dengan penjadwal GitLab. Ketika repositori baru ditambahkan, perubahan secara otomatis diterapkan ke server.
Pada saat melakukan potongan baru dari repositori eksternal, sertifikatnya dicentang, jika berbeda dari yang disimpan dengan kami, maka pembaruan tidak dilakukan, dan kami menerima pesan kesalahan.
Hasil
- Mempersiapkan versi baru kit distribusi untuk sertifikasi tidak lagi memusingkan. Untuk periode sertifikasi, kami memperbaiki komposisi distribusi, dan jika Anda perlu segera memperbaiki sesuatu, maka dengan kemungkinan besar tidak akan ada kesalahan dalam perbaikan terbaru yang dirilis karena perubahan lingkungan.
- Semua build fitur mendapatkan status terkelola dari repositori eksternal.
- Peluncuran hotfix dan verifikasi QA dipercepat dengan hasil yang dapat diprediksi, cepat, dan sukses.
- Feature- , .
- .
Perhatikan bahwa Debian memiliki sumber snapshot.debian.org resmi dengan snapshot harian dan penyimpanan dalam. Ini cukup untuk tugas tertentu.
Terima kasih kepada Sergey Smirnov dan komunitas atas alat yang luar biasa untuk mengelola komposisi repositori eksternal Aptly. Dari kami - kontribusi kecil untuk praktik terbaik menggunakan alat yang berguna ini dalam konveyor produksi.
Pada artikel berikutnya, kita akan berbicara tentang bundel Aptly + Simple-CDD untuk menyiapkan image ISO distribusi, mendelegasikan pengelolaan dependensi eksternal ke tim produk, dan masalah penggunaan Aptly dalam proses mengelola dependensi eksternal.
Penulis : Nikita Drachev , Alexander Pazdnikov , Timur Gilmullin