Nama saya Eduard Matsukov, saya membuat Taximeter - aplikasi untuk driver Yandex.Taxi. Saya terlibat dalam infrastruktur dan segala sesuatu yang berhubungan dengannya. Beberapa waktu lalu saya membuat laporan - saya berbicara tentang pengalaman persahabatan TeamCity dengan proyek kami dan dengan pengembang pada umumnya. Bagian terpisah dari laporan dikhususkan untuk apa yang harus dilakukan Kotlin dengannya.
- Hampir setiap hari mereka datang kepada saya secara pribadi dan kepada pengembang kami dengan pertanyaan. Dan di mana mendapatkan perakitan? Dan di mana mendapatkan cabang seperti itu? Mengapa sesuatu jatuh? Di mana masalah dalam kode saya? Mengapa ada sesuatu yang tidak berfungsi dengan benar? Untuk melakukan ini, kami memiliki banyak infrastruktur yang ditulis sendiri dalam proyek, plugin, berbagai peretasan dan trik yang kami gunakan. Di satu sisi, untuk membuat hidup lebih mudah bagi pengembang, di sisi lain, untuk mengimplementasikan tugas bisnis tertentu.
Dan pada titik tertentu, tentu saja, kami menggunakan CI dan TeamCity juga. Kami menjadi bingung - kami mengajar TeamCity untuk berteman dengan Kotlin dan membawa, bisa dikatakan, seluruh CI dan seluruh majelis ke tingkat yang sama sekali baru.
Tapi pertama-tama, sedikit sejarah - untuk memahami bagaimana kita sampai pada ini dan mengapa tingkat ini saya sebut kanon terpisah. TeamCity telah ada di Yandex selama bertahun-tahun. Kami harus tinggal di server bersama ini, tempat seluruh backend, seluruh frontend, dan, baru-baru ini, semua aplikasi seluler di-host. Sekitar dua tahun yang lalu kami semua berkumpul. Dan setiap pengembang mengatur setiap proyek bahkan tidak seperti yang dia inginkan, tetapi sejauh yang dia bisa atau sejauh dia mengerti seberapa besar dia ingin memahami sistem. Dan tidak ada satu orang pun yang tahu segalanya dan tahu caranya. Hanya sedikit orang yang ingin repot, mempelajari templat secara terpisah, TeamCity liar. Karena itu, semua orang menggergaji, siapa yang banyak.
Kami tinggal di server tunggal ini, dan tahun lalu kami mengalami kecelakaan di TeamCity. Sekitar satu minggu benar-benar downtime. Sidang tidak dikumpulkan, pengujian terus-menerus mengeluh. Seseorang dibuat, dikumpulkan secara lokal.
Ini disebabkan oleh fakta bahwa server TeamCity kami, secara kasar, merupakan solusi setinggi lutut yang tiba-tiba tumbuh menjadi layanan yang luar biasa. Ini digunakan oleh ribuan pengembang di Yandex. Tentu saja, ada semacam toleransi kesalahan, tetapi juga menolak. Kali berikutnya TeamCity diperbarui setelah restart, ternyata beberapa hard drive hanya runtuh, dan kami tidak bisa bangkit lagi. Saya harus keluar.
Kita perlu menarik kesimpulan dari semua yang terjadi. Dan kami, tentu saja, membuat kesimpulan ini: kami menganalisis mengapa itu terjadi dan bagaimana memastikan bahwa ini tidak terjadi lagi.
Pertama-tama, adalah penting bahwa kami naik untuk waktu yang sangat lama dan memulihkan layanan kami. Dengan layanan, maksud saya baik proses teknis dan sebagian proses bisnis untuk pengiriman rilis dangkal, untuk pertemuan permintaan kumpulan. Kami kehilangan banyak artefak, termasuk rilis yang dibuat, kehilangan banyak waktu karena permintaan kumpulan, pada kenyataan bahwa pengujian tidak dapat melakukan tugasnya dengan baik. Dan tentu saja, kami menghabiskan sedikit waktu untuk memulihkan proyek dari awal, mengkonfigurasi ulang seluruh struktur, seluruh sistem pembangunan. Dan kemudian kami menyadari bahwa sudah waktunya untuk mengubah sesuatu dan mengatur server kami sendiri.
Kami pergi ke ini untuk waktu yang lama. Bukan untuk mengatakan bahwa hanya satu kecelakaan yang menyebabkan kesimpulan ini. Secara umum, kami memutuskan bahwa sudah waktunya untuk pergi ke gunung, untuk melakukan semua ini sendiri. Kami memulai peluncuran layanan. Ini dilakukan dengan sangat cepat: beberapa hari dan Anda selesai. Ketika Anda menyebarkan semua ini sendiri dan Anda dapat menggali ke dalam, mengelola sedikit, maka fitur menarik yang mencolok. Salah satunya - TeamCity baru memungkinkan Anda mengonfigurasi versi.
Versi sangat primitif, tetapi pada saat yang sama sangat dapat diandalkan, indah dan keren. Segala sesuatu yang disimpan di TeamCity mengenai Anda atau proyek lainnya dapat diunggah dengan aman ke Git, dan Anda dapat hidup dengan bahagia di sana. Tetapi ada beberapa masalah.
Masalah pertama adalah bahwa semua orang terbiasa bekerja dengan TeamCity secara eksklusif melalui antarmuka, dan kebiasaan ini sulit untuk diberantas. Ada hack kehidupan kecil di sini: Anda bisa saja melarang perubahan apa pun dari antarmuka dan memaksa semua orang untuk mempelajari kembali. Tim kami memiliki 2.000 pengembang. Bukan cara yang baik, bukan?
Bahkan, kontra berakhir di sana. Minus yang paling penting adalah bahwa orang harus mempelajari kembali untuk sesuatu yang baru. Jadi, mereka perlu diberi dasar untuk membuat kesimpulan pribadi tentang mengapa ini perlu sama sekali. Dan perlu maka TeamCity, berkat versi, tidak memungkinkan menerapkan perubahan yang entah bagaimana merusak sistem. TeamCity sendiri kembali pada revisi stabil terbaru.
Di TeamCity, Anda dapat memulai setiap proyek untuk versi ini dan mengkonfigurasinya dengan cukup fleksibel.
Sedikit program pendidikan. Semua proyek di TeamCity diatur dalam pohon. Ada semacam akar yang sama, dan lebih jauh darinya muncul struktur yang begitu sederhana. Setiap proyek adalah bagian atas grafik ini. Ia dapat bertindak sebagai sekumpulan konfigurasi tertentu yang membangun sesuatu, dan sebagai induk untuk proyek lain.
Di Git, Anda dapat mengirim barang sekaligus, atau barang tertentu. Misalnya, jika kolega dari backend dengan frontend tidak ingin menggunakan versi, tolong, Anda tidak dapat mengandalkan mereka, dan cukup mengamankan proyek pribadi Anda.
Anda dapat mengatur sistem hierarkis yang agak rumit, yang akhirnya menjadi tujuan tim kami. Kami memiliki satu akar besar dan beberapa akar kecil. Backend, pengembangan ponsel, frontend, Yandex.Food - mereka semua hidup masing-masing dalam repositori terpisah. Pada saat yang sama, informasi tentang semua proyek ini disimpan dalam repositori bersama yang besar - di root.
Setelah Anda akhirnya menghubungkan versi ini, instal dengan semua kolega Anda, di mana siapa dan bagaimana akan hidup, siapa yang akan terlibat dalam dukungan - setelah semua ini, Anda harus membuat pilihan yang sulit.
TeamCity hanya mendukung dua format konfigurasi. Dengan XML, saya curiga tidak ada yang mau bekerja, jadi kami memilih format kedua. Ini memungkinkan Anda untuk membuat konfigurasi ini pada skrip Kotlin.
eamCity menciptakan proyek-maven, semacam proyek biasa. Anda dapat melakukan salah satu dari dua hal dengannya: mengunggah ke proyek Anda - Android, backend, itu tidak masalah - atau membiarkannya sebagai proyek mandiri. Kemudian Anda akan memiliki repositori independen dengan proyek independen.
Apa nilai tambah dari pendekatan ini? Secara pribadi, saya dan orang-orang yang berurusan dengan infrastruktur kami di backend dan frontend segera disuap oleh sesuatu. Dan bahkan mereka yang tidak terbiasa dengan Kotlin, yang mendengarnya untuk pertama kali, pergi dan mulai mengajarinya.
Dua baris ini menciptakan keseluruhan proyek. Ini adalah dialek API TeamCity. API mengubah setiap versi utama. Ada 2018-2, 2018-1, 2017, dll. Segera, semoga 2019 akan dirilis.
Baris kedua hanya menyatakan proyek.
Ini proyeknya sendiri. Ini benar-benar kode nyata. Seperti itulah repositori root kami sekarang. Tidak ada yang ekstra, tidak ada yang rumit. Satu-satunya pekerjaan manual yang diperlukan di sini adalah membuat UUID sendiri secara manual. TeamCity mengharuskan setiap objek, setiap proyek memiliki pengenal uniknya sendiri. Anda dapat menulis apa pun di sana. Saya hanya menggunakan tim uuidgen nama panggilan standar.
Di sinilah dimulai petualangan di Kotlin DSL. Saya pikir ini adalah bahasa yang tidak rumit untuk dikuasai. Dengan mengunggahnya ke IDEA, Eclipse atau IDE lain, Anda bisa mendapatkan semua dokumentasi, penyorotan, pelengkapan otomatis, kiat. Bahkan, banyak dari mereka yang hilang di antarmuka. Oleh karena itu, pengalaman pribadi saya mengatakan bahwa bekerja dengan kode jauh lebih mudah, lebih sederhana dan lebih intuitif. Kami masih pengembang.
Sesuatu seperti ini terlihat seperti konfigurasi nyata yang sekarang bekerja pada saat yang sama, mendukung konfigurasi TeamCity sendiri. Yaitu, TeamCity membangun konfigurasi sendiri di lingkungannya sendiri. Jika semuanya baik-baik saja dan semuanya salah, ia dengan tenang mengirimkannya ke memori dan mereplikasi perubahan ke PostgreSQL. Pangkalan sudah terhubung ke layanan itu sendiri. Dan di sini akan menjadi dosa untuk tidak menggunakan semua fitur Kotlin.
Dalam kasus ini, tidak seperti XML, konfigurasi ini dapat dijelaskan menggunakan polimorfisme, pewarisan - fitur apa pun dari bahasa Kotlin diizinkan. Satu-satunya poin penting adalah bahwa semua ini pada akhirnya dapat berubah menjadi kekacauan yang ada bersama kami sebelum kami memperkenalkan versi konfigurasi pada skrip Kotlin.
Tapi, anehnya, kekacauan ini menjadi jauh lebih sedikit. Karena sebelumnya tidak terlalu jelas bagaimana melakukan apa yang saya inginkan, bagaimana cara mencapai fitur ini atau itu? Dari kode, dalam praktik saya, jauh lebih mudah untuk memahami bagaimana menerapkan fitur apa pun.
Petualangan yang paling menarik dimulai di sini: bagaimana kita menerapkan beberapa hal dan bagaimana, pada prinsipnya, membuat interaksi proyek dengan TeamCity lebih mudah?
Semua orang di sini hadir dalam satu atau lain bentuk sedang mempersiapkan rilis, berpartisipasi dalam majelisnya, dalam publikasi. Kami menerbitkan rilis kami di berbagai saluran di Google Play.
Kami memiliki beta, ada eksperimen, ada yang stabil. Kami menggunakan plugin khusus dengan robot yang memposting komentar dengan laporan tentang rilis rilis di tiket rilis. Dan semua ini diatur dengan jendela yang begitu indah. Itu muncul segera setelah Anda mencoba membuat rilis. Pertanyaan-pertanyaan ini tidak bisa dihindari.
Dari antarmuka TeamCity, terlihat seperti ini. Untuk segera memahami apa, di mana, di mana dan bagaimana, Anda perlu membaca setiap parameter, Anda perlu bereksperimen. Dari dokumentasi, selain apa yang terlihat di layar, tidak ada lagi yang bisa diperoleh.
Dalam kode, tampilannya seperti ini. Setidaknya sejauh ini, selama setengah tahun, belum ada yang datang dan bertanya - bagaimana cara membuat fitur? Paling sering dari kode semuanya jelas secara intuitif.
Pada saat yang sama, beberapa hal dilakukan dengan cukup sederhana, tetapi tersembunyi di balik beberapa lapisan antarmuka. Kita harus berjalan, bolak-balik.
Berikut adalah contoh bagaimana keamanan diterapkan di TeamCity. Dalam praktik saya, bagi kebanyakan orang, TeamCity tampaknya menjadi sistem dingin yang cukup sederhana yang tidak mendukung integrasi, misalnya, dengan layanan keamanan. Karena itu, semua token, semua kunci, semua kredensial bersama kami paling sering muncul di tempat terbuka. Kenapa tidak
Faktanya, TeamCity aman. Dia tahu cara membuat file khusus sendiri di servernya, yang disebut - credential json, seperti yang ditunjukkan. Dan dia menciptakan kunci untuk setiap token, untuk setiap kredensial, yang kami hasilkan secara khusus melalui antarmuka. Anda sudah bisa memasukkannya ke dalam kode dan pastikan kredensial ini tidak akan pernah muncul di log TeamCity atau di antarmuka TeamCity. Sistem dapat memotong kunci ini secara harfiah dari mana-mana. Seluruh antarmuka, secara kasar, semacam dekorasi.
Oke, kami telah menyiapkan beberapa parameter kami, membuat penerusan parameter yang diperlukan, misalnya, untuk membuat rilis. Tetapi bagaimana jika kita ingin melangkah lebih jauh? Dan kami ingin melangkah lebih jauh. Selama perakitan, banyak langkah berbeda diluncurkan. Kami menjalankan beberapa perpustakaan bersarang yang dibangun dari repositori yang sama sekali berbeda. Dan kami hanya ingin melakukan perubahan baru. Semua itu sekarang. Jangan ganggu - misalnya, jangan kumpulkan perpustakaan bantu untuk permintaan kumpulan, jangan unggah ke repositori pakar, jangan tambahkan gerakan tambahan ke permintaan kumpulan.
Kami baru saja menyiapkan perakitan rantai. Saya akan menunjukkan sampai akhir betapa tidak jelas dan tidak nyaman untuk melakukan ini dari antarmuka, menurut pendapat pribadi saya. Dan sudah ada yang menilai sendiri.
Seperti inilah tampilan rangkaian rantai di antarmuka.
Ini terlihat seperti ini dalam kode. Kami hanya menunjukkan dengan tepat konfigurasi mana yang bergantung dan apa yang harus dilakukan jika salah satu konfigurasi tidak berfungsi atau dibatalkan oleh pengguna dari luar. Dalam hal ini, saya tidak ingin majelis memulai sama sekali. Karena apa gunanya jika kita belum mengumpulkan semua pustaka dependen?
Dengan semangat yang sama, semua hal lain sedang dilakukan. Dan seluruh proyek di TeamCity membutuhkan 500 baris kode.
Ternyata Anda dapat meneruskan beberapa parameter menarik melalui semua dependensi. Saya menunjukkan rantai karena suatu alasan. Chains memang nyaman, tetapi sulit disiapkan di antarmuka. Dan TeamCity tidak mendokumentasikan fitur penting seperti penerusan melalui parameter. Untuk apa ini? Misalkan, di build kami di Gradle atau di tempat lain, kami ingin terikat pada beberapa bidang tertentu, meneruskan alamat yang sama ke tiket rilis. Dan kami ingin melakukan ini satu kali, dan bukan untuk setiap rakitan bersarang.
TeamCity memiliki parameter yang tidak terlalu jelas dan sepenuhnya tidak terdokumentasi - reverse.dep (reverse dependency). Itu melempar semua parameter yang datang setelah tanda bintang ke semua membangun bersarang.
Pada output, kita mendapatkan struktur yang sederhana. Anda dapat memperumitnya dan membuat sarang sedalam imajinasi atau kebutuhan Anda. Dan untuk memastikan bahwa dalam semua dependensi ini, dalam semua konfigurasi ini, semua parameter kami yang kami harapkan pada setiap langkah perakitan akan diteruskan. Siap menjawab pertanyaan Anda. Terima kasih semuanya!