AI кодчилол CI пайплайныг боомилж эхлэв: Linear өөрийн бүтцийг хэрхэн сууриар нь шинэчлэв?

Сүүлийн үед хөгжүүлэлтийн ертөнцөд нэгэн томоохон шилжилт чимээгүйхэн өрнөж байна. Хөгжүүлэгчид Cursor, Claude Code, GitHub Copilot зэрэг агентуудыг өдөр тутмын ажилдаа нэвтрүүлснээр кодын эхний хувилбарыг бичих, алдаа засах, рефактор хийх хурд асар огцом өссөн. Гэвч энэхүү "хэт хурдатгал" нь програм хангамжийн дэд бүтцэд огт өөр гацааг (bottleneck) үүсгэж эхэллээ: энэ бол CI (Continuous Integration) пайплайн юм.

Код хэдхэн секундийн дотор бэлэн болж, нэг өдөрт нээгдэх Pull Request (PR)-ийн тоо хэд дахин нэмэгдэхэд хуучин загварын CI системүүд дарааллаа дийлэхээ больж, хөгжүүлэгчид код шалгагдахыг хүлээж гацах болов. Хурд, гүйцэтгэлээрээ бахархдаг ажлын менежментийн платформ Linear энэхүү сорилттой нүүр тулж, өөрсдийн CI дэд бүтцээ хэрхэн сууриар нь өөрчилсөн техникийн туршлагаа нийтэллээ.

Асуудал: AI-ийн бүтээмж ба CI-ийн "үхлийн бүс"

Linear-ийн багийн мэдээлснээр, инженерийн багт AI хэрэгслүүдийн хэрэглээ нэвтэрснээс хойш кодын баталгаажуулалтын тестүүд богино хугацаанд бараг 4 дахин нэмэгджээ. Тестүүд олшрох тусам GitHub Actions дээрх runner-уудын зардал, хугацаа асар ихээр тэлж, энгийн нэг PR-ийн үр дүнг хүлээх дундаж хугацаа 6 минутаас давж эхэлсэн байна.

Хөгжүүлэгч бүр өдөрт 5-10 удаа кодоо CI-аар шалгуулдаг гэж тооцвол, багийн бүтээмж AI-ийн ачаар биш, харин түүний үүсгэсэн дарааллын улмаас эсрэгээрээ саарах эрсдэл бий болов. Үүнийг шийдэхийн тулд тэд ердөө "илүү үнэтэй, олон runner худалдаж авах" биш, архитектурын 4 түвшний оновчлол хийсэн байна.

1. Бэлэн бэлтгэсэн суурь CI Docker Image ашиглах

CI дээрх олон жижиг ажлууд ашигтай ажил хийхээсээ илүүтэй runner эхлүүлэх, багц суулгах, шаардлагатай сангуудыг бэлтгэхэд хамгийн их хугацаа алддаг. Жишээлбэл, Linear-ийн API тестийн shard бүр ажиллах болгондоо apt ашиглан PostgreSQL клиент болон системийн сангуудыг шинээр татаж суулгадаг байсан нь тест болгонд 7–8 секундийн нэмэлт зардал болдог байв.

Linear-ийн инженерүүд үүнийг хасч, Node.js болон байнга хэрэглэгддэг PostgreSQL клиент, натив сангуудын build header-үүдийг урьдчилан суурилуулсан жижиг, тусгай CI base image бэлтгэжээ. Ингэснээр сүлжээнээс байнга татаж гацдаг (cold start) эрсдэл бүрэн арилж, shard болгон шууд тестээ эхлүүлэх боломжтой болсон байна.

2. Богино шалгалтуудыг нэгтгэх (Batch Short Checks)

Линеарын өмнөх бүтцэд 7 өөр бие даасан шалгалт (жишээ нь линтер, форматтер, энгийн тохиргооны тестүүд) тус тусдаа runner эхлүүлж, репозиторыг checkout хийж, dependency-үүдийг шинээр суулгадаг байв. Энэ 7 ажил бодит байдал дээр хэдхэн секунд үргэлжилдэг ч орчин бэлдэх гэж хэдэн минутыг дэмий үрдэг байжээ.

Баг эдгээр 7 жижиг шалгалтыг ердөө 2 том ажил (job) болгон нэгтгэж, тухайн ажлын дотор паралелиар ажиллуулснаар дахин давтагддаг орчин бэлтгэх үйлдлийг 7-гоос 2 болгон бууруулав. Энэ өөрчлөлт нь сар бүр 87,000 runner-минут буюу нийт CI хэрэглээний 11.8%-ийг хэмнэжээ.

3. Vitest-ийн модуль тусгаарлалтыг (Isolation) оновчлох

Хамгийн том гүйцэтгэлийн үсрэлтийг энэхүү алхам авчирсан байна. Vitest фрэймворк нь анхдагч тохиргоогоороо тест файл бүрийг бүрэн тусгаарлагдсан орчинд (isolated mode) ажиллуулдаг. Linear-ийн хувьд тест файл бүр дээр том хэмжээний GraphQL схем, дата моделийн энтити, декораторын бүтцийг дахин дахин санах ойд шинээр үүсгэдэг байв.

Linear энэ асуудлыг шийдэхийн тулд Vitest төслөө хоёр хуваажээ:

• Санах ойн глобал төлөв өөрчилдөггүй, "аюулгүй" тестүүдэд зориулж isolate: false тохиргоотой төсөл үүсгэсэн байна. Ингэснээр worker процесс дотор модуль регистрийг нэг л удаа уншиж дундаа хуваалцаж эхлэв.
• Харин үнэхээр тусгаарлах шаардлагатай, глобал төлөв өөрчилдөг тестүүдийг isolated горимд үлдээв.

Үр дүнд нь хамгийн удаан ажилладаг тестийн shard 370+ секундээс 195 секунд хүртэл буурч, Linear-ийн API тестийн нийт runner хугацаа 32.8 минутаас 22 минут болж багассан байна. Энэ нь сарын нийт зардлын 17%-ийг хэмнэсэн хамгийн өндөр өгөөжтэй шийдэл болжээ.

4. Файлын хэмжээгээр тэнцвэржүүлсэн Sharding

Тестүүдийг shard хийхдээ ихэнх багууд файлын тоогоор хуваадаг. Гэтэл Vitest тестүүдийн үргэлжлэх хугацаагаар биш, зөвхөн файлын тоогоор хуваарилдаг тул хэдхэн том integration тесттэй файл ганцаараа нэг shard-ийг бүтэн 5 минут дүүргэж, бусад жижиг shard-ууд 1 минутын дотор дуусаад сул зогсдог байв.

Linear-ийн баг хамгийн хүнд файлуудыг жижиг хэсгүүдэд хуваан бүтэцчилж, shard-ийн тоог 4-өөс 8 болгон нэмэгдүүлжээ. Энэ нь хамгийн урт хугацаа авч байсан "критикал" ажлын хугацааг шууд 19% хурдасгаж, 5.25 минутаас 4.33 минут болгон багасгасан байна.

Үр дүн ба хөгжүүлэгчдэд өгөх сургамж

Эдгээр сайжруулалтын дараа:

• Тестийн бааз бараг 4 дахин нэмэгдсэн атал хөгжүүлэгчийн PR хүлээх хугацаа 6 гаруй минутаас 5 минут хүртэл богиносчээ.
• Тест бүрт зарцуулагдах runner-ийн хугацаа 50%-иар буурсан байна.

AI хэрэгслүүд код бичих асуудлыг шийдэж буй энэ үед програм хангамжийн жинхэнэ гацаа "CI/CD пайплайн болон тестийн дэд бүтэц" рүү шилжиж байгааг уг туршлага тод харуулж байна. Танай баг ч мөн AI ашиглан кодыг олноор үйлдвэрлэж байгаа бол хамгийн түрүүнд CI-ийнхээ кэш, орчин бэлтгэл, тестийн тусгаарлалтын тохиргоондоо анхаарах цаг хэдийнэ болжээ.

Эх сурвалж: Linear Engineering Blog, Hacker News (September 21, 2026)