UPD: bagian kedua artikel sudah siap .Halo, Habr! Nama saya Alexander Izmailov. Di Badoo, saya memimpin tim insinyur rilis. Saya tahu bahwa di banyak perusahaan Anda dapat mengirim perubahan kode kepada orang yang terlatih khusus, dia melihat mereka dan menambahkannya ke tempat mereka seharusnya (misalnya, inilah yang terjadi dengan kode Git). Dan saya ingin berbicara tentang bagaimana kami mengotomatiskan proses ini dengan kami.
Kisah saya akan terdiri dari dua bagian. Pada bagian ini, saya akan berbicara tentang apa yang ingin kami capai dari sistem baru, bagaimana tampilannya dalam versi pertama, dan mengapa pada akhirnya kami harus mengulanginya. Pada bagian kedua, kita akan berbicara tentang proses pembuatan ulang sistem dan tentang bonus tak terduga yang diberikannya kepada kita.
Gambar:
sumberSekali waktu di perusahaan kami semua orang dapat membuat perubahan mereka langsung ke cabang utama dan meletakkannya dengan tangan mereka sendiri. Untuk melakukan ini, kami menulis utilitas MSCP khusus yang bekerja cukup primitif: ia menyalin perubahan dari satu mesin ke mesin lain dan mengatur hak yang diperlukan.
Seiring berjalannya waktu, perusahaan tumbuh - dan kami harus berpikir tentang otomatisasi proses, termasuk proses menyusun perubahan kecil. Jadi kami mendapat ide untuk membuat sistem tambalan. Pertama-tama, kami ingin agar pengembang dapat mengirim perubahan mereka ke Git dan meletakkannya di server. Untuk bagian kami, kami menuntut agar pengembang lain melihat perubahan dan bahwa mereka terikat dengan tugas dari sistem pelacakan bug kami (kami menggunakan Jira).
Patch kolektor 6000Saya harus mengatakan bahwa persyaratan ini tidak menarik bagi semua pengembang. Tampaknya bagi kami bahwa menghabiskan beberapa menit untuk membuat tugas bukanlah suatu hal, tetapi bagi kami ini berarti penggunaan sistem yang lebih disengaja. Tetapi para pengembang mulai menolak, dengan alasan bahwa mengeluarkan perubahan membutuhkan waktu beberapa kali lebih sedikit daripada membuat tiket baru. Akibatnya, kami masih memiliki tugas "universal", yang dilampirkan ratusan tambalan.
Selain itu, sistem itu disusun dengan tujuan memperbaiki masalah yang mendesak, dan menemukan pengulas untuk tambalan pada pukul tiga pagi bisa jadi sulit.
Apa yang kita butuhkan
Ya, hanya cahaya di jendela ... Masalah kita dapat dibagi menjadi dua bagian: kami membutuhkan beberapa cara untuk menerima perubahan pada repositori dan beberapa cara untuk menyusun perubahan ini.
Kami memutuskan pertanyaan pertama dengan cukup cepat: kami membuat formulir yang kami harus lampirkan perubahan kami dan menunjukkan detail (peninjau dan tugas).
Di halaman kedua, Anda bisa melihat perubahan, menolak atau menerimanya.
Setelah konfirmasi, perubahan jatuh ke master.
Pertanyaan kedua: bagaimana perubahan ini dapat dikirim ke server dengan cepat? Saat ini, banyak yang menggunakan integrasi terus-menerus, dan itu bisa melakukan pekerjaan dengan baik jika pembangunan dan tata letak yang "jujur" tidak memakan banyak waktu.
Perakitan yang adil
Perakitan kami selalu sangat rumit. Prinsip umumnya adalah ini: di direktori yang terpisah, kami meletakkan file seperti yang akan di server tujuan; kemudian kami menyimpan status ini dalam snapshot (snapshot dari sistem file) dan meletakkannya.
Kami memasukkan kode PHP ke direktori, yang kami ambil dari repositori apa adanya, menambahkan file yang dihasilkan (misalnya, templat dan terjemahan) ke dalamnya. Kami meletakkan statika secara terpisah. Ini adalah proses yang agak rumit, dan Anda dapat mencurahkan seluruh artikel untuk itu, tetapi sebagai hasilnya, kami memiliki peta versi untuk menghasilkan tautan file untuk pengguna yang meninggalkan bersama dengan kode utama.
Selanjutnya, keadaan direktori perlu disimpan di suatu tempat. Untuk melakukan ini, kami menggunakan
perangkat blok , yang kami sebut loop. Seluruh direktori disalin ke perangkat kosong, yang kemudian diarsipkan dan dikirim ke server "utama" yang terpisah. Dari server ini kami mengambil arsip dalam proses tata letak. Setiap arsip berukuran 200 MB, dan saat dibuka, loopnya memiliki berat 1 GB. Kami membutuhkan waktu sekitar lima menit untuk membangun tanpa statis.
Tata letak yang adil
Pertama, kami perlu mengirimkan arsip ke server tujuan. Kami memiliki ribuan, jadi pertanyaan pengiriman bagi kami selalu menjadi masalah besar: kami memiliki beberapa platform (pusat data), dan pada seribu server “paling tebal” dengan kode. Dalam upaya mencapai kinerja yang lebih baik (waktu dan sumber daya minimum), kami mencoba berbagai metode: dari SCP sederhana hingga torrent. Pada akhirnya, kami memutuskan untuk menggunakan UFTP. Metode ini cepat (dalam cuaca bagus - satu menit), tetapi, sayangnya, tidak bebas masalah. Secara berkala, sesuatu pecah, dan kami harus lari ke admin dan penggiat jejaring.
Setelah arsip (entah bagaimana) menemukan dirinya di server, itu harus dibongkar, yang juga tidak gratis. Prosedur ini tampaknya sangat mahal jika Anda ingat bahwa itu dilakukan ribuan kali, meskipun secara paralel pada mesin yang berbeda.
Tidak ada perakitan
Jadi, secara jujur memposting perubahan memerlukan banyak waktu, dan kecepatan pengiriman sangat penting untuk sistem patch, karena diasumsikan bahwa mereka akan menggunakannya ketika ada sesuatu yang tidak lagi berfungsi. Oleh karena itu, kami kembali ke ide menggunakan MSCP: cepat dan mudah diimplementasikan. Dengan demikian, setelah perubahan muncul di wizard, pada halaman terpisah dimungkinkan untuk menguraikan file yang diubah secara bergantian.
Itu hidup
Sistem sedang bekerja. Meskipun ada beberapa ketidakpuasan dengan hal-hal kecil, para pengembang dapat melakukan pekerjaan mereka, dan untuk ini mereka tidak memerlukan akses ke master, atau akses ke server.
Tapi, tentu saja, dengan metode tata letak ini, kami punya masalah. Beberapa dapat diprediksi, beberapa kami bahkan memutuskan entah bagaimana. Sebagian besar terkait dengan pengeditan file secara paralel.
Satu tambalan untuk banyak file
Contoh masalah yang dapat diprediksi. File-file baru disajikan secara bergantian. Apa yang harus dilakukan jika Anda perlu mengubah beberapa file dan perubahan terkait dengannya? Misalnya, saya ingin menambahkan metode baru dalam satu file dan segera menggunakannya dalam file lain. Selama tidak ada loopback menggunakan metode (lihat
rekursi timbal balik ), itu cukup untuk mengingat urutan tata letak file yang benar.
Keputusan yang jujurUntuk mengatasi masalah tersebut, kami perlu mengganti beberapa file secara atom. Dalam kasus satu file, solusinya diketahui: Anda perlu menggunakan nama operasi file. Misalkan kita memiliki file F, dan kita perlu mengganti isinya. Untuk melakukan ini, buat file TMP, tulis informasi yang diperlukan, lalu buat ganti nama TMP F.
Mari menyulitkan tugas. Misalkan kita memiliki direktori D, dan kita perlu mengganti isinya. Operasi penggantian nama tidak akan membantu kami, karena tidak dapat mengganti direktori yang tidak kosong. Namun, ada solusinya: Anda dapat mengganti direktori D dengan yang disebut tautan simbolik (symlink). Maka konten itu sendiri akan terletak di tempat lain, misalnya, di direktori D_1, dan D akan menjadi tautan ke D_1. Saat penggantian diperlukan, konten baru ditulis ke direktori D_2, tempat tautan TMP baru dibuat. Sekarang ganti nama TMP D akan berfungsi karena operasi ini dapat diterapkan ke tautan.
Solusi ini terlihat tepat: Anda dapat mengubah seluruh direktori dengan kode, menyalin file lama dan menulis yang baru di atas. Masalahnya adalah menyalin semua kode itu panjang dan mahal. Anda dapat mengganti hanya subdirektori di mana file berubah, tetapi kemudian semua subdirektori dengan kode harus berupa tautan, karena kami tidak dapat mengganti direktori yang diisi dengan apa pun selama proses tata letak. Tidak hanya solusi ini terlihat sangat rumit - Anda harus ingat untuk menambahkan beberapa batasan sehingga kedua proses tidak dapat secara bersamaan mengubah direktori atau direktori dan subdirektori yang sama.
Akibatnya, kami tidak dapat menemukan solusi teknis, tetapi kami menemukan cara untuk menyederhanakan hidup: kami membuat tata letak beberapa file dengan satu tindakan di antarmuka. Pengembang menentukan tata letak file, dan sistem mengirimkannya.
Beberapa tambalan per file
Lebih sulit jika ada satu file, dan ada beberapa pengembang yang ingin mengubahnya. Kami menerapkan tambalan pertama, tetapi tidak menguraikannya. Pada titik ini, tambalan kedua tiba dan diminta untuk membusuk. Apa yang harus dilakukan Lebih menarik lagi, jika tambalan kedua diterapkan, dan saat ini kami diminta untuk menguraikan tambalan pertama.
Mungkin, kita perlu mengklarifikasi bahwa kita selalu meletakkan hanya versi terbaru dari wizard. Kalau tidak, masalah lain bisa muncul. Misalnya, meletakkan versi lama di atas yang baru.
Kami tidak menemukan solusi yang sangat bagus untuk masalah ini. Kami menunjukkan kepada pengembang perbedaan antara apa yang mereka lay out dan apa yang ada di mesin pada waktu tertentu, tetapi ini tidak selalu berhasil. Misalnya, mungkin ada banyak perubahan, dan pengembang bisa terburu-buru atau hanya malas (apa pun bisa terjadi).
Banyak tambalan, dan semua orang mengubah file yang sama
Ini adalah opsi terburuk yang bahkan tidak ingin Anda pikirkan. Jika perubahan dari beberapa pengembang memengaruhi beberapa file yang sama, sistem tambalan kami tidak dapat membantu secara khusus - tetap bergantung pada perhatian pengembang dan kemampuan mereka untuk berkomunikasi satu sama lain. Namun secara teori, sangat mungkin untuk mendapatkan "ikan" ketika, dalam urutan tata letak apa pun, di beberapa titik di server akan ada kode yang rusak sebagian.
Gambar:
sumberMasalah besi
Masalah lain muncul ketika karena alasan tertentu salah satu server menjadi tidak tersedia. Kami memiliki mekanisme untuk mengecualikan server seperti itu dari tata letak, yang bekerja cukup baik; kesulitan muncul setelah mereka kembali bertugas. Faktanya adalah bahwa versi konfigurasi dan kode pada server yang bekerja diperiksa bersama kami (ada seluruh departemen pemantauan!), Dan kami memastikan bahwa semua versi mutakhir ketika server kembali beroperasi. Tetapi kami tidak memiliki versi untuk tambalan - kami hanya menyalin file baru ke kode saat ini.
Kami tidak menemukan cara yang akurat untuk membuat versi tambalan yang terurai, tetapi kami mencoba menyelesaikan masalah dengan penyelesaian masalah. Misalnya, rsync dari mesin tetangga di akhir proses tata letak. Tapi entah bagaimana kami tidak bisa memeriksanya.
Kami membahas beberapa solusi untuk masalah ini, misalnya, kami ingin menerapkan tambalan pada server "utama" juga (penting untuk diingat bahwa kami sedang menyebarkan versi paket, yaitu, kami perlu menerapkan tambalan dan mengemas versi kembali), tetapi itu cukup sulit untuk diterapkan.
Sendok madu
Namun, selain masalah, ada aspek positif.
Pertama, para pengembang dengan cepat menemukan bahwa, selain memperbaiki hal-hal, menggunakan sistem patch, Anda kadang-kadang dapat mengunggah fungsionalitas baru, misalnya, ketika Anda sangat membutuhkannya. Seperti di perusahaan mana pun, kami memiliki force majeure. Tetapi jika sebelumnya kita harus membuat bangunan yang luar biasa, di mana penguji dan insinyur rilis terganggu, sekarang pengembang dapat menguraikan beberapa perubahan sendiri.
Kedua, beberapa orang istimewa dengan hak tidak lagi diperlukan untuk memperbaiki sesuatu. Setiap pengembang sendiri dapat memposting suntingannya. Tapi ini belum semuanya: build secara umum menjadi lebih mudah, sekarang masalahnya dibagi menjadi kritis dan yang bisa diperbaiki menggunakan patch. Ini memungkinkan untuk mundur lebih jarang dan membuat keputusan lebih cepat tentang apakah kami berhasil.
Sederhananya, kami menyukai sistem dan mendapatkan popularitas. Kami terus berusaha memperbaikinya, tetapi dengan masalah yang diuraikan kami harus hidup beberapa tahun lagi. Dan bagaimana kami memutuskannya, bagaimana sistem bekerja sekarang, dan bagaimana kami hampir membunuh liburan Tahun Baru selama proses pembaruan, saya akan memberi tahu di bagian kedua artikel.