Mazoezi ya DevOps hufanya kazi. Tulishawishika na hili sisi wenyewe tulipopunguza muda wa usakinishaji wa kutolewa kwa mara 10. Katika mfumo wa Wasifu wa FIS, ambao tunautumia kwenye VTB, usakinishaji sasa unachukua dakika 90 badala ya 10. Muda wa kujenga kutolewa umepungua kutoka wiki mbili hadi siku mbili. Idadi ya kasoro za utekelezaji zinazoendelea imepungua hadi karibu kiwango cha chini. Ili kuondokana na "kazi ya mikono" na kuondokana na utegemezi kwa muuzaji, tulipaswa kufanya kazi na viboko na kutafuta ufumbuzi usiotarajiwa. Chini ya kukata kuna hadithi ya kina kuhusu jinsi tulivyojenga maendeleo kamili ya ndani.
Dibaji: DevOps ni falsafa
Katika mwaka uliopita, tumefanya kazi nyingi kuandaa maendeleo ya ndani na utekelezaji wa desturi za DevOps katika VTB:
- Tulijenga michakato ya maendeleo ya ndani kwa mifumo 12;
- Tulizindua mabomba 15, manne kati ya hayo yaliletwa kwa uzalishaji;
- Matukio ya majaribio ya otomatiki 1445;
- Tulitekeleza kwa ufanisi matoleo kadhaa yaliyotayarishwa na timu za ndani.
Mojawapo ya ngumu zaidi kuandaa maendeleo ya ndani na utekelezaji wa mazoea ya DevSecOps iligeuka kuwa mfumo wa Wasifu wa FIS - mchakataji wa bidhaa za rejareja kwenye DBMS isiyo ya uhusiano. Hata hivyo, tuliweza kuunda usanidi, kuzindua bomba, kusakinisha vifurushi vya kibinafsi visivyotolewa kwenye bidhaa, na kujifunza jinsi ya kukusanya matoleo. Kazi haikuwa rahisi, lakini ya kuvutia na bila vikwazo dhahiri katika utekelezaji: hapa ni mfumo - unahitaji kujenga maendeleo ya ndani ya nyumba. Sharti pekee ni kutumia CD kabla ya mazingira yenye tija.
Mwanzoni, algorithm ya utekelezaji ilionekana rahisi na wazi:
- Tunakuza utaalamu wa awali wa maendeleo na kufikia kiwango kinachokubalika cha ubora kutoka kwa timu ya kanuni bila kasoro kubwa;
- Tunajumuisha katika michakato iliyopo kadiri iwezekanavyo;
- Ili kuhamisha msimbo kati ya hatua za wazi, tunakata bomba na kushinikiza moja ya mwisho wake katika kuendelea.
Wakati huu, timu ya maendeleo ya ukubwa unaohitajika lazima kukuza ujuzi na kuongeza sehemu ya mchango wake kwa releases kwa kiwango kinachokubalika. Na hiyo ndiyo yote, tunaweza kuzingatia kazi iliyokamilishwa.
Inaweza kuonekana kuwa hii ni njia ya ufanisi wa nishati kwa matokeo yanayohitajika: hapa kuna DevOps, hapa kuna vipimo vya utendaji wa timu, hapa kuna utaalam uliokusanywa ... Lakini katika mazoezi, tulipokea uthibitisho mwingine kwamba DevOps bado inahusu falsafa. , na sio "imeambatishwa kwa mchakato wa gitlab, inayowezekana, uhusiano na chini ya orodha."
Baada ya kuchambua mpango wa utekelezaji tena, tuligundua kuwa tulikuwa tunaunda aina ya muuzaji wa nje ndani yetu. Kwa hivyo, urekebishaji wa mchakato uliongezwa kwa algorithm iliyoelezwa hapo juu, pamoja na maendeleo ya utaalamu kwenye njia nzima ya maendeleo ili kufikia jukumu kuu katika mchakato huu. Sio chaguo rahisi zaidi, lakini hii ni njia ya maendeleo sahihi ya kiitikadi.
Maendeleo ya ndani huanza wapi?
Haukuwa mfumo rafiki zaidi kufanya kazi nao. Kwa usanifu, ilikuwa DBMS moja kubwa isiyo ya uhusiano, iliyojumuisha vitu vingi tofauti vinavyoweza kutekelezwa (hati, taratibu, makundi, nk), ambayo yaliitwa kama inahitajika, na kufanya kazi kwa kanuni ya sanduku nyeusi: inapokea ombi na masuala. jibu. Shida zingine zinazostahili kuzingatiwa ni pamoja na:
- Lugha ya kigeni (MUMPS);
- interface ya Console;
- Ukosefu wa ushirikiano na zana maarufu za automatisering na mifumo;
- Kiasi cha data katika makumi ya terabytes;
- Mzigo wa shughuli zaidi ya milioni 2 kwa saa;
- Umuhimu - Biashara-Muhimu.
Wakati huo huo, hapakuwa na hazina ya msimbo wa chanzo upande wetu. Hata kidogo. Kulikuwa na nyaraka, lakini ujuzi na ujuzi wote muhimu ulikuwa upande wa shirika la nje.
Tulianza kusimamia maendeleo ya mfumo karibu kutoka mwanzo, kwa kuzingatia sifa zake na usambazaji mdogo. Ilianza Oktoba 2018:
- Alisoma hati na misingi ya utengenezaji wa kanuni;
- Tulisoma kozi fupi ya maendeleo iliyopokelewa kutoka kwa muuzaji;
- Ujuzi wa maendeleo ya awali;
- Tulikusanya mwongozo wa mafunzo kwa wanachama wapya wa timu;
- Tulikubali kujumuisha timu katika hali ya "kupambana";
- Ilitatua suala hilo kwa udhibiti wa ubora wa msimbo;
- Tulipanga jukwaa la maendeleo.
Tulitumia miezi mitatu kukuza utaalam na kujiingiza katika mfumo, na tangu mwanzoni mwa 2019, maendeleo ya ndani yalianza harakati zake kuelekea siku zijazo nzuri, wakati mwingine kwa shida, lakini kwa ujasiri na kwa makusudi.
Uhamiaji wa hifadhi na majaribio ya kiotomatiki
Kazi ya kwanza ya DevOps ni hazina. Tulikubali haraka kutoa ufikiaji, lakini ilikuwa muhimu kuhama kutoka SVN ya sasa na tawi moja la shina hadi Git lengwa letu na mpito hadi mfano wa matawi kadhaa na ukuzaji wa Git Flow. Pia tuna timu 2 zilizo na miundombinu yao wenyewe, pamoja na sehemu ya timu ya wauzaji nje ya nchi. Ilinibidi kuishi na Gits mbili na kuhakikisha maingiliano. Katika hali kama hiyo, ilikuwa ndogo kati ya maovu mawili.
Uhamiaji wa hazina uliahirishwa mara kwa mara; ilikamilishwa mnamo Aprili tu, kwa msaada wa wenzake kutoka mstari wa mbele. Kwa Git Flow, tuliamua kuweka mambo rahisi kwa mwanzo na kutatuliwa kwenye mpango wa kawaida na hotfix, kukuza na kutolewa. Waliamua kuachana na bwana (aka prod-like). Hapo chini tutaelezea kwa nini chaguo hili liligeuka kuwa bora kwetu. Hazina ya nje ya muuzaji, ya kawaida kwa timu mbili, ilitumiwa kama mfanyakazi. Ilisawazishwa na hazina ya ndani kulingana na ratiba. Sasa na Git na Gitlab iliwezekana kubinafsisha michakato.
Suala la majaribio ya kiotomatiki lilitatuliwa kwa kushangaza kwa urahisi - tulipewa mfumo uliotengenezwa tayari. Kwa kuzingatia upekee wa mfumo, kuita operesheni tofauti ilikuwa sehemu inayoeleweka ya mchakato wa biashara na wakati huo huo ilitumika kama mtihani wa kitengo. Iliyobaki ni kuandaa data ya mtihani na kuweka utaratibu unaohitajika wa kuita maandishi na kutathmini matokeo. Wakati orodha ya matukio, iliyoundwa kwa msingi wa takwimu za operesheni, umuhimu wa michakato na mbinu iliyopo ya urekebishaji, iliyojazwa, majaribio ya kiotomatiki yalianza kuonekana. Sasa tunaweza kuanza kujenga bomba.
Jinsi ilivyokuwa: mfano kabla ya automatisering
Mfano uliopo wa mchakato wa utekelezaji ni hadithi tofauti. Kila urekebishaji ulihamishwa kwa mikono kama kifurushi tofauti cha usakinishaji wa nyongeza. Ifuatayo ilikuja usajili wa mwongozo katika Jira na usakinishaji kwa mikono kwenye mazingira. Kwa vifurushi vya mtu binafsi, kila kitu kilionekana wazi, lakini kwa maandalizi ya kutolewa, mambo yalikuwa magumu zaidi.
Mkutano ulifanyika kwa kiwango cha utoaji wa mtu binafsi, ambao ulikuwa vitu vya kujitegemea. Mabadiliko yoyote ni uwasilishaji mpya. Miongoni mwa mambo mengine, matoleo 60-70 ya kiufundi yaliongezwa kwa vifurushi 10-15 vya muundo mkuu wa toleo - matoleo yaliyopatikana wakati wa kuongeza au kujumuisha kitu kutoka kwa toleo na kuonyesha mabadiliko katika mauzo nje ya matoleo.
Vipengee ndani ya uwasilishaji vilipishana, haswa katika msimbo unaoweza kutekelezeka, ambao haukuwa wa kipekee. Kulikuwa na utegemezi mwingi kwenye nambari iliyosanikishwa tayari na kwa ile ambayo usakinishaji wake ulipangwa tu.
Ili kupata toleo linalohitajika la msimbo, ilikuwa ni lazima kufuata madhubuti utaratibu wa ufungaji, wakati ambapo vitu viliandikwa upya kimwili mara nyingi, baadhi ya mara 10-12.
Baada ya kusanikisha kundi la vifurushi, ilibidi nifuate maagizo kwa mikono ili kuanzisha mipangilio. Toleo hilo lilikusanywa na kusakinishwa na muuzaji. Muundo wa toleo hilo ulifafanuliwa karibu kabla ya wakati wa utekelezaji, ambao ulijumuisha uundaji wa vifurushi vya "kutenganisha". Matokeo yake, sehemu kubwa ya vifaa vilihamia kutoka kwa kutolewa hadi kutolewa na mkia wake wa "decouplings".
Sasa ni wazi kwamba kwa mbinu hii - kukusanya fumbo la kutolewa kwenye kiwango cha kifurushi - tawi moja kuu halikuwa na maana ya vitendo. Ufungaji kwenye uzalishaji ulichukua kutoka saa moja na nusu hadi saa mbili za kazi ya mikono. Ni vizuri kwamba angalau katika ngazi ya kisakinishi utaratibu wa usindikaji wa kitu ulibainishwa: mashamba na miundo yaliingizwa kabla ya data kwao na taratibu. Walakini, hii ilifanya kazi tu ndani ya kifurushi tofauti.
Matokeo ya kimantiki ya mbinu hii yalikuwa kasoro za usakinishaji wa lazima kwa namna ya matoleo potofu ya vitu, msimbo usio wa lazima, maagizo yaliyokosekana na kutohesabika kwa ushawishi wa pamoja wa vitu, ambavyo viliondolewa kwa nguvu baada ya kutolewa.
Sasisho za kwanza: fanya mkusanyiko na utoaji
Kiotomatiki kilianza kwa kusambaza nambari kupitia bomba kwenye njia hii:
- Kuchukua utoaji wa kumaliza kutoka kwenye hifadhi;
- Weka kwenye mazingira ya kujitolea;
- Fanya majaribio ya kiotomatiki;
- Tathmini matokeo ya ufungaji;
- Piga bomba lifuatalo kwenye kando ya amri ya majaribio.
Bomba linalofuata linapaswa kusajili kazi katika Jira na kusubiri amri za kusambazwa kwa vitanzi vya kupima vilivyochaguliwa, ambavyo hutegemea muda wa utekelezaji wa kazi. Trigger - barua kuhusu utayari wa kujifungua kwa anwani fulani. Hii, bila shaka, ilikuwa njia ya wazi, lakini ilibidi nianzie mahali fulani. Mnamo Mei 2019, uhamishaji wa nambari ilianza na ukaguzi wa mazingira yetu. Mchakato umeanza, kilichobaki ni kuifanya iwe na sura nzuri:
- Kila urekebishaji unafanywa katika tawi tofauti, ambalo linalingana na kifurushi cha ufungaji na kuunganishwa kwenye tawi kuu la lengo;
- Kichochezi cha uzinduzi wa bomba ni kuonekana kwa ahadi mpya katika tawi kuu kupitia ombi la kuunganisha, ambalo limefungwa na watunzaji kutoka kwa timu ya ndani;
- Hifadhi husawazishwa mara moja kila dakika tano;
- Mkusanyiko wa mfuko wa ufungaji umeanza - kwa kutumia mkusanyiko uliopokea kutoka kwa muuzaji.
Baada ya hayo, tayari kulikuwa na hatua zilizopo za kuangalia na kuhamisha msimbo, kuzindua bomba na kukusanyika upande wetu.
Chaguo hili lilizinduliwa mnamo Julai. Ugumu wa mpito ulisababisha kutoridhika kati ya muuzaji na mstari wa mbele, lakini kwa mwezi uliofuata tuliweza kuondoa kingo zote mbaya na kuanzisha mchakato kati ya timu. Sasa tuna mkusanyiko kwa ahadi na utoaji.
Mnamo Agosti, tulifanikiwa kukamilisha usakinishaji wa kwanza wa kifurushi tofauti kwenye uzalishaji kwa kutumia bomba letu, na tangu Septemba, bila ubaguzi, usakinishaji wote wa vifurushi visivyo vya kutolewa ulifanywa kupitia zana yetu ya CD. Kwa kuongeza, tuliweza kufikia sehemu ya kazi za ndani katika 40% ya utungaji wa kutolewa na timu ndogo kuliko muuzaji - hii ni mafanikio ya uhakika. Kazi kubwa zaidi ilibaki - kukusanyika na kusanikisha toleo.
Suluhisho la mwisho: vifurushi vya ufungaji vilivyojumuishwa
Tulielewa vyema kwamba kuandika maagizo ya muuzaji ilikuwa otomatiki sana; ilibidi tufikirie upya mchakato wenyewe. Suluhisho lilikuwa dhahiri - kukusanya usambazaji wa jumla kutoka kwa tawi la kutolewa na vitu vyote vya matoleo yanayohitajika.
Tulianza na uthibitisho wa dhana: tulikusanya kwa mkono kifurushi cha kutolewa kulingana na yaliyomo katika utekelezaji uliopita na kukisakinisha kwenye mazingira yetu. Kila kitu kilifanyika, wazo hilo liligeuka kuwa linalowezekana. Kisha, tulitatua suala la kuandika mipangilio ya uanzishaji na kuijumuisha katika ahadi. Tulitayarisha kifurushi kipya na kukifanyia majaribio katika mazingira ya majaribio kama sehemu ya sasisho la mtaro. Usakinishaji ulifanikiwa, ingawa kulikuwa na maoni mengi kutoka kwa timu ya utekelezaji. Lakini jambo kuu ni kwamba tulipewa idhini ya kwenda katika uzalishaji katika toleo la Novemba na mkusanyiko wetu.
Ikiwa imesalia zaidi ya mwezi mmoja, vifaa vilivyochukuliwa kwa mkono vilidokeza wazi kwamba muda ulikuwa unaenda. Waliamua kutengeneza jengo hilo kutoka kwa tawi la kutolewa, lakini kwa nini litenganishwe? Hatuna Prod-kama, na matawi yaliyopo si mazuri - kuna nambari nyingi za kuthibitisha zisizohitajika. Tunahitaji kwa haraka kupunguza upendeleo wa prod, na hii ni zaidi ya ahadi elfu tatu. Kukusanyika kwa mkono sio chaguo kabisa. Tulichora hati inayopitia logi ya usakinishaji wa bidhaa na kukusanya ahadi kwenye tawi. Mara ya tatu ilifanya kazi kwa usahihi, na baada ya "kumaliza na faili" tawi lilikuwa tayari.
Tuliandika mjenzi wetu kwa kifurushi cha ufungaji na tukamaliza kwa wiki. Kisha tulilazimika kurekebisha kisakinishi kutoka kwa utendakazi wa msingi wa mfumo, kwani ni chanzo wazi. Baada ya mfululizo wa hundi na marekebisho, matokeo yalionekana kuwa mafanikio. Wakati huo huo, utungaji wa kutolewa ulichukua sura, kwa ajili ya ufungaji sahihi ambayo ilikuwa ni lazima kuunganisha mzunguko wa mtihani na moja ya uzalishaji, na script tofauti iliandikwa kwa hili.
Kwa kawaida, kulikuwa na maoni mengi kuhusu usakinishaji wa kwanza, lakini kwa ujumla msimbo ulifanya kazi. Na baada ya ufungaji wa tatu kila kitu kilianza kuonekana vizuri. Udhibiti wa utungaji na udhibiti wa toleo la vitu vilifuatiliwa kando katika hali ya mwongozo, ambayo katika hatua hii ilikuwa sahihi kabisa.
Changamoto ya ziada ilikuwa idadi kubwa ya matoleo ambayo hayajatolewa ambayo yalipaswa kuzingatiwa. Lakini kwa tawi la Prod-kama na Rebase, kazi ikawa wazi.
Mara ya kwanza, haraka na bila makosa
Tulikaribia kutolewa kwa mtazamo wa matumaini na zaidi ya usakinishaji kadhaa uliofaulu kwenye saketi tofauti. Lakini halisi siku moja kabla ya tarehe ya mwisho, ikawa kwamba muuzaji hakuwa amekamilisha kazi ya kuandaa kutolewa kwa ajili ya ufungaji kwa njia iliyokubaliwa. Ikiwa kwa sababu fulani muundo wetu haufanyi kazi, toleo litakatizwa. Zaidi ya hayo, kupitia juhudi zetu, ambayo ni mbaya sana. Hatukuwa na njia ya kurudi nyuma. Kwa hiyo, tulifikiri kupitia chaguzi mbadala, tukatayarisha mipango ya hatua na kuanza ufungaji.
Kwa kushangaza, kutolewa nzima, iliyo na vitu zaidi ya 800, ilianza kwa usahihi, mara ya kwanza na kwa dakika 10 tu. Tulitumia saa moja kuangalia kumbukumbu kutafuta makosa, lakini hatukupata yoyote.
Siku iliyofuata kulikuwa na ukimya katika gumzo la toleo: hakuna matatizo ya utekelezaji, matoleo potofu au msimbo "usiofaa". Ilikuwa hata kwa namna fulani mbaya. Baadaye, baadhi ya maoni yaliibuka, lakini ikilinganishwa na mifumo mingine na uzoefu wa awali, idadi na kipaumbele chao vilikuwa chini sana.
Athari ya ziada kutoka kwa athari ya mkusanyiko ilikuwa ongezeko la ubora wa mkusanyiko na upimaji. Kwa sababu ya usakinishaji mwingi wa toleo kamili, kasoro za ujenzi na hitilafu za utumiaji zilitambuliwa kwa wakati ufaao. Kujaribu katika usanidi kamili wa toleo kulifanya iwezekane kubainisha kasoro katika ushawishi wa pamoja wa vitu ambavyo havikuonekana wakati wa usakinishaji wa nyongeza. Hakika ilikuwa mafanikio, hasa kutokana na mchango wetu wa 57% katika toleo hili.
Matokeo na hitimisho
Katika chini ya mwaka mmoja tulifanikiwa:
- Jenga maendeleo kamili ya ndani kwa kutumia mfumo wa kigeni;
- Kuondoa utegemezi muhimu wa muuzaji;
- Zindua CI/CD kwa urithi usio rafiki sana;
- Kuinua michakato ya utekelezaji kwa kiwango kipya cha kiufundi;
- Kupunguza kwa kiasi kikubwa muda wa kupeleka;
- Kupunguza kwa kiasi kikubwa idadi ya makosa ya utekelezaji;
- Jitangaze kwa ujasiri kama mtaalam mkuu wa maendeleo.
Bila shaka, mengi ya yale yaliyoelezwa yanaonekana kama ujinga, lakini haya ni sifa za mfumo na vikwazo vya mchakato vilivyomo ndani yake. Kwa sasa, mabadiliko yaliathiri bidhaa na huduma za Wasifu wa IS (akaunti kuu, kadi za plastiki, akaunti za akiba, escrow, mikopo ya fedha), lakini uwezekano wa mbinu hiyo inaweza kutumika kwa IS yoyote ambayo kazi ya kutekeleza mazoea ya DevOps imewekwa. Muundo limbikizi unaweza kuigwa kwa usalama kwa ajili ya utekelezaji unaofuata (ikiwa ni pamoja na zisizo za kutolewa) kutoka kwa usafirishaji mwingi.
Chanzo: mapenzi.com