Tina skrip ka platform urang sorangan: kumaha urang ngajadikeun otomatis pangwangunan di CIAN

Di RIT 2019, kolega urang Alexander Korotkov damel laporan ngeunaan automation pangwangunan di CIAN: pikeun nyederhanakeun kahirupan sareng padamelan, kami nganggo platform Integro sorangan. Éta ngalacak siklus kahirupan tugas, ngaleungitkeun pamekar operasi rutin sareng sacara signifikan ngirangan jumlah bug dina produksi. Dina postingan ieu, kami bakal ngalengkepan laporan Alexander sareng nyarioskeun ka anjeun kumaha urang angkat tina skrip saderhana pikeun ngahijikeun produk open source ngaliwatan platform urang sorangan sareng naon anu dilakukeun ku tim otomatis kami anu misah.
 

Tingkat nol

"Teu aya anu sapertos tingkat nol, kuring henteu terang hal sapertos kitu"
Master Shifu tina pilem "Kung Fu Panda"

Automation di CIAN dimimitian 14 taun sanggeus pausahaan diadegkeun. Dina waktos éta aya 35 urang dina tim pengembangan. Hésé dipercaya, henteu? Tangtosna, otomatisasi aya dina sababaraha bentuk, tapi arah anu misah pikeun integrasi kontinyu sareng pangiriman kode mimiti dibentuk dina 2015. 

Dina waktos éta, urang gaduh monolith ageung Python, C # sareng PHP, disebarkeun dina server Linux / Windows. Pikeun nyebarkeun monster ieu, urang ngagaduhan sakumpulan naskah anu urang jalankeun sacara manual. Aya ogé rakitan monolith, anu nyababkeun nyeri sareng sangsara kusabab konflik nalika ngahijikeun cabang, koréksi cacad, sareng ngawangun deui "kalayan sakumpulan tugas anu béda dina ngawangun." Prosés saderhana katingali sapertos kieu:

Kami henteu senang sareng ieu, sareng kami hoyong ngawangun prosés ngawangun sareng panyebaran anu tiasa diulang, otomatis sareng tiasa diurus. Keur kitu, urang diperlukeun CI / Sistim CD, sarta kami milih antara versi bébas tina Teamcity jeung bebas Vérsi Jenkins, saprak urang digawé kalayan aranjeunna sarta duanana cocog kami dina watesan susunan fungsi. Kami milih Teamcity salaku produk anu langkung énggal. Dina waktos éta, urang henteu acan nganggo arsitéktur microservice sareng henteu ngarepkeun sajumlah ageung tugas sareng proyék.

Urang datang ka pamanggih sistem urang sorangan

Palaksanaan Teamcity dihapus ukur bagian tina karya manual: naon tetep nyaéta kreasi Tarik Requests, promosi masalah ku status di Jira, sarta Pilihan isu pikeun release. Sistem Teamcity henteu tiasa deui ngatasi ieu. Ieu diperlukeun pikeun milih jalur automation salajengna. Kami mertimbangkeun pilihan pikeun damel sareng skrip di Teamcity atanapi ngalih ka sistem otomatisasi pihak katilu. Tapi tungtungna urang mutuskeun yén urang diperlukeun kalenturan maksimum, nu ngan solusi urang sorangan bisa nyadiakeun. Ieu kumaha versi mimiti sistem automation internal disebut Integro mucunghul.

Teamcity nguruskeun otomatisasi dina tingkat ngaluncurkeun prosés ngawangun sareng panyebaran, sedengkeun Integro fokus kana otomatisasi prosés pangwangunan tingkat luhur. Ieu diperlukeun pikeun ngagabungkeun gawé kalawan masalah di Jira jeung ngolah kode sumber pakait dina Bitbucket. Dina tahap ieu, Integro mimiti gaduh workflows sorangan pikeun gawé bareng tugas tina tipena béda. 

Kusabab kanaékan otomatisasi dina prosés bisnis, jumlah proyék sareng jalan di Teamcity parantos ningkat. Janten masalah énggal sumping: hiji conto Teamcity gratis henteu cekap (3 agén sareng 100 proyék), kami nambihan conto sanés (3 langkung agén sareng 100 proyék), teras anu sanés. Hasilna, kami ngagaduhan sistem sababaraha klaster, anu sesah diurus:

Nalika patarosan ngeunaan conto ka-4 timbul, urang sadar yén urang henteu tiasa teras-terasan hirup sapertos kieu, sabab total biaya pikeun ngadukung 4 instansi henteu aya dina wates naon waé. Patarosan timbul ngeunaan mésér Teamcity anu mayar atanapi milih Jenkins gratis. Urang nyieun itungan on instansi jeung rencana automation sarta mutuskeun yén urang bakal hirup di Jenkins. Saatos sababaraha minggu, urang ngalih ka Jenkins sareng ngaleungitkeun sababaraha nyeri sirah anu aya hubunganana sareng ngajaga sababaraha instansi Teamcity. Ku alatan éta, kami bisa difokuskeun ngembangkeun Integro tur ngaropéa Jenkins keur diri urang sorangan.

Kalayan tumuwuhna automation dasar (dina bentuk kreasi otomatis tina Requests Tarik, kempelan jeung publikasi sinyalna Code na cék séjén), aya kahayang kuat a abandon Kaluaran manual saloba mungkin tur masihan karya ieu robot. Salaku tambahan, perusahaan mimiti ngalih ka microservices dina perusahaan, anu peryogi sékrési sering, sareng misah ti anu sanés. Ieu kumaha urang laun-laun sumping ka sékrési otomatis microservices kami (kami ayeuna ngaleupaskeun monolith sacara manual kusabab pajeulitna prosésna). Tapi, sakumaha biasana kajadian, pajeulitna anyar timbul. 

Urang ngajadikeun otomatis nguji

Alatan otomatisasi sékrési, prosés pamekaran parantos gancangan, sawaréh kusabab ngalangkungan sababaraha tahap tés. Sareng ieu nyababkeun leungitna kualitas samentawis. Ieu disada trivial, tapi babarengan jeung akselerasi release, éta diperlukeun pikeun ngarobah metodologi ngembangkeun produk. Ieu diperlukeun pikeun mikir ngeunaan automation tina nguji, instilling tanggung jawab pribadi (di dieu urang ngobrol ngeunaan "nampa gagasan dina sirah", teu denda moneter) pamekar pikeun kode dileupaskeun sarta bug di dinya, kitu ogé kaputusan pikeun ngabebaskeun / teu ngaleupaskeun tugas ngaliwatan deployment otomatis. 

Ngaleungitkeun masalah kualitas, kami sumping ka dua kaputusan penting: urang mimiti ngalaksanakeun uji kanaria sareng ngenalkeun ngawaskeun otomatis tina latar tukang kasalahan kalayan réspon otomatis kana kaleuwihanana. Solusi kahiji ngamungkinkeun pikeun manggihan kasalahan atra saméméh kode ieu dileupaskeun pinuh kana produksi, kadua ngurangan waktu respon kana masalah dina produksi. Kasalahan, tangtosna, kajantenan, tapi urang nyéépkeun waktos sareng usaha sanés pikeun ngabenerkeunana, tapi pikeun ngaminimalkeunana. 

Tim Automation

Urang ayeuna boga staf 130 pamekar, sarta kami nuluykeun pikeun tumuwuh. Tim pikeun integrasi kontinyu sarta pangiriman kode (saterusna disebut salaku Nyebarkeun sarta Integrasi atawa tim DI) diwangun ku 7 urang jeung jalan di 2 arah: ngembangkeun platform automation Integro jeung DevOps. 

DevOps tanggung jawab kana lingkungan Dev/Beta situs CIAN, lingkungan Integro, ngabantosan pamekar ngarengsekeun masalah sareng ngembangkeun pendekatan anyar pikeun skala lingkungan. Arah pamekaran Integro nguruskeun Integro sorangan sareng jasa anu aya hubunganana, contona, plugins pikeun Jenkins, Jira, Confluence, sareng ogé ngembangkeun utilitas bantu sareng aplikasi pikeun tim pangembangan. 

Tim DI damel babarengan sareng tim Platform, anu ngembangkeun arsitéktur, perpustakaan, sareng pendekatan pamekaran sacara internal. Dina waktos anu sami, pamekar naon waé dina CIAN tiasa nyumbang kana otomatisasi, contona, ngadamel otomatis-mikro pikeun nyocogkeun ka kabutuhan tim atanapi ngabagi ide anu saé ngeunaan kumaha carana ngadamel otomatisasi langkung saé.

Lapisan jajan of automation di CIAN

Sadaya sistem aub dina automation bisa dibagi kana sababaraha lapisan:

1. Sistem éksternal (Jira, Bitbucket, jsb.). Tim pamekaran damel sareng aranjeunna.
2. platform Integro. Seringna, pamekar henteu langsung damel sareng éta, tapi éta anu ngajaga sadaya otomatisasi jalan.
3. Pangiriman, orkestrasi sareng jasa penemuan (contona, Jeknins, Konsul, Nomad). Kalayan bantosanana, kami nyebarkeun kode dina server sareng mastikeun yén jasa tiasa dianggo saling.
4. Lapisan fisik (server, OS, software patali). Kode kami beroperasi dina tingkat ieu. Ieu tiasa janten server fisik atanapi virtual (LXC, KVM, Docker).

Dumasar kana konsép ieu, urang ngabagi daérah tanggung jawab dina tim DI. Dua tingkat anu munggaran aya di daérah tanggung jawab arah pangembangan Integro, sareng dua tingkat terakhir parantos aya dina daérah tanggung jawab DevOps. Pemisahan ieu ngamungkinkeun urang pikeun difokuskeun tugas sareng henteu ngaganggu interaksi, sabab urang caket sareng silih sareng silih tukeur pangaweruh sareng pangalaman.

gembleng

Hayu urang difokuskeun Integro sareng mimitian ku tumpukan téknologi:

• CentOS 7
• Docker + Nomad + Konsul + Kolong
• Java 11 (monolit Integro heubeul bakal tetep dina Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• Kelenci MQ 
• Apache Ignite
• Camunda (dipasang)
• Grafana + Grafit + Prometheus + Jaeger + ELK
• UI Wéb: Réaksi (CSR) + MobX
• SSO: Keycloak

Urang taat kana prinsip ngembangkeun microservice, sanajan urang boga warisan dina bentuk monolith tina versi awal Integro. Unggal microservice dijalankeun dina wadahna Docker sorangan, sareng jasa saling komunikasi liwat pamundut HTTP sareng pesen RabbitMQ. Microservices manggihan silih ngaliwatan Konsul jeung nyieun pamundut ka dinya, ngaliwatan otorisasina ngaliwatan SSO (Keycloak, OAuth 2 / OpenID Connect).

Salaku conto kahirupan nyata, mertimbangkeun berinteraksi sareng Jenkins, anu diwangun ku léngkah-léngkah ieu:

1. The microservice manajemén workflow (satuluyna disebut salaku microservice Aliran) hayang ngajalankeun hiji ngawangun di Jenkins. Jang ngalampahkeun ieu, manéhna ngagunakeun Konsul pikeun manggihan IP: PORT sahiji microservice pikeun integrasi jeung Jenkins (hereinafter disebut Jenkins microservice) sarta ngirimkeun hiji pamundut Asynchronous pikeun ngamimitian ngawangun di Jenkins.
2. Saatos nampi pamundut a, Jenkins microservice ngahasilkeun sarta ngabales ku ID Proyék, nu lajeng bisa dipaké pikeun ngaidentipikasi hasil karya. Dina waktos anu sami, éta micu ngawangun di Jenkins via panggero REST API.
3. Jenkins ngalaksanakeun pangwangunan sareng, saatos réngsé, ngirimkeun webhook kalayan hasil palaksanaan ka microservice Jenkins.
4. The Jenkins microservice, sanggeus narima webhook nu, dibangkitkeun pesen ngeunaan parantosan pamrosésan pamundut na nempelkeun hasil palaksanaan eta. Pesen anu dihasilkeun dikirim ka antrian RabbitMQ.
5. Ngaliwatan RabbitMQ, pesen anu diterbitkeun dugi ka Flow microservice, anu diajar ngeunaan hasil ngolah tugasna ku cocog sareng ID Proyék tina pamundut sareng pesen anu ditampi.

Ayeuna urang gaduh ngeunaan 30 microservices, nu bisa dibagi kana sababaraha grup:

1. Manajemén konfigurasi.
2. Inpormasi sareng interaksi sareng pangguna (utusan, surat).
3. Gawe sareng kode sumber.
4. Integrasi sareng alat panyebaran (jenkins, nomad, konsul, jsb).
5. Ngawaskeun (kaluaran, kasalahan, jsb).
6. Utiliti wéb (UI pikeun ngatur lingkungan tés, ngumpulkeun statistik, jsb.).
7. Integrasi sareng trackers tugas sareng sistem anu sami.
8. Manajemén alur kerja pikeun tugas anu béda.

Tugas alur kerja

Integro ngajadikeun otomatis kagiatan anu aya hubunganana sareng siklus kahirupan tugas. Dina istilah saderhana, daur hirup hiji tugas bakal dipikaharti salaku alur gawé tugas di Jira. Prosés pamekaran urang gaduh sababaraha variasi alur kerja gumantung kana proyék, jinis tugas sareng pilihan anu dipilih dina tugas khusus. 

Hayu urang tingali alur kerja anu sering dianggo:

Dina diagram, gear nunjukkeun yén transisi disebut sacara otomatis ku Integro, sedengkeun sosok manusa nunjukkeun yén transisi disebut sacara manual ku hiji jalma. Hayu urang tingali sababaraha jalur anu tiasa dilakukeun ku tugas dina alur kerja ieu.

Tés manual lengkep dina DEV + BETA tanpa tés kanaria (biasana ieu kumaha urang ngaleupaskeun monolit):

Meureun aya kombinasi transisi séjén. Kadang-kadang jalur anu bakal dilakukeun ku masalah tiasa dipilih ngalangkungan pilihan dina Jira.

Gerakan tugas

Hayu urang tingali léngkah-léngkah utama anu dilakukeun nalika tugas ngalangkungan alur kerja "Tes DEV + Tes Canary":

1. Pamekar atanapi PM nyiptakeun tugas.

2. pamekar nyokot tugas pikeun digawé. Saatos réngsé, éta ngalih ka status IN REVIEW.

3. Jira ngirimkeun Webhook ka microservice Jira (tanggung jawab integrasi jeung Jira).

4. The Jira microservice ngirimkeun pamundut ka layanan Aliran (tanggung jawab workflows internal nu gawéna dipigawé) pikeun ngamimitian workflow nu.

5. Di jero jasa Aliran:

• Reviewers ditugaskeun ka tugas (Pamaké microservice nu weruh sagalana ngeunaan pamaké + Jira microservice).
• Ngaliwatan microservice Sumber (eta terang ngeunaan repositories jeung cabang, tapi teu dianggo kalayan kode sorangan), hiji pilarian dijieun pikeun repositories nu ngandung cabang tina masalah urang (pikeun simplify pilarian, nami cabang coincides jeung masalah. nomer dina Jira). Paling sering, tugas ngan boga hiji cabang dina hiji gudang; ieu simplifies manajemén antrian deployment sarta ngurangan konektipitas antara repositories.
• Pikeun unggal cabang anu kapanggih, runtuyan tindakan di handap ieu dilaksanakeun:

  i) Ngamutahirkeun cabang master (Git microservice pikeun gawé bareng kode).
  ii) Cabang diblokir tina parobahan ku pamekar (Bitbucket microservice).
  iii) A Request Tarik dijieun pikeun cabang ieu (Bitbucket microservice).
  iv) Pesen ngeunaan Permintaan Tarik anyar dikirim ka obrolan pamekar (Bewara microservice pikeun gawé bareng béwara).
  v) Ngawangun, nguji sareng nyebarkeun tugas dimimitian dina DEV (Jenkins microservice pikeun gawé bareng Jenkins).
  vi) Upami sadaya léngkah saacanna parantos suksés, maka Integro nempatkeun Approve na dina Tarik Request (Bitbucket microservice).

• Integro ngantosan Approve di Tarik Request ti reviewers ditunjuk.
• Pas sagala persetujuan diperlukeun geus narima (kaasup tés otomatis geus lulus positif), Integro mindahkeun tugas ka Test on Dev (Jira microservice) status.

6. Testers nguji tugas. Upami teu aya masalah, maka tugasna ditransfer ka status Siap Pikeun Ngawangun.

7. Integro "ningali" yen tugas geus siap pikeun release tur mimitian deployment na dina modeu kanaria (Jenkins microservice). Kesiapan pikeun ngaleupaskeun ditangtukeun ku sakumpulan aturan. Salaku conto, tugasna aya dina status anu diperyogikeun, teu aya konci dina tugas-tugas sanés, ayeuna teu aya unggahan aktif tina microservice ieu, jsb.

8. Tugas ditransfer ka status Kanaria (Jira microservice).

9. Jenkins ngajalankeun tugas deployment ngaliwatan Nomad dina modeu kanaria (biasana 1-3 instansi) jeung ngabéjaan jasa ngawaskeun release (DeployWatch microservice) ngeunaan deployment.

10. The DeployWatch microservice ngumpulkeun tukang kasalahan sarta meta pikeun eta, lamun perlu. Upami latar tukang kasalahan ngaleuwihan (norma tukang diitung sacara otomatis), pamekar bakal dibéjaan via jasa mikro Bewara. Upami saatos 5 menit pamekar henteu ngaréspon (diklik Balikkeun atanapi Tetep), teras balikan otomatis tina instansi kenari diluncurkeun. Upami latar tukang henteu ngaleuwihan, pamekar kedah sacara manual ngaluncurkeun panyebaran tugas ka Produksi (ku ngaklik tombol dina UI). Upami dina 60 menit pamekar henteu ngaluncurkeun panyebaran ka Produksi, maka instansi kenari ogé bakal digulung deui kusabab alesan kaamanan.

11. Saatos launching deployment ka Produksi:

• Tugas ditransferkeun ka status Produksi (Jira microservice).
• Microservice Jenkins ngamimitian prosés panyebaran sareng ngabéjaan microservice DeployWatch ngeunaan panyebaran éta.
• Microservice DeployWatch pariksa yén sadaya wadah dina Produksi parantos diropéa (aya kasus nalika henteu sadayana diropéa).
• Ngaliwatan Notify microservice, béwara ngeunaan hasil panyebaran dikirim ka Produksi.

12. Pamekar bakal boga 30 menit pikeun ngamimitian rolling deui tugas ti Produksi lamun kabiasaan microservice lepat dideteksi. Saatos waktos ieu, tugas bakal otomatis dihijikeun kana master (Git microservice).

13. Saatos suksés ngagabung kana master, status tugas bakal dirobah jadi Closed (Jira microservice).

Diagram henteu pura-pura lengkep lengkep (dina kanyataanana aya léngkah-léngkah anu langkung seueur), tapi ngamungkinkeun anjeun pikeun meunteun tingkat integrasi kana prosés. Kami henteu nganggap skéma ieu idéal sareng ningkatkeun prosés pelepasan otomatis sareng dukungan panyebaran.

Naon salajengna

Urang boga rencana badag pikeun ngembangkeun automation, contona, ngaleungitkeun operasi manual salila release monolith, ngaronjatkeun monitoring salila deployment otomatis, sarta ngaronjatkeun interaksi jeung pamekar.

Tapi hayu urang eureun di dieu pikeun ayeuna. Kami nutupan seueur topik dina ulasan automasi sacara deet, sababaraha henteu keuna pisan, ku kituna kami bakal resep ngajawab patarosan. Kami ngantosan bongbolongan ngeunaan naon anu kedah ditutupan sacara rinci, tulis dina koméntar.

sumber: www.habr.com