Vipimo vya kitengo katika DBMS - jinsi tunavyofanya katika Sportmaster, sehemu ya pili

Sehemu ya kwanza - hapa.

Hebu wazia hali hiyo. Unakabiliwa na kazi ya kukuza utendakazi mpya. Una maendeleo kutoka kwa watangulizi wako. Tukichukulia kwamba huna wajibu wa kiadili, ungefanya nini?

Mara nyingi, maendeleo yote ya zamani yamesahaulika na kila kitu huanza tena. Hakuna mtu anayependa kuchimba msimbo wa mtu mwingine, lakini ikiwa una muda, kwa nini usianze kuunda mfumo wako mwenyewe? Hii ni mbinu ya kawaida, na kwa kiasi kikubwa ni sahihi. Lakini katika mradi wetu tulifanya vibaya. Tuliweka msingi wa mfumo wa majaribio wa kiotomatiki wa siku zijazo kwenye maendeleo ya majaribio ya kitengo kwenye utPLSQL kutoka kwa watangulizi wetu, na kisha tukafanya kazi kwa njia kadhaa sambamba.

1. Kurejesha vipimo vya zamani vya kitengo. Ufufuaji unamaanisha kurekebisha majaribio kwa hali iliyopo ya mfumo wa uaminifu na kurekebisha majaribio kwa viwango vya utPLSQL.
2. Kutatua tatizo kwa ufahamu wa nini hasa, ni njia gani na taratibu zinazofunikwa na autotests. Ni lazima uhifadhi maelezo haya kichwani mwako, au ufikie hitimisho kulingana na msimbo wa otomatiki. Kwa hiyo, tuliamua kuunda orodha. Tuliweka msimbo wa kipekee wa mnemonic kwa kila jaribio la kiotomatiki, tukaunda maelezo na mipangilio iliyorekodiwa (kwa mfano, inapaswa kuzinduliwa katika hali gani, au nini kifanyike ikiwa uzinduzi wa jaribio hautafaulu). Kwa hakika, tulijaza metadata kuhusu majaribio ya kiotomatiki na tukaweka metadata hiyo kwenye jedwali za kawaida za utPLSQL.
3. Kufafanua mkakati wa upanuzi, i.e. uteuzi wa utendakazi ambao unaweza kuthibitishwa na majaribio ya kiotomatiki. Tuliamua kuzingatia mambo matatu: uboreshaji wa mfumo mpya, matukio ya uzalishaji, na michakato muhimu ya mfumo. Kwa hivyo, tunaendeleza sambamba na kutolewa, kuhakikisha ubora wake wa juu, wakati huo huo kupanua wigo wa kurejesha na kuhakikisha kuegemea kwa mfumo katika maeneo muhimu. Shida ya kwanza kama hiyo ilikuwa mchakato wa kusambaza punguzo na bonasi kwenye hundi.
4. Kwa kawaida, tulianza kutengeneza majaribio mapya ya kiotomatiki. Mojawapo ya kazi za kwanza za kutolewa ilikuwa kutathmini utendakazi wa sampuli zilizobainishwa awali za mfumo wa uaminifu. Mradi wetu una kizuizi cha hoja zisizobadilika za SQL ambazo huchagua wateja kulingana na hali. Kwa mfano, pata orodha ya wateja wote ambao ununuzi wao wa mwisho ulikuwa katika jiji mahususi, au orodha ya wateja ambao wastani wa kiasi cha ununuzi wao unazidi thamani fulani. Baada ya kuandika majaribio ya kiotomatiki, tulikagua sampuli zilizobainishwa awali, vigezo vya utendakazi vilivyorekodiwa, na zaidi ya hayo tulifanya majaribio ya upakiaji.
5. Kufanya kazi na majaribio ya kiotomatiki inapaswa kuwa rahisi. Vitendo viwili vya kawaida ni kufanya majaribio ya kiotomatiki na kuunda data ya jaribio. Hivi ndivyo moduli mbili za usaidizi zilivyoonekana katika mfumo wetu: moduli ya uzinduzi na moduli ya kizazi cha data.

   Kizindua kinawakilishwa kama utaratibu mmoja wa ulimwengu wote na kigezo kimoja cha kuingiza maandishi. Kama kigezo, unaweza kupitisha msimbo wa mnemonic wa kujaribu kiotomatiki, jina la kifurushi, jina la jaribio, mpangilio wa jaribio la kiotomatiki, au neno kuu lililohifadhiwa. Utaratibu huchagua na kuendesha majaribio yote ya kiotomatiki ambayo yanakidhi masharti.

   Moduli ya kizazi cha data imewasilishwa kwa namna ya mfuko ambao kwa kila kitu cha mfumo chini ya mtihani (meza katika hifadhidata), utaratibu maalum umeundwa ambao huingiza data huko. Katika utaratibu huu, maadili ya kawaida yanajazwa iwezekanavyo, ambayo inahakikisha uundaji wa vitu halisi kwa kubofya kwa kidole. Na kwa urahisi wa matumizi, templates za data zinazozalishwa ziliundwa. Kwa mfano, unda mteja wa umri fulani na simu ya majaribio na ununuzi uliokamilika.

6. Majaribio otomatiki yanapaswa kuanza na kuendeshwa kwa wakati unaokubalika kwa mfumo wako. Kwa hiyo, uzinduzi wa usiku wa kila siku uliandaliwa, kulingana na matokeo ambayo ripoti juu ya matokeo inatolewa na kutumwa kwa timu nzima ya maendeleo kupitia barua ya ushirika. Baada ya kurejesha majaribio ya zamani na kuunda mpya, muda wote wa kufanya kazi ulikuwa dakika 30. Utendaji huu ulimfaa kila mtu, kwani uzinduzi ulifanyika nje ya saa za kazi.

   Lakini ilibidi tufanye kazi katika kuongeza kasi ya kazi. Mfumo wa uaminifu katika uzalishaji unasasishwa usiku. Kama sehemu ya moja ya matoleo, tulilazimika kufanya mabadiliko ya haraka usiku. Kungoja kwa nusu saa kwa matokeo ya uchunguzi wa otomatiki saa tatu asubuhi hakumfurahisha mtu aliyehusika na kutolewa (salamu za dhati kwa Alexey Vasyukov!), Na asubuhi iliyofuata maneno mengi ya fadhili yalisemwa kuelekea mfumo wetu. Lakini matokeo yake, kiwango cha dakika 5 cha kazi kilianzishwa.

   Ili kuharakisha utendaji, tulitumia njia mbili: autotests ilianza kukimbia katika nyuzi tatu sambamba, kwa bahati nzuri hii ni rahisi sana kutokana na usanifu wa mfumo wetu wa uaminifu. Na tuliacha mbinu ambapo autotest haitengenezi data ya majaribio yenyewe, lakini inajaribu kupata kitu kinachofaa katika mfumo. Baada ya kufanya mabadiliko, muda wa jumla wa uendeshaji ulipunguzwa hadi dakika 3-4.

7. Mradi ulio na majaribio ya kiotomatiki unapaswa kuwa na uwezo wa kupelekwa katika vituo mbalimbali. Mwanzoni mwa safari yetu, kulikuwa na majaribio ya kuandika faili zetu za batch, lakini ikawa wazi kuwa usakinishaji wa kiotomatiki uliojiandika ulikuwa wa kutisha kabisa, na tukageuka kuelekea suluhisho za viwandani. Kutokana na ukweli kwamba mradi huo una kanuni nyingi za moja kwa moja (kwanza kabisa, tunahifadhi msimbo wa autotest) na data ndogo sana (data kuu ni metadata kuhusu autotests), utekelezaji katika mradi wa Liquibase uligeuka kuwa rahisi sana.

   Ni chanzo-wazi, maktaba inayojitegemea ya hifadhidata kwa ajili ya kufuatilia, kudhibiti, na kutekeleza mabadiliko ya schema ya hifadhidata. Inasimamiwa kupitia safu ya amri au mifumo kama vile Apache Maven. Kanuni ya uendeshaji wa Liquibase ni rahisi sana. Tuna mradi uliopangwa kwa njia fulani, ambayo inajumuisha mabadiliko au hati ambazo zinahitaji kupitishwa kwa seva inayolengwa, na kudhibiti faili zinazoamua katika mlolongo upi na kwa vigezo gani mabadiliko haya yanapaswa kusakinishwa.

   Katika kiwango cha DBMS, meza maalum imeundwa ambayo Liquibase huhifadhi logi ya rollover. Kila badiliko lina heshi iliyokokotolewa, ambayo inalinganishwa kila wakati kati ya mradi na serikali katika hifadhidata. Shukrani kwa Liquibase, tunaweza kufanya mabadiliko kwa mfumo wetu kwa saketi yoyote kwa urahisi. Majaribio ya kiotomatiki sasa yanazinduliwa kwenye mizunguko ya majaribio na kutolewa, na pia kwenye vyombo (mizunguko ya kibinafsi ya watengenezaji).

Kwa hiyo, hebu tuzungumze kuhusu matokeo ya kutumia mfumo wetu wa kupima kitengo.

1. Bila shaka, kwanza kabisa, tuna hakika kwamba tumeanza kuendeleza programu bora zaidi. Majaribio otomatiki huzinduliwa kila siku na makosa kadhaa hupatikana kila toleo. Zaidi ya hayo, baadhi ya makosa haya yanahusiana kwa njia isiyo ya moja kwa moja tu na utendakazi ambao kwa kweli tulitaka kubadilisha. Kuna mashaka makubwa kwamba makosa haya yalipatikana kwa kupima mwongozo.
2. Timu sasa ina imani kwamba utendakazi mahususi unafanya kazi kwa usahihi... Kwanza kabisa, hii inahusu michakato yetu muhimu. Kwa mfano, zaidi ya miezi sita iliyopita hatujapata shida yoyote na usambazaji wa punguzo na bonasi kwenye risiti, licha ya mabadiliko ya kutolewa, ingawa katika vipindi vya awali makosa yalitokea na frequency fulani.
3. Tuliweza kupunguza idadi ya marudio ya majaribio. Kwa sababu ya ukweli kwamba majaribio ya kiotomatiki yameandikwa kwa utendakazi mpya, wachambuzi na wajaribu wa muda hupokea msimbo wa ubora wa juu, kwa sababu tayari imeangaliwa.
4. Baadhi ya maendeleo katika majaribio ya kiotomatiki hutumiwa na wasanidi programu. Kwa mfano, data ya majaribio kwenye vyombo huundwa kwa kutumia moduli ya kutengeneza kitu.
5. Ni muhimu kwamba tumeanzisha "kukubalika" kwa mfumo wa kupima kiotomatiki kutoka kwa wasanidi programu. Kuna ufahamu kwamba hii ni muhimu na muhimu. Lakini kutokana na uzoefu wangu mwenyewe naweza kusema kwamba hii ni mbali na kesi hiyo. Majaribio ya kiotomatiki yanahitaji kuandikwa, yanahitaji kuungwa mkono na kuendelezwa, matokeo lazima yachambuliwe, na mara nyingi gharama hizi za wakati sio thamani yake. Ni rahisi zaidi kwenda kwenye uzalishaji na kukabiliana na matatizo huko. Hapa, wasanidi programu hujipanga na kutuuliza tufiche utendakazi wao kwa majaribio otomatiki.

Nini kifuatacho

Hebu tuzungumze kuhusu mipango ya maendeleo ya mradi wa kupima otomatiki.

Bila shaka, mradi tu mfumo wa uaminifu wa Sportmaster uko hai na unaendelea kukua, inawezekana pia kuendeleza uchunguzi wa kiotomatiki karibu bila mwisho. Kwa hiyo, mwelekeo kuu wa maendeleo ni kupanua eneo la chanjo.

Kadiri idadi ya majaribio ya kiotomatiki inavyoongezeka, jumla ya muda wao wa kufanya kazi utaongezeka kwa kasi, na tutalazimika tena kurudi kwenye suala la utendakazi. Uwezekano mkubwa zaidi, suluhisho litakuwa kuongeza idadi ya nyuzi zinazofanana.

Lakini hizi ni njia dhahiri za maendeleo. Ikiwa tunazungumza juu ya jambo lisilo la maana zaidi, tunaangazia yafuatayo:

1. Hivi sasa, usimamizi wa autotest unafanywa kwa kiwango cha DBMS, i.e. ujuzi wa PL/SQL unahitajika kwa kazi yenye mafanikio. Ikiwa ni lazima, usimamizi wa mfumo (kwa mfano, kuzindua au kuunda metadata), unaweza kuunda aina fulani ya jopo la msimamizi kwa kutumia Jenkins au kitu sawa.
2. Kila mtu anapenda viashiria vya kiasi na ubora. Kwa majaribio ya kiotomatiki, kiashirio kama hicho cha jumla ni Ufikiaji wa Msimbo au kipimo cha chanjo ya msimbo. Kwa kutumia kiashirio hiki, tunaweza kubaini ni asilimia ngapi ya msimbo wa mfumo wetu unaojaribiwa hufunikwa na majaribio ya kiotomatiki. Kuanzia toleo la 12.2, Oracle hutoa uwezo wa kukokotoa kipimo hiki na inatoa matumizi ya kifurushi cha kawaida cha DBMS_PLSQL_CODE_COVERAGE.

   Mfumo wetu wa majaribio ya kiotomatiki una zaidi ya mwaka mmoja na labda sasa ndio wakati wa kutathmini huduma zetu. Katika mradi wangu wa mwisho (sio mradi wa Sportmaster) hii ndio ilifanyika. Mwaka mmoja baada ya kufanya majaribio ya kiotomatiki, usimamizi uliweka jukumu la kutathmini ni asilimia ngapi ya msimbo tunaoshughulikia. Kwa chanjo ya zaidi ya 1%, usimamizi utafurahi. Sisi, watengenezaji, tulitarajia matokeo ya takriban 10%. Tuliweka chanjo ya msimbo, tukaipima, na tukapata 20%. Ili kusherehekea, tulienda kuchukua tuzo, lakini jinsi tulivyoenda kuipata na tulikokwenda baadaye ni hadithi tofauti kabisa.

3. Majaribio otomatiki yanaweza kuangalia huduma za wavuti zilizofichuliwa. Oracle inaturuhusu kufanya hivi vizuri, na hatutakutana tena na shida kadhaa.
4. Na, bila shaka, mfumo wetu wa kupima otomatiki unaweza kutumika kwa mradi mwingine. Suluhisho tulilopokea ni la ulimwengu wote na linahitaji tu matumizi ya Oracle. Nilisikia kwamba miradi mingine ya Sportmaster ina nia ya kupima kiotomatiki na labda tutaenda kwao.

Matokeo

Hebu tufanye muhtasari. Kwenye mradi wa mfumo wa uaminifu katika Sportmaster, tuliweza kutekeleza mfumo wa kupima otomatiki. Inategemea suluhisho la utPLSQL kutoka kwa Stephen Feuerstein. Karibu na utPLSQL kuna msimbo wa kiotomatiki na moduli za kujiandikia msaidizi: moduli ya uzinduzi, moduli ya kuunda data na zingine. Majaribio ya kiotomatiki yanazinduliwa kila siku na, muhimu zaidi, yanafanya kazi na yanafaa. Tuna uhakika kwamba tumeanza kutoa programu ya ubora wa juu. Wakati huo huo, suluhisho linalosababishwa ni la ulimwengu wote na linaweza kutumika kwa uhuru kwa mradi wowote ambapo ni muhimu kuandaa upimaji wa otomatiki kwenye Oracle DBMS.

PS Nakala hii sio maalum sana: kuna maandishi mengi na kwa kweli hakuna mifano ya kiufundi. Ikiwa mada kwa ujumla ni ya kuvutia, basi tuko tayari kuiendeleza na kurudi na muendelezo, ambapo tutakuambia kilichobadilika zaidi ya miezi sita iliyopita na kutoa mifano ya kanuni.

Andika maoni ikiwa kuna mambo ambayo yanapaswa kusisitizwa wakati ujao, au maswali yanayohitaji ufichuzi.

Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. Weka sahihitafadhali.

Je, tuandike zaidi kuhusu hili?

• Ndiyo, hakika

• Hapana asante

Watumiaji 12 walipiga kura. Watumiaji 4 walijizuia.

Chanzo: mapenzi.com