Ing RIT 2019, kolega Alexander Korotkov digawe babagan otomatisasi pembangunan ing CIAN: kanggo nyederhanakake urip lan karya, kita nggunakake platform Integro dhewe. Iki nglacak siklus urip tugas, nyuda pangembang saka operasi rutin lan nyuda jumlah bug ing produksi. Ing kirim iki, kita bakal nglengkapi laporan Alexander lan pitutur marang kowe carane kita pindhah saka skrip prasaja kanggo nggabungake produk open source liwat platform kita dhewe lan apa tim otomatis kita kapisah.
Tingkat nol
"Ora ana tingkat nol, aku ora ngerti babagan iki"
Master Shifu saka film "Kung Fu Panda"
Otomasi ing CIAN wiwit 14 taun sawisé perusahaan didegaké. Ing wektu iku ana 35 wong ing tim pangembangan. Hard kanggo pracaya, tengen? Mesthi wae, otomatisasi ana ing sawetara wujud, nanging arah sing kapisah kanggo integrasi terus-terusan lan pangiriman kode wiwit diwiwiti ing 2015.
Ing wektu iku, kita duwe monolit ageng Python, C # lan PHP, disebarake ing server Linux / Windows. Kanggo nyebarke monster iki, kita wis pesawat saka Tulisan sing kita mbukak kanthi manual. Ana uga perakitan monolit, sing nyebabake rasa lara lan penderitaan amarga konflik nalika nggabungake cabang, mbenerake cacat, lan mbangun maneh "kanthi macem-macem tugas ing bangunan." Proses sing disederhanakake katon kaya iki:
Kita ora seneng karo iki, lan kita pengin mbangun proses mbangun lan penyebaran sing bisa diulang, otomatis lan bisa diatur. Iki, kita needed CI / sistem CD, lan kita milih antarane free versi Teamcity lan free versi Jenkins, awit kita kerjo karo wong-wong mau lan loro cocog kita ing syarat-syarat pesawat saka fungsi. Kita milih Teamcity minangka produk sing luwih anyar. Ing wektu kasebut, kita durung nggunakake arsitektur layanan mikro lan ora ngarepake akeh tugas lan proyek.
Kita teka ing gagasan sistem kita dhewe
Implementasi Teamcity mung mbusak bagean saka karya manual: sing isih ana yaiku nggawe Panjaluk Tarik, promosi masalah miturut status ing Jira, lan pilihan masalah kanggo dibebasake. Sistem Teamcity ora bisa ngatasi iki maneh. Sampeyan kudu milih dalan otomatisasi luwih lanjut. Kita nimbang opsi kanggo nggarap skrip ing Teamcity utawa ngalih menyang sistem otomatisasi pihak katelu. Nanging ing pungkasan kita mutusake yen kita butuh keluwesan maksimal, sing mung bisa diwenehake solusi dhewe. Iki minangka versi pisanan sistem otomatisasi internal sing diarani Integro.
Teamcity ngurusi otomatisasi ing tingkat ngluncurake proses mbangun lan panyebaran, dene Integro fokus ing otomatisasi proses pangembangan tingkat paling dhuwur. Sampeyan kudu nggabungake karya karo masalah ing Jira karo ngolah kode sumber sing ana gandhengane ing Bitbucket. Ing tahap iki, Integro wiwit duwe alur kerja dhewe kanggo nggarap tugas saka macem-macem jinis.
Amarga tambah otomatisasi ing proses bisnis, jumlah proyek lan mlaku ing Teamcity saya tambah. Dadi masalah anyar teka: siji free conto Teamcity ora cukup (3 agen lan 100 proyek), kita nambah conto liyane (3 liyane agen lan 100 proyek), banjur liyane. Akibaté, kita rampung karo sistem sawetara klompok, kang angel kanggo ngatur:
Nalika ana pitakonan saka conto kaping 4, kita nyadari yen kita ora bisa terus urip kaya iki, amarga biaya total kanggo ndhukung 4 kasus ora ana watesan apa wae. Pitakonan muncul babagan tuku Teamcity sing dibayar utawa milih Jenkins gratis. Kita nggawe kalkulasi babagan kedadeyan lan rencana otomatis lan mutusake yen kita bakal manggon ing Jenkins. Sawise sawetara minggu, kita ngalih menyang Jenkins lan ngilangi sawetara lara sing ana gandhengane karo njaga sawetara instansi Teamcity. Mulane, kita bisa fokus ing ngembangaken Integro lan ngatur Jenkins kanggo awake dhewe.
Kanthi tuwuhing otomatisasi dhasar (ing wangun otomatis nggawe Panjaluk Tarik, koleksi lan publikasi jangkoan Kode lan pamriksa liyane), ana kepinginan sing kuat kanggo nglirwakake rilis manual sabisa-bisa lan menehi karya iki menyang robot. Kajaba iku, perusahaan wiwit pindhah menyang layanan mikro ing perusahaan, sing mbutuhake rilis sing kerep, lan kanthi kapisah. Iki carane kita mboko sithik teka menyang rilis otomatis microservices kita (saiki kita ngeculake monolith kanthi manual amarga kerumitan proses). Nanging, kaya biasane, kerumitan anyar muncul.
Kita ngotomatisasi tes
Amarga otomatisasi rilis, proses pangembangan saya cepet, sebagian amarga nglewati sawetara tahap tes. Lan iki nyebabake mundhut kualitas sauntara. Muni ora pati penting, nanging bebarengan karo percepatan rilis, perlu kanggo ngganti metodologi pangembangan produk. Sampeyan kudu mikir babagan otomasi tes, ngetrapake tanggung jawab pribadi (ing kene kita ngomong babagan "nampa ide ing sirah", dudu denda dhuwit) saka pangembang kanggo kode sing dirilis lan kewan omo, uga keputusan kanggo ngeculake / ora ngeculake tugas liwat penyebaran otomatis.
Ngilangi masalah kualitas, kita entuk rong keputusan penting: kita wiwit nganakake tes kenari lan ngenalake ngawasi otomatis latar mburi kesalahan kanthi respon otomatis kanggo keluwihan kasebut. Solusi pisanan bisa nemokake kesalahan sing jelas sadurunge kode kasebut dirilis ing produksi, sing kapindho nyuda wektu nanggepi masalah ing produksi. Kesalahan, mesthi, kelakon, nanging kita nglampahi paling wektu lan gaweyan ora kanggo mbenerake, nanging kanggo nyilikake.
Tim Otomasi
Saiki kita duwe staf 130 pangembang, lan kita terus . Tim kanggo integrasi terus-terusan lan pangiriman kode (sabanjuré diarani tim Deploy and Integration utawa DI) dumadi saka 7 wong lan kerja ing 2 arah: pangembangan platform otomatisasi Integro lan DevOps.
DevOps tanggung jawab kanggo lingkungan Dev / Beta situs CIAN, lingkungan Integro, mbantu pangembang ngatasi masalah lan ngembangake pendekatan anyar kanggo skala lingkungan. Arah pangembangan Integro gegayutan karo Integro dhewe lan layanan sing gegandhengan, contone, plugin kanggo Jenkins, Jira, Confluence, lan uga ngembangake utilitas lan aplikasi tambahan kanggo tim pangembangan.
Tim DI kerja bareng karo tim Platform, sing ngembangake arsitektur, perpustakaan, lan pendekatan pangembangan sacara internal. Ing wektu sing padha, pangembang ing CIAN bisa menehi kontribusi kanggo otomatisasi, contone, nggawe otomatisasi mikro sing cocog karo kabutuhan tim utawa nuduhake ide sing apik babagan cara nggawe otomatisasi luwih apik.
Layer cake of automation ing CIAN
Kabeh sistem sing melu otomatisasi bisa dipérang dadi sawetara lapisan:
- Sistem eksternal (Jira, Bitbucket, lsp). Tim pangembangan kerja bareng karo dheweke.
- Platform Integro. Paling asring, pangembang ora bisa digunakake kanthi langsung, nanging sing nggawe kabeh otomatisasi.
- Layanan pangiriman, orkestrasi lan panemuan (contone, Jeknins, Konsul, Nomad). Kanthi bantuan, kita masang kode ing server lan mesthekake yen layanan bisa bebarengan.
- Lapisan fisik (server, OS, piranti lunak sing gegandhengan). Kode kita beroperasi ing tingkat iki. Iki bisa dadi server fisik utawa virtual (LXC, KVM, Docker).
Adhedhasar konsep iki, kita mbagi area tanggung jawab ing tim DI. Rong tingkat pisanan ana ing area tanggung jawab arah pangembangan Integro, lan rong tingkat pungkasan wis ana ing area tanggung jawab DevOps. Pemisahan iki ngidini kita fokus ing tugas lan ora ngganggu interaksi, amarga kita cedhak karo saben liyane lan terus-terusan ijol-ijolan kawruh lan pengalaman.
utuh
Ayo fokus ing Integro lan miwiti tumpukan teknologi:
- CentOS 7
- Docker + Nomad + Konsul + Vault
- Jawa 11 (monolit Integro lawas bakal tetep ana ing Jawa 8)
- Spring Boot 2.X + Spring Cloud Config
- PostgreSql 11
- KelinciMQ
- Apache Ignite
- Camunda (dipasang)
- Grafana + Graphite + Prometheus + Jaeger + ELK
- UI Web: React (CSR) + MobX
- SSO: Keycloak
Kita netepi prinsip pangembangan layanan mikro, sanajan kita duwe warisan ing bentuk monolit saka versi awal Integro. Saben layanan mikro mlaku ing wadhah Docker dhewe, lan layanan kasebut saling komunikasi liwat panjaluk HTTP lan pesen RabbitMQ. Microservices golek saben liyane liwat Konsul lan nggawe panjalukan kanggo, liwat wewenang liwat SSO (Keycloak, OAuth 2 / OpenID Connect).
Minangka conto nyata, coba sesambungan karo Jenkins, sing kalebu langkah-langkah ing ngisor iki:
- Layanan mikro manajemen alur kerja (sabanjuré diarani minangka microservice Flow) pengin nglakokake mbangun ing Jenkins. Kanggo nindakake iki, dheweke nggunakake Konsul kanggo nemokake IP: PORT microservice kanggo integrasi karo Jenkins (sabanjuré diarani Jenkins microservice) lan ngirim panjalukan sing ora sinkron kanggo miwiti mbangun ing Jenkins.
- Sawise nampa panjalukan, microservice Jenkins ngasilake lan nanggapi karo ID Proyek, sing banjur bisa digunakake kanggo ngenali asil karya. Ing wektu sing padha, iku micu mbangun ing Jenkins liwat telpon REST API.
- Jenkins nindakake mbangun lan, sawise rampung, ngirim webhook karo asil eksekusi menyang microservice Jenkins.
- Layanan mikro Jenkins, sawise nampa webhook, ngasilake pesen babagan ngrampungake pangolahan panjaluk lan nempelake asil eksekusi kasebut. Pesen sing digawe dikirim menyang antrian RabbitMQ.
- Liwat RabbitMQ, pesen sing diterbitake tekan layanan mikro Flow, sing sinau babagan asil pangolahan tugas kanthi cocog karo ID Proyek saka panjalukan lan pesen sing ditampa.
Saiki kita duwe udakara 30 layanan mikro, sing bisa dipérang dadi sawetara klompok:
- Manajemen konfigurasi.
- Informasi lan interaksi karo pangguna (utusan, surat).
- Nggarap kode sumber.
- Integrasi karo alat panyebaran (jenkins, nomad, konsul, lsp).
- Ngawasi (rilis, kesalahan, lsp).
- Utilitas web (UI kanggo ngatur lingkungan tes, ngumpulake statistik, lsp).
- Integrasi karo pelacak tugas lan sistem sing padha.
- Manajemen alur kerja kanggo macem-macem tugas.
Tugas alur kerja
Integro ngotomatisasi aktivitas sing ana gandhengane karo siklus urip tugas. Ing istilah sing disederhanakake, siklus urip tugas bakal dimangerteni minangka alur kerja tugas ing Jira. Proses pangembangan kita duwe sawetara variasi alur kerja gumantung saka proyek, jinis tugas lan opsi sing dipilih ing tugas tartamtu.
Ayo goleki alur kerja sing paling kerep digunakake:
Ing diagram, gear nuduhake yen transisi diarani kanthi otomatis dening Integro, dene tokoh manungsa nuduhake yen transisi diarani kanthi manual dening wong. Ayo goleki sawetara dalan sing bisa ditindakake tugas ing alur kerja iki.
Tes manual kanthi lengkap ing DEV + BETA tanpa tes kenari (biasane kaya iki ngeculake monolit):
Bisa uga ana kombinasi transisi liyane. Kadhangkala dalan sing bakal ditindakake masalah bisa dipilih liwat pilihan ing Jira.
Gerakan tugas
Ayo goleki langkah-langkah utama sing ditindakake nalika tugas pindhah liwat alur kerja "Tes DEV + Tes Canary":
1. Pangembang utawa PM nggawe tugas.
2. Pangembang njupuk tugas kanggo bisa. Sawise rampung, pindhah menyang status IN REVIEW.
3. Jira ngirim Webhook menyang microservice Jira (tanggung jawab kanggo integrasi karo Jira).
4. Microservice Jira ngirim panjalukan menyang layanan Flow (tanggung jawab kanggo alur kerja internal sing ditindakake) kanggo miwiti alur kerja.
5. Ing layanan Flow:
- Reviewer diutus kanggo tugas (Panganggo microservice sing ngerti kabeh babagan pangguna + Jira microservice).
- Liwat microservice Source (ngerti babagan repositori lan cabang, nanging ora bisa digunakake karo kode kasebut dhewe), panelusuran digawe kanggo repositori sing ngemot cabang saka masalah kita (kanggo nyederhanakake panelusuran, jeneng cabang kasebut pas karo masalah kasebut. nomer ing Jira). Paling asring, tugas mung duwe siji cabang ing siji repositori; iki nyederhanakake manajemen antrian panyebaran lan nyuda konektivitas antarane repositori.
- Kanggo saben cabang sing ditemokake, urutan tumindak ing ngisor iki ditindakake:
i) Nganyari cabang master (Git microservice kanggo nggarap kode).
ii) Cabang diblokir saka owah-owahan dening pangembang (Bitbucket microservice).
iii) Panjaluk Tarik digawe kanggo cabang iki (layanan mikro Bitbucket).
iv) Pesen babagan Panjaluk Tarik anyar dikirim menyang obrolan pangembang (Ngabari microservice kanggo nggarap kabar).
v) Mbangun, nyoba lan nyebarake tugas diwiwiti ing DEV (Jenkins microservice kanggo nggarap Jenkins).
vi) Yen kabeh langkah sadurunge rampung kasil, banjur Integro sijine Approve ing Panjaluk Tarik (Bitbucket microservice). - Integro ngenteni Persetujuan ing Panjaluk Tarik saka reviewer sing ditunjuk.
- Sanalika kabeh persetujuan sing dibutuhake wis ditampa (kalebu tes otomatis wis lulus kanthi positif), Integro nransfer tugas kasebut menyang status Test on Dev (Jira microservice).
6. Testers nyoba tugas. Yen ora ana masalah, tugas kasebut ditransfer menyang status Siap Dibangun.
7. Integro "ndeleng" sing tugas siap kanggo release lan miwiti penyebaran ing mode kenari (Jenkins microservice). Kesiapan kanggo release ditemtokake dening sakumpulan aturan. Contone, tugas kasebut ana ing status sing dibutuhake, ora ana kunci ing tugas liyane, saiki ora ana unggahan aktif layanan mikro iki, lsp.
8. Tugas ditransfer menyang status Canary (Jira microservice).
9. Jenkins mbukak tugas penyebaran liwat Nomad ing mode kenari (biasane 1-3 kedadean) lan ngabari layanan ngawasi release (DeployWatch microservice) bab penyebaran.
10. Layanan mikro DeployWatch nglumpukake latar mburi kesalahan lan nanggepi, yen perlu. Yen latar mburi kesalahan ngluwihi (norma latar mburi diwilang kanthi otomatis), pangembang diwenehi kabar liwat Notify microservice. Yen sawise 5 menit pangembang durung nanggapi (diklik Revert utawa Tetep), banjur rollback otomatis saka kedadean kenari diluncurake. Yen latar mburi ora ngluwihi, mula pangembang kudu mbukak penyebaran tugas kanthi manual menyang Produksi (kanthi ngeklik tombol ing UI). Yen ing 60 menit pangembang durung ngluncurake penyebaran menyang Produksi, mula kenari uga bakal digulung maneh amarga alasan keamanan.
11. Sawise ngluncurake penyebaran menyang Produksi:
- Tugas kasebut ditransfer menyang status Produksi (Jira microservice).
- Layanan mikro Jenkins miwiti proses panyebaran lan menehi kabar marang layanan mikro DeployWatch babagan penyebaran kasebut.
- Layanan mikro DeployWatch mriksa manawa kabeh kontaner ing Produksi wis dianyari (ana kasus nalika ora kabeh dianyari).
- Liwat layanan mikro Notify, kabar babagan asil penyebaran dikirim menyang Produksi.
12. Pangembang bakal duwe 30 menit kanggo miwiti muter maneh tugas saka Produksi yen prilaku microservice salah dideteksi. Sawise wektu kasebut, tugas kasebut bakal digabung kanthi otomatis dadi master (Git microservice).
13. Sawise gabung sukses dadi master, status tugas bakal diganti Closed (Jira microservice).
Diagram kasebut ora ndalang kanthi rinci (ing kasunyatan, ana langkah liyane), nanging ngidini sampeyan nemtokake tingkat integrasi menyang proses. Kita ora nganggep skema iki becik lan nambah proses rilis otomatis lan dhukungan penyebaran.
Apa mbesuk
Kita duwe rencana gedhe kanggo pangembangan otomatisasi, contone, ngilangi operasi manual sajrone rilis monolit, nambah pemantauan sajrone penyebaran otomatis, lan nambah interaksi karo pangembang.
Nanging ayo mandheg ing kene. Kita nutupi akeh topik ing review otomatisasi kanthi entheng, sawetara ora disentuh, mula kita bakal seneng mangsuli pitakon. Kita ngenteni saran babagan apa sing bakal dibahas kanthi rinci, tulis ing komentar.
Source: www.habr.com