Mhandisi wa laini Mufeez Amjad amechapisha maelezo ya kina ya jinsi kampuni hiyo ilivyorekebisha bomba lake la ujumuishaji linaloendelea baada ya mawakala wa usimbaji wa AI kugeuza CI kuwa kizuizi chake kibaya zaidi - kukata muda wa kungoja kutoka zaidi ya dakika sita hadi zaidi ya tano huku vyumba vyake vya majaribio karibu mara nne tangu mwanzo wa mwaka.
Chapisho, lililochapishwa kwenye blogu ya uhandisi ya Linear mnamo Septemba 21, ilianza, kama mambo haya mara nyingi hufanya, kwa tikiti fupi kutoka juu. Mapema mwaka huu, Amjad alifungua Linear na kugundua kuwa Tuomas, CTO wa kampuni hiyo, alikuwa amemkabidhi toleo lililoitwa "Gharama za CI ni kubwa" - na kumtaka atengeneze CI haraka alipokuwa akiifanya. Kwa muktadha zaidi kuhusu hadithi hii, angalia utangazaji wetu wa tasnia ya AI.
Wakati Mawakala Wanapita Uthibitishaji wa Nafasi
Tatizo ni la kimuundo, si la kubahatisha. "Mawakala wamefanya iwe haraka sana kusafirisha msimbo," Amjad aliandika, "lakini kuthibitisha mabadiliko hayo hakujawa na kiwango sawa." Kila ombi la kuvuta bado linapaswa kupitishwa kupitia CI, ili maendeleo yanapoharakisha, CI inakuwa kichochezi - kuongeza gharama za miundombinu na kuwaacha wasanidi programu na mawakala wao wakisubiri maoni kwa muda mrefu.
Mstari ulioboreshwa kwa vipimo viwili: muda gani PR inasubiri kwenye CI, na muda wa mkimbiaji hutumia. Matokeo baada ya miezi ya kazi: licha ya vyumba vya majaribio kukaribia kuongezeka mara nne tangu Januari, muda wa kusubiri wa ombi la kuvuta ulipungua kutoka zaidi ya dakika sita hadi zaidi ya tano, na muda wa mkimbiaji kwa kila jaribio ulipunguzwa takribani nusu.
Kazi kwa ujumla iliangukia katika kategoria nne: miundomsingi iliyoboreshwa na zana, iliboresha kazi zinazosimamia kazi nyingine, kupunguza usanidi unaorudiwa, na kufanya utekelezaji wa majaribio kuwa mzuri zaidi. Msingi wa msimbo wa Linear kimsingi ni TypeScript, lakini uboreshaji mwingi hutumika katika lugha na minyororo ya zana.
Mashine Haraka na Mkusanyaji Asilia
Baadhi ya mafanikio ya mapema yalihitaji karibu hakuna uboreshaji wa CI yenyewe. Kuhamisha mizigo ya kazi kutoka kwa Vitendo vya GitHub hadi kwa waendeshaji wengine walio na CPU zenye kasi zaidi, uhifadhi wa utendaji wa juu zaidi, na miundombinu bora ya akiba iliyolipiwa mara moja: kwa kulinganisha kama-kama-kama-kama ya siku mbili kila upande wa swichi, kazi ziliendeshwa kwa kasi ya 34% kwa wastani, huku mizigo ya kazi kama `tsc` ikishuka kwa 52%.
Kuboresha mnyororo wa zana kuliongeza ushindi. Inabadilisha hadi `tsgo`, kikusanyaji asilia cha TypeScript, kata wastani wa kila wiki wa kikagua chapa kwa 73% - kubwa ya kutosha kusogeza kizuizi kwenye ukaguzi wa chapa kabisa.
Kuunganisha Bila Aina ya Grafu
Linting ilikuwa lengo lingine la mapema. Baadhi ya sheria maalum za Linear za ESLint zilitegemea maelezo ya aina ya TypeScript, ambayo ililazimu kila pamba kuunda jedwali la aina kamili kabla ya kuzitathmini - kufanya uwekaji kuwa mojawapo ya kazi zinazohitaji kumbukumbu zaidi za CI.
Timu iliandika upya sheria ili kutumia uchanganuzi tuli juu ya mti dhahania wa sintaksia, kutambua miundo inayofanana na utendaji na mifumo ya ulinzi bila maelezo ya aina yoyote. Hiyo inairuhusu ESLint kuacha TypeScript kabisa, kupunguza muda wa lint wa API kwa 68% na muda wa lint wa hazina kwa 55%, huku utumiaji wa kumbukumbu ukishuka sana. Pia ilirahisisha uhamiaji wa baadaye hadi Oxlint, ambayo ilipunguza zaidi dakika za kukimbia za CI zilizotumiwa kwenye safu.
Kupunguza Njia Muhimu
Kwa ukaguzi wa kibinafsi haraka, Linear ilivuta nje na kushughulikia CI kama mfumo. Hilo liliangazia kazi ndogo zilizokaa mbele ya kila kitu kingine - ugunduzi wa mabadiliko ya njia na akiba ya matokeo ya mtihani hukagua lango hilo katika kiwango cha kazi, ikimaanisha kuwa hakuna shadi nane za majaribio ya API inayoweza kuanza hadi ikamilishe.
Marekebisho yalikuwa punjepunje lakini ya kuongezea. Kina cha uchotaji kilichukua lango polepole zaidi kutoka sekunde 94 hadi 20. Kuondoa malipo kutoka kwa kazi ambazo hazikuhitaji mti unaofanya kazi, kata hizo kutoka sekunde 27 hadi 7. Ulipaji mdogo, usio na rangi na historia ndogo uliokoa sekunde 11-zaidi ya matukio ya kusukuma na kuunganisha kwenye foleni. Kwa jumla, muda wa wastani wa kazi ya kugundua mabadiliko ulishuka kutoka sekunde 26 hadi 8, p90 yake kutoka 31 hadi 12, na mwendo wa polepole zaidi kutoka sekunde 138 hadi 37.
Kuegemea kwa Malipo kulihitaji kazi pia: kwa sababu wakimbiaji wa wahusika wengine hukaa nje ya mtandao wa GitHub na wanategemea kiungo cha moja kwa moja cha IP, uharibifu wa viungo mara kwa mara ulikwama. Linear ilibadilisha `action/checkout` na kitendo chake cha mchanganyiko ambacho hujaribu tena kwa kurudi nyuma, huweka `GIT_HTTP_LOW_SPEED_LIMIT` na `GIT_HTTP_LOW_SPEED_TIME` hivyo muunganisho uliokwama hukatika baada ya takriban sekunde 30 badala ya kuning'inia, na hutumia akiba ya malipo ambayo huweka diski inayoendelea ya giti.
Urekebishaji mmoja wa hila uliondolewa ulipoteza muda wa kuunganisha-foleni: alama za akiba zilikuwa zikiandikwa kama sehemu ya ukaguzi wa mwisho kabla ya kuunganishwa, ili PR iweze kukaa kwenye foleni hata baada ya majaribio yake kupita. Kuhamisha maandishi hayo hadi kwa kazi isiyo ya kufunga kunyoa sekunde 42 kutoka kwa njia ya kuunganisha kwa kila ombi la kuvuta API na ingizo la foleni. Kwa pamoja, mabadiliko haya yalichukua takribani dakika moja kutoka kwa ukaguzi unaohitajika wa API PR kwenye makosa ya akiba huku ikipunguza kuanza kwa mkimbiaji.
Sekunde Zilizopotea chache kwa kila Kazi
Kategoria ya mwisho ilishambuliwa gharama ya usanidi inayorudiwa katika kila kazi. Kila sehemu ya majaribio ya API ilitumia sekunde 7 hadi 8 kusakinisha kiteja sawa cha Postgres kilicho na uwezo wa kila kukimbia; kuisogeza kwenye taswira ndogo ya msingi wa CI kando ya Node ilimaanisha kuwa shards zinaweza kuanza kuwa tayari kufanya kazi. Timu baadaye iliongeza vichwa vya muundo asili kwenye picha baada ya kugundua kuwa kupakua wakati wa kusanidi kunaweza kunyongwa mara kwa mara.
Kwanini Ilisikika
Chapisho hilo lilivutia watengenezaji: lilifika ukurasa wa mbele wa Hacker News, likitoa takriban pointi 250 na maoni karibu 280 ndani ya siku moja. Majibu ni rahisi kueleza - Uzoefu wa Linear unataja gharama ya maendeleo inayosaidiwa na AI ambayo mashirika mengi ya uhandisi yanakabiliana nayo sasa. Mawakala ambao hutoa maombi ya kuvuta kwa dakika bado wanasubiri njia za uthibitishaji zilizoundwa kwa ajili ya mwanguko wa binadamu, na kila dakika ya kusubiri huko inazidishwa kwa kila wakala anayefanya kazi sambamba.
Somo kutoka kwa urekebishaji upya wa Linear ni kwamba kizuizi kinaweza kusogezwa, lakini tu kupitia mkusanyiko usiopendeza wa marekebisho mengi madogo - wakimbiaji haraka, hakiki za bei nafuu, sheria za laini za kiwango cha sintaksia, mizigo iliyofungwa, malipo thabiti, picha zilizoundwa mapema - badala ya risasi moja ya fedha.
---
Kaa Mbele ya AIPata habari za hivi punde za AI, uchanganuzi na mafanikio - yote katika sehemu moja.
Soma habari zaidi za AI →
