{"id":55870,"date":"2020-01-30T00:00:00","date_gmt":"2020-01-29T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian"},"modified":"2020-02-18T14:04:02","modified_gmt":"2020-02-18T11:04:02","slug":"ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Od skrypt\u00f3w do w\u0142asnej platformy: jak zautomatyzowali\u015bmy rozw\u00f3j w CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Od
\n
\nNa RIT 2019 nasz kolega Aleksandr Korotkow wyg\u0142osi\u0142 referat<\/a><\/noindex> wyst\u0105pienie na temat automatyzacji rozwoju w CIAN: aby upro\u015bci\u0107 \u017cycie i prac\u0119, u\u017cywamy naszej w\u0142asnej platformy Integro. \u015aledzi ona cykl \u017cycia zada\u0144, odci\u0105\u017ca programist\u00f3w od rutynowych operacji i znacznie redukuje liczb\u0119 b\u0142\u0119d\u00f3w w produkcji. W tym wpisie uzupe\u0142nimy wyst\u0105pienie Aleksandra i opowiemy, jak przeszli\u015bmy od prostych skrypt\u00f3w do integracji produkt\u00f3w open source przez nasz\u0105 w\u0142asn\u0105 platform\u0119 oraz czym zajmuje si\u0119 nasz zesp\u00f3\u0142 ds. automatyzacji.
\n\u00a0<\/a><\/noindex><\/p>\n

Poziom zerowy<\/h2>\n

\n\u201ePoziomu zerowego nie ma, nie znam czego\u015b takiego\u201d<\/b>
\nMistrz Shifu z filmu \u201eKung Fu Panda\u201d<\/i><\/p>\n

Automatyzacja w CIAN zacz\u0119\u0142a si\u0119 14 lat po za\u0142o\u017ceniu firmy. Wtedy w zespole programistycznym by\u0142o 35 os\u00f3b. Trudno w to uwierzy\u0107, prawda? Oczywi\u015bcie, w jakiej\u015b formie automatyzacja faktycznie istnia\u0142a, ale osobny kierunek dotycz\u0105cy ci\u0105g\u0142ej integracji i dostarczania kodu zacz\u0105\u0142 si\u0119 kszta\u0142towa\u0107 dopiero w 2015 roku.\u00a0<\/p>\n

W tamtym czasie mieli\u015bmy ogromny monolit z Pythonem, C# i PHP, uruchomiony na serwerach Linux\/Windows. Do wdro\u017cenia tego potwora mieli\u015bmy zestaw skrypt\u00f3w, kt\u00f3re uruchamiali\u015bmy r\u0119cznie. By\u0142o te\u017c budowanie monolitu, kt\u00f3re przynosi\u0142o b\u00f3l i cierpienie z powodu konflikt\u00f3w przy \u0142\u0105czeniu ga\u0142\u0119zi, poprawkach b\u0142\u0119d\u00f3w i ponownym budowaniu \u201ez innym zestawem zada\u0144 w budowaniu\u201d. Uproszczony proces wygl\u0105da\u0142 tak:<\/p>\n

\"Od
\n
\nNie satysfakcjonowa\u0142o nas to, chcieli\u015bmy zbudowa\u0107 powtarzalny, zautomatyzowany i zarz\u0105dzany proces budowy i wdro\u017cenia. Do tego potrzebny by\u0142 nam system CI\/CD, a my wybierali\u015bmy mi\u0119dzy bezp\u0142atn\u0105 wersj\u0105 Teamcity a bezp\u0142atnym Jenkins, poniewa\u017c pracowali\u015bmy z nimi i obie odpowiada\u0142y nam funkcjonalno\u015bciami. Wyb\u00f3r pad\u0142 na Teamcity jako na nowszy produkt. Wtedy jeszcze nie u\u017cywali\u015bmy architektury mikroserwis\u00f3w i nie przewidywali\u015bmy du\u017cej liczby zada\u0144 i projekt\u00f3w.<\/p>\n

Przechodzimy do pomys\u0142u stworzenia w\u0142asnego systemu<\/h2>\n

\nWdro\u017cenie Teamcity zredukowa\u0142o tylko cz\u0119\u015b\u0107 pracy r\u0119cznej: pozosta\u0142o jeszcze tworzenie Pull Request\u00f3w, przesuwanie zada\u0144 wed\u0142ug status\u00f3w w Jira i wyb\u00f3r zada\u0144 do wydania. Z tym system Teamcity ju\u017c sobie nie radzi\u0142. Nale\u017ca\u0142o wybra\u0107 kierunek dalszej automatyzacji. Rozwa\u017cali\u015bmy opcje pracy ze skryptami w Teamcity lub przej\u015bcie na zewn\u0119trzne systemy automatyzacji. Ostatecznie zdecydowali\u015bmy, \u017ce potrzebna jest maksymalna elastyczno\u015b\u0107, kt\u00f3r\u0105 daje tylko w\u0142asne rozwi\u0105zanie. Tak powsta\u0142a pierwsza wersja wewn\u0119trznego systemu automatyzacji o nazwie Integro.<\/p>\n

Teamcity zajmuje si\u0119 automatyzacj\u0105 na poziomie uruchamiania proces\u00f3w budowy i wdro\u017cenia, podczas gdy Integro skupi\u0142o si\u0119 na wy\u017cszej automatyzacji proces\u00f3w rozwoju. Nale\u017ca\u0142o po\u0142\u0105czy\u0107 prac\u0119 z zadaniami w Jira z przetwarzaniem powi\u0105zanego kodu \u017ar\u00f3d\u0142owego w Bitbucket. Na tym etapie w Integro zacz\u0119\u0142y pojawia\u0107 si\u0119 w\u0142asne workflow do pracy z r\u00f3\u017cnymi typami zada\u0144.\u00a0<\/p>\n

W wyniku zwi\u0119kszonej automatyzacji w procesach biznesowych wzros\u0142a liczba projekt\u00f3w i run\u00f3w w Teamcity. Tak pojawi\u0142 si\u0119 nowy problem: jeden darmowy instans Teamcity przesta\u0142 wystarcza\u0107 (3 agenty i 100 projekt\u00f3w), dodali\u015bmy kolejny instans (kolejne 3 agenty i 100 projekt\u00f3w), potem jeszcze jeden. W rezultacie otrzymali\u015bmy system sk\u0142adaj\u0105cy si\u0119 z kilku klastr\u00f3w, kt\u00f3ry by\u0142 trudny w zarz\u0105dzaniu:<\/p>\n

\"Od
\n
\nKiedy stan\u0105\u0142 przed nami problem czwartego instansu, zrozumieli\u015bmy, \u017ce nie mo\u017cemy dalej tak funkcjonowa\u0107, poniewa\u017c skumulowane koszty wsparcia czterech instans\u00f3w wymkn\u0119\u0142y si\u0119 spod kontroli. Pojawi\u0142a si\u0119 kwestia zakupu p\u0142atnej wersji Teamcity lub wyboru darmowego Jenkins. Przeprowadzili\u015bmy obliczenia dotycz\u0105ce instans\u00f3w i plan\u00f3w automatyzacji oraz zdecydowali\u015bmy, \u017ce b\u0119dziemy korzysta\u0107 z Jenkins. Po kilku tygodniach przeszli\u015bmy na Jenkins i pozbyli\u015bmy si\u0119 cz\u0119\u015bci b\u00f3lu g\u0142owy zwi\u0105zanego z utrzymywaniem kilku instans\u00f3w Teamcity. Dzi\u0119ki temu mogli\u015bmy skupi\u0107 si\u0119 na rozwijaniu Integro i dostosowywaniu Jenkins do w\u0142asnych potrzeb.<\/p>\n

Wraz z rozwojem podstawowej automatyzacji (w postaci automatycznego tworzenia Pull Request\u00f3w, zbierania i publikowania pokrycia kodu oraz innych kontrol) pojawi\u0142a si\u0119 silna ch\u0119\u0107 maksymalnego ograniczenia r\u0119cznych wyda\u0144 i oddania tej pracy robotom. Ponadto w firmie rozpocz\u0119\u0142a si\u0119 migracja na mikroserwisy, kt\u00f3re wymaga\u0142y cz\u0119stych wyda\u0144, przy czym ka\u017cde z nich oddzielnie. Stopniowo przeszli\u015bmy do automatycznych wyda\u0144 naszych mikroserwis\u00f3w (monolit na razie wydajemy r\u0119cznie z powodu z\u0142o\u017cono\u015bci procesu). Ale, jak to zwykle bywa, pojawi\u0142 si\u0119 nowy problem.\u00a0<\/p>\n

Automatyzujemy testowanie<\/h2>\n

\n\"Od
\n
\nDzi\u0119ki automatyzacji wyda\u0144 procesy programowania przyspieszy\u0142y, cz\u0119\u015bciowo kosztem pomijania niekt\u00f3rych etap\u00f3w testowania. To z kolei doprowadzi\u0142o do czasowej utraty jako\u015bci. Brzmi banalnie, ale wraz z przyspieszeniem wydania nale\u017ca\u0142o zmieni\u0107 tak\u017ce metodologi\u0119 rozwoju produktu. Trzeba by\u0142o pomy\u015ble\u0107 o automatyzacji testowania, wdro\u017ceniu osobistej odpowiedzialno\u015bci (tu m\u00f3wimy o \u201eprzyj\u0119ciu idei w g\u0142owie\u201d, a nie o karach finansowych) programisty za wydany kod i b\u0142\u0119dy w nim, a tak\u017ce o decyzji dotycz\u0105cej wydania \/ niewydania zadania poprzez automatyczny deployment.\u00a0<\/p>\n

Eliminuj\u0105c problemy z jako\u015bci\u0105, doszli\u015bmy do dw\u00f3ch wa\u017cnych rozwi\u0105za\u0144: zacz\u0119li\u015bmy przeprowadza\u0107 testy kaskadowe i wdro\u017cyli\u015bmy automatyczne monitorowanie b\u0142\u0119d\u00f3w w tle z automatyczn\u0105 reakcj\u0105 na jego przekroczenie. Pierwsze rozwi\u0105zanie pozwoli\u0142o znale\u017a\u0107 oczywiste b\u0142\u0119dy zanim kod trafi\u0142 do produkcji, drugie zmniejszy\u0142o czas reakcji na problemy w produkcji. B\u0142\u0119dy si\u0119 zdarzaj\u0105, ale wi\u0119ksz\u0105 cz\u0119\u015b\u0107 czasu i wysi\u0142k\u00f3w sp\u0119dzamy nie na ich naprawie, ale na minimalizacji.\u00a0<\/p>\n

Zesp\u00f3\u0142 automatyzacji<\/h2>\n

\nAktualnie mamy zesp\u00f3\u0142 sk\u0142adaj\u0105cy si\u0119 z 130 programist\u00f3w, i wci\u0105\u017c ro\u015bniemy<\/a><\/noindex>. Zesp\u00f3\u0142 zajmuj\u0105cy si\u0119 ci\u0105g\u0142\u0105 integracj\u0105 i dostarczaniem kodu (dalej \u2014 zesp\u00f3\u0142 Deploy and Integration lub DI) sk\u0142ada si\u0119 z 7 os\u00f3b i pracuje w 2 obszarach: rozw\u00f3j platformy automatyzacji Integro oraz DevOps.\u00a0<\/p>\n

Zesp\u00f3\u0142 DevOps odpowiada za \u015brodowiska Dev\/Beta strony CIAN, \u015brodowiska Integro, wspiera programist\u00f3w w rozwi\u0105zywaniu problem\u00f3w oraz opracowuje nowe podej\u015bcia do skalowania \u015brodowisk. Kierunek rozwoju Integro zajmuje si\u0119 zar\u00f3wno sam\u0105 Integro, jak i us\u0142ugami pokrewnymi, na przyk\u0142ad wtyczkami do Jenkins, Jira, Confluence, a tak\u017ce opracowuje pomocnicze narz\u0119dzia i aplikacje dla zespo\u0142\u00f3w deweloperskich.\u00a0<\/p>\n

Zesp\u00f3\u0142 DI wsp\u00f3\u0142pracuje z zespo\u0142em Platformy, kt\u00f3ry zajmuje si\u0119 projektowaniem architektury, bibliotek oraz podej\u015bciem do rozwoju wewn\u0105trz firmy. Dodatkowo ka\u017cdy programista w CIAN mo\u017ce przyczyni\u0107 si\u0119 do automatyzacji, na przyk\u0142ad wprowadzi\u0107 mikroautomatyzacj\u0119 pod potrzeby zespo\u0142u lub podzieli\u0107 si\u0119 \u015bwietnym pomys\u0142em, jak jeszcze poprawi\u0107 automatyzacj\u0119.<\/p>\n

Warstwowe podej\u015bcie do automatyzacji w CIAN<\/h2>\n

\n\"Od
\n
\nWszystkie systemy zaanga\u017cowane w automatyzacj\u0119 mo\u017cna podzieli\u0107 na kilka warstw:<\/p>\n

    \n
  1. Systemy zewn\u0119trzne (Jira, Bitbucket itp.). Z nimi pracuj\u0105 zespo\u0142y deweloperskie.\n<\/li>\n
  2. Platforma Integro. Najcz\u0119\u015bciej programi\u015bci nie pracuj\u0105 z ni\u0105 bezpo\u015brednio, ale to ona wspiera dzia\u0142anie ca\u0142ej automatyzacji.\n<\/li>\n
  3. Us\u0142ugi dostarczania, orkiestracji i odkrywania (na przyk\u0142ad Jenkins, Consul, Nomad). Dzi\u0119ki nim wdra\u017camy kod na serwerach i zapewniamy wsp\u00f3\u0142prac\u0119 us\u0142ug.\n<\/li>\n
  4. Poziom fizyczny (serwery, systemy operacyjne, oprogramowanie pokrewne). Na tym poziomie dzia\u0142a nasz kod. Mo\u017ce to by\u0107 zar\u00f3wno serwer fizyczny, jak i wirtualny (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nNa podstawie tej koncepcji dzielimy obszary odpowiedzialno\u015bci wewn\u0105trz zespo\u0142u DI. Dwa pierwsze poziomy le\u017c\u0105 w zakresie odpowiedzialno\u015bci kierunku rozwoju Integro, a dwa ostatnie poziomy ju\u017c w zakresie odpowiedzialno\u015bci DevOps. Takie podzia\u0142 pozwala skupi\u0107 si\u0119 na zadaniach i nie przeszkadza w interakcji, poniewa\u017c znajdujemy si\u0119 blisko siebie i nieustannie wymieniamy si\u0119 wiedz\u0105 i do\u015bwiadczeniem.<\/p>\n

    Integro<\/h2>\n

    \nSkupimy si\u0119 na Integro i zaczniemy od stosu technologicznego:<\/p>\n