Ի՞նչ է CI/CD-ն։ Անընդհատ ինտեգրում և մատուցում պարզ բացատրությամբ
CI/CD-ն ծրագրային ապահովում թողարկելու եղանակ է, որտեղ յուրաքանչյուր կոդի փոփոխություն ավտոմատ կառուցվում, փորձարկվում է և, եթե անցնում է, պատրաստվում թողարկման կամ թողարկվում։ CI (անընդհատ ինտեգրում) նշանակում է, որ փոփոխությունները հաճախ են միաձուլվում և յուրաքանչյուր անգամ ստուգվում ավտոմատ թեստերով։ CD (անընդհատ մատուցում կամ տեղակայում) նշանակում է, որ անցած փոփոխությունները փաթեթավորվում և առաքվում են դեպի ձեր օգտատերերը քիչ կամ առանց ձեռքով աշխատանքի։
Գաղափարն պարզ է․ բռնել սխալները րոպեներ անց, այլ ոչ թե շաբաթներ անց, երբ հաճախորդը դրանք գտնի։
Ինչու է CI/CD-ն կարևոր, երբ կառուցում եք AI-ով
AI կառուցիչները կոդի փոփոխություններ են անում արագ։ Մեկ հրահանգը կարող է ազդել տասը ֆայլի վրա։ Դա հրաշալի է այնքան ժամանակ, քանի դեռ վճարման էջի փոփոխությունը աննկատ չի կոտրում մուտքի էջը և ոչ ոք չի նկատում, մինչև օգտատերը ձեզ նամակ չգրի։
CI/CD-ն հենց այս դեպքի համար է անվտանգության ցանց։ Այն վստահելու փոխարեն, որ յուրաքանչյուր փոփոխություն նորմալ է, խողովակաշարը յուրաքանչյուր անգամ գործարկում է նույն ստուգումները․
- Արդյո՞ք հավելվածը դեռ կառուցվում է առանց սխալների։
- Արդյո՞ք ավտոմատ թեստերը դեռ անցնում են։
- Արդյո՞ք կոդը հետևում է նախագծի կանոններին (տիպեր, ձևաչափում, անվտանգության ստուգումներ)։
Եթե որևէ ստուգում ձախողվում է, փոփոխությունը կանգնեցվում է, մինչև հասնի օգտատերերին։ Որքան արագ են փոխվում ձեր կոդը, այնքան ավելի արժեքավոր է ստուգում, որ երբեք չի հոգնում և չի բաց թողնում քայլ։
Ամենօրյա անալոգիա
Պատկերացրեք հացաթուխ, որը ամեն առավոտ հաց է վաճառում խանութներին։
- CI/CD-ի առանց՝ յուրաքանչյուր խոհարար մեկ շաբաթ իր բաղադրատոմսի փոփոխություններն է անում, ապա ուրբաթ երեկոյան բոլորը միասին են միացնում դրանք և հուսով են, որ հացը դեռ կթափվի։ Երբ չի թափվում, ոչ ոք չգիտի, թե ում փոփոխությունն է պատճառը։
- CI-ով՝ բաղադրատոմսի յուրաքանչյուր փոքր փոփոխություն անմիջապես թխվում է փորձնական հացի մեջ և ստուգվում՝ համ, քաշ, ձև։ Վատ փոփոխությունը բռնվում է նույն օրը, և դուք ճշգրիտ գիտեք, թե որն էր։
- CD-ով՝ ստուգումն անցած հացերը անմիջապես գնում են առաքման մեքենա՝ փաթեթավորված և պիտակավորված միշտ նույն կերպ, այլ ոչ թե մեկը ձեռքով արկղեր է լցնում առավոտյան հինգին։
Ստուգումը հացթուխներին ավելի լավ չի դարձնում։ Այն դարձնում է նրանց սխալները էժան։
Ինչպես է աշխատում CI/CD խողովակաշարը
Խողովակաշար (pipeline)-ը քայլերի ցանկ է, որ CI/CD ծառայությունն ավտոմատ կատարում է, երբ ինչ-որ բան տեղի է ունենում՝ սովորաբար, երբ ինչ-որ մեկը կոդ է հրում (push) դեպի GitHub-ի պես պահոց։ Տիպիկ խողովակաշարը այսպիսին է․
| Քայլ | Ինչ է տեղի ունենում | Ինչ է բռնում |
|---|---|---|
| 1. Գործարկում | Կոդը հրվում է կամ բացվում է pull request | — |
| 2. Տեղադրում | Նոր մեքենան ներբեռնում է կոդը և նրա կախվածությունները | Բացակայող կամ կոտրված փաթեթներ |
| 3. Կառուցում | Հավելվածը կոմպիլացվում կամ փաթեթավորվում է | Շարահյուսական և տիպերի սխալներ, կոտրված ներմուծումներ |
| 4. Թեստեր | Ավտոմատ թեստերը գործարկվում են | Գործառույթներ, որոնք այլևս չեն աշխատում |
| 5. Ստուգումներ | Լինթինգ, ձևաչափում, անվտանգության սկանավորում | Ոճի խնդիրներ, հայտնի խոցելի փաթեթներ, արտահոսած բանալիներ |
| 6. Տեղակայում նախագծային միջավայրում | Հավելվածը գնում է արտադրության փորձնական պատճենի | Խնդիրներ, որոնք երևում են միայն իրական միջավայրում |
| 7. Տեղակայում արտադրությունում | Հավելվածը գնում է կենդանի՝ ինքնաբերաբար կամ հաստատումից հետո | — |
Յուրաքանչյուր քայլ աշխատում է մաքուր մեքենայի վրա, ոչ թե ինչ-որ մեկի նոութբուքի, այնպես որ «ինձ մոտ աշխատում է» արդարացում չէ։ Եթե քայլը ձախողվում է, խողովակաշարը կանգ է առնում և տեղեկացնում է փոփոխություն անողին։
Քայլերը սահմանվում են կոնֆիգուրացիայի ֆայլում, որը գտնվում է կոդի կողքին։ GitHub Actions-ում, օրինակ, դա YAML ֆայլ է պահոցի .github/workflows թղթապանակում։
Անընդհատ մատուցում ընդդեմ անընդհատ տեղակայման
«CD»-ն երկիմաստ է, և մարդիկ այն օգտագործում են երկու ձևով․
| Անընդհատ մատուցում | Անընդհատ տեղակայում | |
|---|---|---|
| Թեստերը ավտոմատ են գործարկվում | Այո | Այո |
| Թողարկումը ավտոմատ է փաթեթավորվում | Այո | Այո |
| Ավտոմատ գնում է կենդանի | Ոչ՝ մարդը սեղմում է «թողարկել» | Այո՝ յուրաքանչյուր անցած փոփոխություն թողարկվում է |
| Լավ է | Փոքր թիմերի մեծամասնության, վճարող օգտատերեր ունեցող հավելվածների համար | Թիմերի, որոնք ունեն ուժեղ թեստային ծածկույթ և մոնիթորինգ |
Անընդհատ տեղակայումը լավ է աշխատում միայն եթե թեստերը լավն են։ Եթե ձեր թեստերը չեն ծածկում դրամարկղը, անընդհատ տեղակայումը ուրախությամբ կթողարկի կոտրված դրամարկղ։
Օրինակ աշխատանքում․ ամրագրման հավելված խողովակաշարով
Նշենք, որ ունեք սրահի ամրագրման հավելված, որի կոդը GitHub պահոցում է։ Դուք AI կառուցիչին խնդրում եք. «ավելացրու 10% զեղչ առաջին անգամ եկող հաճախորդների համար»։
- Փոփոխությունը հրվում է նոր ճյուղ և բացվում է pull request։
- Խողովակաշարը սկսվում է։ Այն տեղադրում է փաթեթները և կառուցում հավելվածը․ սա անցնում է։
- Այն գործարկում է թեստերը։ Մեկ թեստ՝ «վերադարձող հաճախորդը լրիվ գին է վճարում», ձախողվում է․ զեղչը կիրառվում է բոլորի վրա։
- Pull request-ը ցույց է տալիս կարմիր խաչ։ Փոփոխությունը չի կարող միաձուլվել։
- Դուք խնդրում եք AI-ին շտկել։ Այն հրում է ուղղում․ խողովակաշարը նորից է գործարկվում և ամեն ինչ անցնում է։
- Փոփոխությունը միաձուլվում է։ Խողովակաշարը այն տեղակայում է նախագծային միջավայր, որտեղ դուք փորձում եք փորձնական ամրագրում։
- Հաստատում եք, և այն տեղակայվում է արտադրությունում։
Առանց խողովակաշարի, 3-րդ քայլում եղած սխալը տեղի կունենար ձեր հաճախորդների դրամապանակներում։
Հիմնական տերմիններ
| Տերմին | Նշանակություն |
|---|---|
| Խողովակաշար (pipeline) | Ավտոմատ քայլերի հաջորդականություն, որ գործարկվում է յուրաքանչյուր փոփոխության վրա։ |
| Կառուցում (build) | Նախնական կոդը վերածել գործարկվող բանի։ |
| Ավտոմատ թեստ | Կոդ, որ ստուգում է, թե մյուս կոդն ինչ է անում, ինչպես պետք է։ |
| Pull request (PR) | Առաջարկված փոփոխություն, որ ուրիշները (և խողովակաշարը) վերանայում են, նախքան միաձուլելը։ Տե՛ս ինչ է GitHub-ը։ |
| Ճյուղ (branch) | Փոփոխությունների առանձին գիծ, որպեսզի անավարտ աշխատանքը չազդի հիմնական կոդի վրա։ |
| Նախագծային միջավայր (staging) | Ձեր հավելվածի մասնավոր պատճենը, որ արտադրությունը արտապատկերում է, որպեսզի փոփոխությունները ստուգվեն մինչև օգտատերերին տեսնելը։ |
| Արտադրություն (production) | Կենդանի հավելվածը, որ օգտագործում են ձեր օգտատերերը։ |
| Վերադարձ (rollback) | Վերադառնալ նախորդ աշխատող տարբերակին, երբ թողարկումը սխալ է ընթանում։ |
| Կանաչ / կարմիր build | Խողովակաշարի գործարկում, որ անցավ / ձախողվեց։ |
Տարածված սխալ պատկերացումներ
- «CI/CD-ը նշանակում է, որ իմ հավելվածը փորձարկված է»։ Խողովակաշարը գործարկում է միայն այն թեստերը, որ ունեք։ Եթե թեստեր չկան, CI-ն ապացուցում է միայն, որ հավելվածը կառուցվում է, ոչ ավելին։ Խնդրեք AI-ին գրել թեստեր այն հոսքերի համար, որոնք ամենաշատն են կարևոր։
- «CI/CD-ը միայն մեծ ընկերությունների համար է»։ Հոստինգային գործիքները, ինչպիսին GitHub Actions-ն է, կարճ կոնֆիգուրացիայի ֆայլով են կարգավորվում, և փոքր թիմերը դրանք շատ են օգտագործում։ Ծանր աշխատանքը թեստերն են, ոչ գործիքները։
- «Ավտոմատ տեղակայումը նշանակում է, որ ոչ ոք ոչինչ չի ստուգում»։ Լավ խողովակաշարերը ավելացնում են ստուգումներ, ոչ թե հեռացնում են դրանք։ Շատ թիմեր պահում են մարդկային հաստատման քայլ արտադրությունից առաջ։
- «Եթե խողովակաշարը կանաչ է, հավելվածը աշխատում է»։ Դա նշանակում է, որ ավտոմատ ստուգումներն անցան։ Դեռ պետք է ինքներդ փորձեք փոփոխությունը, ցանկալիորեն նախադիտման կամ նախագծային միջավայրում։
- «CI/CD-ը փոխարինում է կրկնօրինակներին»։ Չի փոխարինում։ Տվյալների բազայի վատ միգրացիան, որ անցնում է թեստերը, դեռ կարող է վնասել իրական տվյալները։ Պահեք կրկնօրինակները և վերադարձի եղանակ։
Ինչ հարցնել ձեր AI կառուցիչից
- «Գրիր ավտոմատ թեստեր գրանցման, մուտքի և դրամարկղի համար, և ցույց տուր, թե ինչպես գործարկել դրանք։»
- «Կարգավորիր GitHub Actions աշխատանքային հոսք, որ տեղադրում է կախվածությունները, կառուցում հավելվածը և գործարկում թեստերը յուրաքանչյուր pull request-ի վրա։»
- «Ավելացրու տիպերի ստուգում և լինտեր խողովակաշարին և դարձրու, որ ձախողվի սխալների դեպքում։»
- «Պարզ լեզվով բացատրիր, թե խողովակաշարի յուրաքանչյուր քայլ ինչ է անում։»
- «Ի՞նչ է լինում, եթե տեղակայումը ձախողվի կեսից։ Ինչպե՞ս վերադառնալ։»
- «Ստուգիր, որ գաղտնիքները չեն կոդավորված պահոցում և չեն տպվում խողովակաշարի մատյաններում։»
Եթե ձեր հավելվածն օգտագործում է API բանալիներ, խողովակաշարին էլ են դրանք պետք՝ պահված որպես կոդավորված գաղտնիքներ CI գործիքում, երբեք կոնֆիգուրացիայի ֆայլում։ Տե՛ս միջավայրի փոփոխականները և գաղտնիքները։
CI/CD-ն և Mythex-ը
Mythex-ը ձեզ համար CI խողովակաշար չի գործարկում, բայց իր ձևով լուծում է նույն կարիքներից մի քանիսը․
- Ստուգակետեր (checkpoints)։ Յուրաքանչյուր հաջող գործակալի հերթափոխից հետո Mythex-ը պահում է git ստուգակետ, և Վերադառնալ այս կետին տարբերակը նախագիծը վերադարձնում է, եթե փոփոխությունը սխալ է ընթացել։ Տե՛ս Չաթ։
- App Testing։ Գրեք
/test, և գործակալը սեղմում է ձեր կենդանի նախադիտման միջով՝ որպես օգտատեր, և հաղորդում է կոտրված հոսքերի մասին․ օգտակար է յուրաքանչյուր հրապարակումից առաջ։ Տե՛ս App Testing։ - Հրապարակումը գիտակցված քայլ է։ Փոփոխությունները նախ հայտնվում են մասնավոր նախադիտման մեջ․ ձեր հրապարակային հավելվածը թարմանում է միայն երբ նորից հրապարակում եք։ Սա ավելի մոտ է անընդհատ մատուցմանը, քան անընդհատ տեղակայմանը։
- GitHub համաժամացում (Pro)։ Համաժամացրեք նախագիծը GitHub պահոցի հետ, և կարող եք ավելացնել ձեր սեփական GitHub Actions աշխատանքային հոսքերը՝ թեստեր գործարկելու յուրաքանչյուր push-ի վրա։ Տե՛ս GitHub-ը և արտահանումը։
Արտադրությունում հավելվածը գործարկելուց առաջ ձեռքով փորձարկելու ստուգացանկի համար տե՛ս ինչպես փորձարկել ձեր հավելվածը գործարկելուց առաջ, իսկ տարբերակների կառավարման հետ աշխատելու համար՝ ինչպես օգտագործել Git-ը AI-ով կառուցված հավելվածի հետ։
Հարցեր
Ինչ է նշանակում CI/CD։
CI-ը նշանակում է անընդհատ ինտեգրում (continuous integration)․ յուրաքանչյուր կոդի փոփոխություն հաճախ միաձուլվում և ավտոմատ կառուցվում ու ստուգվում է։ CD-ն նշանակում է անընդհատ մատուցում (continuous delivery) կամ անընդհատ տեղակայում (continuous deployment)․ փորձարկումները անցած փոփոխությունները ավտոմատ պատրաստվում են թողարկման (delivery) կամ թողարկվում են օգտատերերին առանց ձեռքով քայլի (deployment)։
Ո՞րն է տարբերությունը անընդհատ մատուցման և անընդհատ տեղակայման միջև։
Անընդհատ մատուցման դեպքում յուրաքանչյուր փոփոխություն, որ անցնում է խողովակաշարը, պատրաստ է թողարկման, բայց մարդը դեռ որոշում է, թե երբ այն ուղարկել կենդանի։ Անընդհատ տեղակայման դեպքում յուրաքանչյուր անցած փոփոխություն ավտոմատ գնում է կենդանի, առանց մարդկային հաստատման քայլի։
Արդյո՞ք ինձ CI/CD է պետք AI-ով կառուցված փոքր հավելվածի համար։
Առաջին օրից՝ ոչ։ Մի քանի օգտատեր ունեցող փոքր հավելվածը կարող է բավարարվել նախադիտման մեջ փորձարկմամբ և ձեռքով հրապարակմամբ։ CD-ն արդարանում է, երբ կոդը փոխում են մի քանի մարդ, երբ իրական հաճախորդները կախված են հավելվածից կամ երբ կոտրում եք այն, ինչ նախկինում աշխատում էր։
Ինչ գործիքներ են օգտագործվում CI/CD-ի համար։
Տարածված են GitHub Actions-ը, GitLab CI/CD-ն, CircleCI-ն և Jenkins-ը, ինչպես նաև հոստինգային հարթակների ներկառուցված տեղակայման խողովակաշարերը։ Բոլորն էլ նույն հիմնական աշխատանքն են անում․ փոփոխության դեպքում ավտոմատ կատարում են քայլերի ցանկ։