CI/CD ምንድን ነው? Continuous Integration እና Delivery በቀላል ማብራሪያ

CI/CD ኮድ እያንዳንዱ ለውጥ በራስ-ሰር የሚገነባበት፣ የሚፈተንበትና — ካለፈ — ለመልቀቅ የሚዘጋጅ ወይም የሚለቀቅበት የሶፍትዌር አቀራረብ ነው። CI (continuous integration) ማለት ለውጦች ብዙ ጊዜ ይጣመራሉ እና በእያንዳንዱ ጊዜ በራስ-ሰር ፈተናዎች ይፈተሻሉ ማለት ነው። CD (continuous delivery ወይም deployment) ማለት ያለፉት ለውጦች በትንሽ ወይም ያለ በእጅ ስራ ታሽገው ወደ ተጠቃሚዎችዎ ይገፋሉ ማለት ነው።

ነጥቡ ቀላል ነው፦ ስህተቶችን ከተፈጸሙ በደቂቃዎች ውስጥ ይያዙ፤ ደንበኛ ሳያገኛቸው ሳምንታት ከመጠበቅ።

በAI ሲገነቡ CI/CD ለምን አስፈላጊ ነው

AI መገንቢያዎች የኮድ ለውጦችን በፍጥነት ያደርጋሉ። አንድ ጥያቄ አሥር ፋይሎችን ሊነካ ይችላል። ይህ ፍጥነት እጅግ ጥሩ ነው፤ ነገር ግን የcheckout ገጽ ለውጥ በጸጥታ የlogin ገጽን ሲሰብረው ማንም ተጠቃሚ ኢሜይል እስኪልክልዎ ድረስ ሳይታወቅ ሊቆይ ይችላል።

CI/CD ለዚህ በትክክል መረብ ነው። እያንዳንዱ ለውጥ ጥሩ ነው ብሎ ከማመን ይልቅ pipeline ተመሳሳይ ፍተሻዎችን በእያንዳንዱ ጊዜ ያካሂዳል፦

• መተግበሪያው አሁንም ያለ ስህተት ይገነባል?
• በራስ-ሰር የሚደረጉ ፈተናዎች አሁንም ያልፋሉ?
• ኮዱ የፕሮጀክቱን ህጎች ይከተላል (types፣ formatting፣ የደህንነት ፍተሻዎች)?

ማንኛውም ፍተሻ ቢወድቅ ለውጡ ተጠቃሚዎች ላይ ከመድረሱ በፊት ይቆማል። ኮድዎ በፈጠነ ቁጥር የማይደክምና ደረጃ የማይዘልል ፍተሻ ይበልጥ ዋጋ ያለው ይሆናል።

ዕለታዊ ምሳሌ

በየማለዳው ዳቦ ለሱቆች የሚሸጥ ዳቦ ቤት አስቡ።

• CI/CD ከሌለ እያንዳንዱ ዳቦ ጋጋሪ ለሳምንት የራሱን የምግብ አዘገጃጀት ያስተካክላል፣ ከዚያ ዓርብ ማታ ሁሉም አንድ ላይ ያጣምሩታል እና ዳቦው እንደሚነሳ ተስፋ ያደርጋሉ። ካልነሳ ማንም የማን ለውጥ እንደሆነ አያውቅም።
• CI ጋር እያንዳንዱ ትንሽ የአዘገጃጀት ለውጥ ወዲያውኑ ወደ ፈተና ዳቦ ተጋግሮ ይፈተሻል — ጣዕም፣ ክብደት፣ ቅርጽ። መጥፎ ለውጥ በዚያው ቀን ይያዛል፤ የትኛው እንደነበረ በትክክል ያውቃሉ።
• CD ጋር ፍተሻውን ያለፉ ዳቦዎች ቀጥታ ወደ ማድረስ መኪናው ይሄዳሉ፤ በእያንዳንዱ ጊዜ በተመሳሳይ መንገድ ታሽገውና ተለጥፈው፣ ሰው ጠዋት 5 ሰዓት ሳጥን በእጁ ከመሙላት ይልቅ።

ፍተሻው ጋጋሪዎቹን የተሻሉ አያደርጋቸውም። ስህተቶቻቸውን ርካሽ ያደርገዋል።

የCI/CD pipeline እንዴት ይሠራል

Pipeline አንድ ነገር ሲፈጠር — ብዙውን ጊዜ አንድ ሰው ኮድ እንደ GitHub ወዳለ repository ሲገፋ — በCI/CD አገልግሎት በራስ-ሰር የሚሠራ የእርምጃዎች ዝርዝር ነው። የተለመደ pipeline እንደዚህ ይመስላል፦

እያንዳንዱ እርምጃ በንጹህ ማሽን ላይ ይሠራል፣ በማንም ላፕቶፕ ላይ አይደለም፤ ስለዚህ «በእኔ ኮምፒዩተር ይሠራል» ሰበብ መሆኑ ያቆማል። እርምጃ ቢወድቅ pipeline ይቆማል እና ለውጡን ላደረገው ሰው ይነግራል።

እርምጃዎቹ ከኮዱ ጋር በሚኖር የውቅር ፋይል ውስጥ ይገለጻሉ። ለምሳሌ በGitHub Actions ይህ በrepositoryው .github/workflows አቃፊ ውስጥ ያለ YAML ፋይል ነው።

Continuous delivery ከcontinuous deployment ጋር

«CD» ግልጽ ያልሆነ ነው፤ ሰዎች በሁለት መንገድ ይጠቀሙበታል፦

Continuous deployment ፈተናዎቹ ጥሩ ከሆኑ ብቻ በደንብ ይሠራል። ፈተናዎችዎ checkoutን ካልሸፈኑ፣ continuous deployment የተበላሸ checkout በደስታ ይልካል።

ምሳሌ፦ pipeline ያለው የቦታ ማስያዣ መተግበሪያ

የሳሎን ቦታ ማስያዣ መተግበሪያ አለዎት እንበል፤ ኮዱ በGitHub repository ውስጥ ነው። AI መገንቢያን «ለመጀመሪያ ጊዜ ለሚመጡ ደንበኞች የ10% ቅናሽ ጨምር» ብለው ይጠይቃሉ።

1. ለውጡ ወደ አዲስ branch ይገፋል እና pull request ይከፈታል።
2. Pipelineው ይጀምራል። ፓኬጆችን ይጭናል እና መተግበሪያውን ይገነባል — ይህ ያልፋል።
3. ፈተናዎችን ያካሂዳል። አንድ ፈተና፣ «ተመላሽ ደንበኛ ሙሉ ዋጋ ይከፍላል»፣ ይወድቃል፦ ቅናሹ ለሁሉም እየተተገበረ ነው።
4. Pull requestው ቀይ መስቀል ያሳያል። ለውጡ ሊዋሃድ አይችልም።
5. AIው እንዲያስተካክል ይጠይቃሉ። ማስተካከያ ይገፋል፤ pipelineው ዳግም ይሠራል እና ሁሉም ያልፋል።
6. ለውጡ ይዋሃዳል። Pipelineው ወደ staging አካባቢ ያሰማራዋል፤ እዚያም የሙከራ ቦታ ማስያዝ ይሞክራሉ።
7. ያጸድቃሉ፤ ወደ production ይሰማራል።

Pipeline ከሌለ፣ ደረጃ 3 በደንበኞችዎ ኪስ ውስጥ ይከሰት ነበር።

ቁልፍ ቃላት

የተለመዱ የተሳሳቱ ግንዛቤዎች

• «CI/CD ማለት መተግበሪያዬ ተፈትኗል ማለት ነው።» pipeline የሚያካሂደው ያሉዎትን ፈተናዎች ብቻ ነው። ፈተና ከሌለ CI የሚያረጋግጠው መተግበሪያው እንደሚገነባ ብቻ ነው — ከዚያ በላይ የለም። በጣም አስፈላጊ ለሆኑ ፍሰቶች ፈተናዎች እንዲጽፍ AIውን ይጠይቁ።
• «CI/CD ለትላልቅ ኩባንያዎች ብቻ ነው።» እንደ GitHub Actions ያሉ የተስተናገዱ መሣሪያዎች ለማዋቀር አጭር የውቅር ፋይል ይወስዳሉ፤ ትናንሽ ቡድኖችም ሁልጊዜ ይጠቀሙባቸዋል። ጥረቱን የሚወስደው ፈተናዎቹ እንጂ መሣሪያው አይደለም።
• «በራስ-ሰር ማሰማራት ማለት ማንም ምንም አይፈትሽም ማለት ነው።» ጥሩ pipelines ፍተሻዎችን ይጨምራሉ እንጂ አያስወግዱም። ብዙ ቡድኖች ወደ production ከመሄዳቸው በፊት የሰው ማጽደቂያ ደረጃ ይይዛሉ።
• «pipelineው አረንጓዴ ከሆነ መተግበሪያው ይሠራል ማለት ነው።» ማለት የራስ-ሰር ፍተሻዎቹ አልፈዋል ማለት ነው። አሁንም ለውጡን እራስዎ ይሞክሩ፤ በተለይ በpreview ወይም በstaging ላይ።
• «CI/CD ምትኬዎችን ይተካል።» አይተካም። ፈተናዎችን ያለፈ መጥፎ የዳታቤዝ migration አሁንም እውነተኛ ዳታ ሊያበላሽ ይችላል። ምትኬዎችንና ወደ ኋላ የመመለሻ መንገድ ይዘው ይቆዩ።

ለAI መገንቢያዎ ምን ብለው ይጠይቁ

• «ለsign-up፣ login እና checkout በራስ-ሰር ፈተናዎች ጻፍ፤ እንዴት እንደሚሠሩ አሳየኝ።»
• «በእያንዳንዱ pull request ላይ ጥገኞችን የሚጭን፣ መተግበሪያውን የሚገነባና ፈተናዎችን የሚያካሂድ የGitHub Actions workflow አዘጋጅ።»
• «በpipelineው ላይ type check እና linter ጨምር፤ ስህተቶች ሲኖሩ እንዲወድቅ አድርገው።»
• «የpipelineው እያንዳንዱ እርምጃ ምን እንደሚሠራ በቀላል እንግሊዝኛ አብራራ።»
• «deploy በግማሽ ቢወድቅ ምን ይሆናል? እንዴት ወደ ኋላ እመለሳለሁ?»
• «ምንም ሚስጥር በrepositoryው ውስጥ በቀጥታ ያልተጻፈ ወይም በpipeline logs ውስጥ ያልታተመ መሆኑን አረጋግጥ።»

መተግበሪያዎ API ቁልፎችን የሚጠቀም ከሆነ pipelineውም ያስፈልጋቸዋል — በCI መሣሪያው ውስጥ እንደተመሰጠሩ ሚስጥሮች ይቀመጣሉ፤ በውቅር ፋይሉ ውስጥ በጭራሽ። የአካባቢ ተለዋዋጮችና ሚስጥሮች ይመልከቱ።

CI/CD እና Mythex

Mythex ለእርስዎ CI pipeline አያካሂድም፤ ነገር ግን ተመሳሳይ ፍላጎቶችን በራሱ መንገድ ይሸፍናል፦

• Checkpoints። ከእያንዳንዱ የተሳካ የagent ዙር በኋላ Mythex የgit checkpoint ያስቀምጣል፤ ለውጥ ከተበላሸ ወደዚህ ነጥብ ተመለስ ፕሮጀክቱን ወደ ኋላ ይመልሳል። Chat ይመልከቱ።
• App Testing። /test ብለው ይጻፉ፤ agentው እንደ ተጠቃሚ በቀጥታ preview ላይ ይጫናል እና የተበላሹ ፍሰቶችን ሪፖርት ያደርጋል — ከእያንዳንዱ ማተም በፊት ጠቃሚ ነው። App Testing ይመልከቱ።
• ማተም ሆን ተብሎ የሚደረግ እርምጃ ነው። ለውጦች መጀመሪያ በግል preview ላይ ይታያሉ፤ የይፋው መተግበሪያዎ የሚዘምነው እንደገና ሲያትሙ ብቻ ነው — ከcontinuous deployment ይልቅ ለcontinuous delivery ይቀርባል።
• GitHub sync (Pro)። ፕሮጀክቱን ከGitHub repository ጋር ካመሳሰሉ፣ በእያንዳንዱ push ላይ ፈተናዎችን ለማሄድ የራስዎን GitHub Actions workflows ማከል ይችላሉ። GitHub እና export ይመልከቱ።

ከመልቀቅዎ በፊት በእጅ ምን መፈተሽ እንዳለበት ዝርዝር ለማግኘት መተግበሪያዎን ከመጀመሪያ ጊዜ በፊት እንዴት መፈተሽ እንደሚቻል ይመልከቱ፤ ከversion control ጋር ለመስራት ደግሞ በAI በተገነባ መተግበሪያ Git እንዴት መጠቀም እንደሚቻል።

ጥያቄዎች