Integrasi berkelanjutan di Unity: cara mengurangi waktu perakitan dan menghemat sumber daya + payline sebagai hadiah

Halo semuanya, saya berhubungan dengan Alexander Panov, pakar teknis dari Pixonic. Di perusahaan saya bertanggung jawab untuk solusi antar-proyek dan periferal dekat-proyek dan hari ini saya ingin berbagi pengalaman dan praktik terbaik saya.

Platform pengembangan dan integrasi berkelanjutan, atau CI / CD, sekarang digunakan di mana-mana di industri-industri tersebut di mana proses teknis yang berulang dan berfungsi dengan baik memainkan peran yang menentukan. Dalam artikel ini, kita akan berbicara tentang CI / CD untuk mengimplementasikan proyek Unity kami untuk pengembangan game mobile: masalah apa yang kami temui, bagaimana kami berhasil menyelesaikannya, perbaikan apa yang kami capai dan bagaimana perakitan pipa yang kami buat terdaftar.

Segera setuju bahwa kami menggunakan TeamCity dari JetBrains sebagai server CI, GitHub sebagai repositori repositori Git, dan Nexus untuk menyimpan artefak perakitan.

Jadi, kami menghadapi masalah berikut:

• Kurangnya standar pembuatan perakitan umum: praktis semua pengembang memiliki akses ke server TeamCity, sebagai akibatnya skrip perakitan ditulis dalam bahasa pemrograman yang berbeda (BASH, PowerShell, Python), dan logikanya sering diduplikasi;
• Armada yang lemah: karena kami harus membangun build untuk iOS, kami harus menggunakan armada mobil dari Mac mini. Dan karena di Unity hampir seluruh rakitan berlangsung dalam satu utas, memparalelkan rakitan pada satu mesin terbukti bermasalah;
• Sedikit efisiensi operasional yang tidak jelas: karena produktivitas yang rendah dari dukungan teknis kami, perakitan membutuhkan waktu yang sangat lama;
• Antrian besar menunggu perakitan dengan jumlah agen TeamCity yang memadai;
• Kumpulan agen terpisah untuk setiap proyek: karena lingkungan instalasi yang berbeda pada perangkat, serta file konfigurasi yang saling bertentangan antara proyek (file konfigurasi server cache, dll.), Tidak mungkin untuk mengorganisasikan kumpulan bersama.

Apa yang Anda lakukan sebagai akibatnya?

• Repositori untuk skrip perakitan

Pertama-tama, kami membuat repositori tunggal skrip untuk majelis dengan Python. Peluncuran ini dilakukan di lingkungan manajemen lingkungan virtual Pipenv dengan mem-proxy-kan perpustakaan pihak ketiga di server-nya untuk memperbarui secara cepat dan mengontrol versi dari perpustakaan yang diperlukan. Dengan demikian, kami menyediakan satu titik masuk untuk majelis semua proyek yang ada. Kami menulis ulang semua skrip dengan Python, menyatukan konfigurasi, menyebabkan standar umum, menghapus duplikat kode.

• Armada mobil baru

Itu perlu untuk mengurangi waktu perakitan, mungkin mengurangi jumlah perangkat yang digunakan.

Awalnya, kami memiliki sebuah peternakan komputer mini 13 Mac, tetapi solusi ini masih jauh dari optimal: karena kekhasan rakitan di Unity, sekitar 80% waktu perakitan akan dilakukan hanya dalam satu utas. Tambahkan ke ini sejumlah besar akses tulis ke hard drive dan kami mendapatkan bahwa satu mini Mac hampir tidak dapat mengatasi 1-2 rakitan simultan.

Hasilnya adalah kebutuhan untuk meninjau perangkat keras.

Saat mencari dan membandingkan alternatif untuk rakitan Unity, kami memperhatikan bahwa komputer berbasis AMD Ryzen, karena kinerjanya, memungkinkan perakitan hingga 8-12 rakitan pada saat yang sama tanpa kehilangan kinerja yang signifikan, sehubungan dengan itu diputuskan untuk membeli empat perangkat tersebut dengan enam SSD dan menginstal dua agen per hard drive.

Perbandingan bagaimana itu dan apa yang diberikan diberikan dalam tabel.



Waktu pembuatan rata-rata:



Selain itu, kami mengatur prioritas pemilihan agen TeamCity untuk mengurangi waktu yang dihabiskan majelis dalam antrian. Sebelumnya, masing-masing proyek kami memiliki kumpulan agen sendiri, dan karena sifat multi platform dari permainan, lingkungan yang bergantung pada proyek tidak memungkinkan membuat kumpulan bersama. Sekarang, setelah reorganisasi sistem, kami meninggalkan sejumlah agen yang ditugaskan untuk proyek, yang digunakan untuk rakitan otomatis, tetapi dapat menambahkan beberapa agen umum untuk semua proyek: mereka dimasukkan dalam pekerjaan ketika semua agen yang terkait dengan proyek yang diinginkan sedang sibuk.

• Perpustakaan BuildPipeline untuk Persatuan

Mereka memulai perpustakaan kecil untuk Unity, yang memungkinkan untuk mengatur build build di jendela editor Unity yang terpisah, dan juga memiliki kemampuan untuk menjalankan build build dalam mode batchmode. Dari fungsi utama perpustakaan: ini memungkinkan Anda untuk menambah dan menghapus definisi sebelum perakitan, menonaktifkan perpustakaan pihak ketiga atau file tertentu, menambahkan langkah pra-dan pasca-pemrosesan kustom, semua pengaturannya disimpan dalam file konfigurasi, ada juga kemungkinan warisannya.


Jendela mendefinisikan di pustaka BuildPipeline

CI / CD pipa kami saat ini

Perakitan PullRequest. Untuk setiap komitmen:

1. meluncurkan Unity untuk memeriksa kesalahan kompilasi, menentukan pembaruan dan menghasilkan solusi;
2. menjalankan tes;
3. peluncuran penganalisis statis: dengan bantuannya, analisis tambahan dilakukan pada file yang dipengaruhi oleh PullRequest saat ini;
4. Pesan tentang hasil verifikasi, yang disimpan di GitHub.

Langkah-langkah membangun proyek persatuan:

1. Menginstal Pipenv dan menjalankan skrip untuk membangun di Python: memperbarui dan menginstal pustaka Python pihak ketiga dari server kami ( proksi repositori pypi.org ) dan kemudian menjalankan skrip build.

2. Persiapan awal untuk perakitan Persatuan:

• menghapus folder Library, Bundel, aset selektif (berdasarkan mask dan / atau file tertentu), menghapus solusi (file .sln) - jika perlu;
• Membuat file informasi rakitan: nama cabang, nomor rakitan, dll. - untuk penggunaan lebih lanjut dalam pembuatan untuk debugging dan pengujian;
• menyiapkan server cache Persatuan untuk suatu proyek. Setiap proyek memiliki sendiri. Setiap pengembang juga memiliki server cache yang diatur untuk pengisian lebih cepat: ketika seorang pengembang menambahkan aset baru, itu akan secara otomatis muncul di server cache dan pada server build - sehingga mengimpor aset jauh lebih cepat.

3. Menjalankan Unity untuk memeriksa kesalahan kompilasi, memperbarui mendefinisikan, dan menghasilkan solusi.

4. Jalankan tes dan keluarlah jika ada kesalahan - jika perlu.

5. Peluncuran Unity BuildPipeline dengan konfigurasi yang diperlukan dan parameter proyek tambahan.

6. Untuk Android / iOS build - meluncurkan Gradle / Xcode:

• Gradle - GradleWrapper;
• Xcode - arsipkan XcodeProject yang diperoleh setelah Unity dan salin ke Mac mini. Secara terpisah instal dan perbarui semua sertifikat yang diperlukan dan file Profil Penyedia. Jalankan perintah Bersihkan, Arsipkan, Ekspor.
• Pada tahap ekspor, dimungkinkan untuk memisahkan tanda tangan dari build, developer dan AppStore. Tergantung pada apa yang kami kumpulkan, pilih plist yang diinginkan, atau masing-masing pada gilirannya. Pada output, kami mendapatkan dua file: Pengembang dan Rilis - untuk instalasi pada perangkat uji dan masing-masing untuk mengunggah ke AppStore.

7. Menuangkan build yang dikumpulkan dan file terkait (log, hasil tes, .obb, manifes untuk menginstal aplikasi iOS, file dsym, dll.) Ke penyimpanan artefak, untuk rakitan mandiri - mengunggah build yang dikumpulkan ke penyimpanan arsip.

8. Membuat halaman dengan kode QR untuk menginstal build, menambahkan tautan dari repositori dan membangun informasi ke database untuk pekerjaan lebih lanjut dengan aplikasi PixLauncher - kita akan membicarakannya nanti.

9. Pesan ke Slack tentang hasil perakitan: kepada orang yang meluncurkan perakitan, serta ke saluran yang diperlukan.


Pesan seperti itu datang ke Slack

Langkah selanjutnya

Sebagai langkah terakhir dari rencana, bangunan yang dikumpulkan didistribusikan ke perangkat untuk pengujian dan pengunggahan lebih lanjut ke toko.

Untuk menginstal build pada perangkat, kami menulis aplikasi kecil untuk Android dan iOS - PixLauncher. Kami menginstalnya di setiap perangkat di mana ada kemungkinan untuk memilih build dari TeamCity. Untuk kenyamanan, Anda dapat mengatur filter di dalamnya - misalnya, menambahkan konfigurasi ke favorit Anda dan kemudian melakukan tindakan dengan itu dalam satu klik. Dalam kasus build untuk Android, jika perlu, file dalam resolusi .obb diunduh secara otomatis.

Selain itu, kami mengatur kemungkinan pemasangan build melalui pemberitahuan push: kami menambahkan plug-in yang ditulis sendiri ke server TeamCity, yang memungkinkan kami untuk memilih alamat MAC perangkat yang terhubung ke jaringan lokal di halaman build. Kemudian pemberitahuan push dikirim ke perangkat ini dengan tautan ke instalasi - cara ini sekarang dilakukan dalam satu klik.

Jadi, aplikasi diizinkan untuk mempercepat pencarian build QA yang diinginkan oleh departemen dan instalasi pada perangkat untuk verifikasi selanjutnya.


Penampilan Aplikasi iOS PixLauncher

Akhirnya, mengunggah bangunan ke toko

Setelah semua tindakan dilakukan, kebutuhan untuk pengisian bangunan dan meta-informasi yang dijamin pada aplikasi kepada para pihak secara alami terbentuk.

Awalnya, sebagian besar masalah muncul dengan AppStore:

• mengisi gerbang dibuat hanya dari perangkat MacOS;
• Anda harus mengunggah video, tangkapan layar, dan deskripsi aplikasi dalam lebih dari 25 bahasa.

Ini menyebabkan hilangnya banyak waktu untuk mengisi dan macet dalam mengunduh file ke panel admin. Karena itu, kami memikirkan proses otomatisasi.

Sebagai hasilnya, kami memiliki yang berikut:

1. Di Google Disk, kami mendapatkan tablet dengan deskripsi aplikasi dalam semua bahasa;
2. Video dan tangkapan layar aplikasi disusun dalam folder dengan penamaan tertentu;
3. Di Teamcity, untuk memilih build yang sudah dirakit, mereka membuat konfigurasi tergantung pada build rilis;
4. Melalui GooglePlay API dan iTMSTransporter untuk Apple, isi informasi build dan meta tentang aplikasi di store untuk semua bahasa yang diperlukan. Jika terjadi masalah (misalnya, dengan jaringan) - kami melakukan beberapa upaya dan mengirim pesan ke Slack dengan teks kesalahan.

Seperti inilah tampilan unggahan bangunan ke AppStore

Akibatnya - beberapa angka

• Sekarang kami memiliki sekitar 400 rakitan dan hingga 60 instalasi build di perangkat per hari;
• Ada 57 konfigurasi build berbeda di TeamCity;
• Kami menggunakan 22 agen TeamCity, sementara itu dimungkinkan untuk berkembang tanpa kehilangan kinerja yang signifikan menjadi 48 agen;
• Ada kemungkinan perluasan armada secara horizontal.