რა არის CI/CD? უწყვეტი ინტეგრაცია და მიწოდება მარტივად ახსნილი
CI/CD არის პროგრამული უზრუნველყოფის გაგზავნის გზა, სადაც კოდის ყოველი ცვლილება ავტომატურად აგდება, იტესტება და — თუ გაივლის — ემზადება გამოშვებისთვის ან გამოიშვება. CI (continuous integration) ნიშნავს, რომ ცვლილებები ხშირად ერთიანდება და ყოველ ჯერზე ავტომატური ტესტებით მოწმდება. CD (continuous delivery ან deployment) ნიშნავს, რომ გამავალი ცვლილებები იფუთება და მომხმარებლებისკენ გზავნება მცირე ან საერთოდ ხელით სამუშაოს გარეშე.
მიზანი მარტივია: შეცდომები წუთებში დაიჭირო, ისინი რომ გაქრეს, არა კვირების შემდეგ, როცა მომხმარებელი იპოვის.
რატომ არის CI/CD მნიშვნელოვანი, როცა AI-ით აშენებ
AI ბილდერები კოდის ცვლილებებს სწრაფად აკეთებენ. ერთი მოთხოვნა შეიძლება ათ ფაილს შეეხოს. ეს სიჩქარე კარგია, სანამ checkout გვერდზე ცვლილება ჩუმად არ გატეხავს login გვერდს და არავინ არ შეამჩნევს, სანამ მომხმარებელი ელფოსტით არ მოგწერს.
CI/CD სწორედ ამ შემთხვევისთვის არის უსაფრთხოების ბადე. იმის ნაცვლად, რომ ენდო, რომ ყოველი ცვლილება კარგია, პაიფლაინი ყოველ ჯერზე ერთსა და იმავე შემოწმებებს ატარებს:
- ბილდავს თუ არა აპი შეცდომების გარეშე?
- გადის თუ არა ავტომატური ტესტები?
- ემორჩილება თუ არა კოდი პროექტის წესებს (ტიპები, ფორმატირება, უსაფრთხოების შემოწმებები)?
თუ რომელიმე შემოწმება ჩავარდება, ცვლილება მომხმარებლებამდე არ მიდის. რაც უფრო სწრაფად იცვლება შენი კოდი, მით უფრო ღირებულია შემოწმება, რომელიც არ იღლება და არ ტოვებს საფეხურს.
ყოველდღიური ანალოგია
წარმოიდგინე საფუარის მაღაზია, რომელიც ყოველ დილით ყიდის პურს მაღაზიებს.
- CI/CD-ის გარეშე თითოეული მცხობელი თავისთვის ცვლის რეცეპტს კვირის განმავლობაში, შემდეგ პარასკევს ღამით ყველა ცვლილება ერთად ერთვება და იმედი აქვთ, რომ პური მაინც აიზრდება. როცა არ იზრდება, არავინ იცის, ვისმა ცვლილებამ გამოიწვია.
- CI-ით ყოველი პატარა რეცეპტის ცვლილება მაშინვე იცხობება საცდელ პურად და მოწმდება — გემო, წონა, ფორმა. ცუდი ცვლილება იმავე დღეს ჩანს და ზუსტად იცი, რომელი იყო.
- CD-ით კონტროლს გავლილი პურები პირდაპირ მიწოდების მანქანაზე მიდის, შეფუთული და ერთნაირად დანიშნული, იმის ნაცვლად, რომ ვიღაც დილის 5 საათზე ხელით აწყობდეს ყუთებს.
შემოწმება მცხობლებს არ აუმჯობესებს. ის მათ შეცდომებს იაფს ხდის.
როგორ მუშაობს CI/CD პაიფლაინი
პაიფლაინი არის საფეხურების სია, რომელსაც CI/CD სერვისი ავტომატურად უშვებს, როცა რაღაც ხდება — ჩვეულებრივ, როცა ვინმე კოდს GitHub-ის მსგავს რეპოზიტორიში ტვირთავს. ტიპური პაიფლაინი ასე გამოიყურება:
| საფეხური | რა ხდება | რას იჭერს |
|---|---|---|
| 1. ტრიგერი | კოდი იტვირთება ან იხსნება pull request | — |
| 2. ინსტალაცია | ახალი მანქანა ჩამოტვირთავს კოდსა და მის დამოკიდებულებებს | გატეხილ ან დაკარგულ პაკეტებს |
| 3. აგება (build) | აპი კომპილირდება ან იკვრება | სინტაქსისა და ტიპების შეცდომებს, გატეხილ იმპორტებს |
| 4. ტესტირება | ავტომატური ტესტები მუშაობს | ფუნქციებს, რომლებიც აღარ მუშაობს |
| 5. შემოწმებები | ლინტინგი, ფორმატირება, უსაფრთხოების სკანირება | სტილის პრობლემებს, ცნობილ მოწყვლად პაკეტებს, გაჟონილ გასაღებებს |
| 6. დეპლოი სტეიჯინგზე | აპი მიდის შენი პროდაქშენის სატესტო ასლზე | პრობლემებს, რომლებიც მხოლოდ რეალურ გარემოში ჩანს |
| 7. დეპლოი პროდაქშენზე | აპი ცოცხალი ხდება — ავტომატურად ან დამტკიცების შემდეგ | — |
ყოველი საფეხური ცარიელ მანქანაზე მუშაობს და არა ვინმეს ლეპტოპზე, ასე რომ „ჩემს კომპიუტერზე მუშაობს“ აღარ არის საბაბი. თუ საფეხური ჩავარდება, პაიფლაინი ჩერდება და ცვლილების ავტორს ატყობინებს.
საფეხურები განსაზღვრულია კონფიგურაციის ფაილში, რომელიც კოდთან ერთად ცხოვრობს. მაგალითად GitHub Actions-ში ეს არის YAML ფაილი რეპოზიტორიის .github/workflows საქაღალდეში.
Continuous delivery vs continuous deployment
„CD“ ორაზროვანია, და ხალხი ორივე მნიშვნელობით იყენებს:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| ტესტები ავტომატურად მუშაობს | დიახ | დიახ |
| გამოშვება ავტომატურად იფუთება | დიახ | დიახ |
| ავტომატურად ცოცხალი ხდება | არა — ადამიანი აჭერს „გამოშვებას“ | დიახ — ყოველი გამავალი ცვლილება ვრცელდება |
| კარგია | უმეტესი პატარა გუნდისთვის, აპებისთვის ფულადი მომხმარებლებით | გუნდებისთვის ძლიერი ტესტური დაფარვით და მონიტორინგით |
Continuous deployment კარგად მუშაობს მხოლოდ მაშინ, როცა ტესტები კარგია. თუ შენი ტესტები checkout-ს არ ფარავს, continuous deployment ხალისით გაუშვებს გატეხილ checkout-საც.
სამუშაო მაგალითი: დაჯავშნის აპი პაიფლაინით
ვთქვათ, გაქვს სალონის დაჯავშნის აპი, და მისი კოდი 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 ბილდერს
- „დაწერე ავტომატური ტესტები რეგისტრაციის, შესვლისა და checkout-ისთვის და მაჩვენე, როგორ გავუშვა ისინი.“
- „დააყენე GitHub Actions workflow, რომელიც დააინსტალირებს დამოკიდებულებებს, ააგებს აპს და გაუშვებს ტესტებს ყოველ pull request-ზე.“
- „დაამატე ტიპების შემოწმება და ლინტერი პაიფლაინში და გახადე, რომ შეცდომებზე ჩავარდეს.“
- „ახსენი მარტივი ენით, რას აკეთებს პაიფლაინის თითოეული საფეხური.“
- „რა ხდება, თუ დეპლოი შუა გზაზე ჩავარდება? როგორ დავაბრუნო წინა ვერსია?“
- „შეამოწმე, რომ არცერთი საიდუმლო არ არის მყარად კოდირებული რეპოზიტორიაში ან დაბეჭდილი პაიფლაინის ლოგებში.“
თუ შენი აპი API გასაღებებს იყენებს, პაიფლაინსაც დასჭირდება ისინი — დაშიფრული საიდუმლოების სახით CI ინსტრუმენტში შენახული, არასდროს კონფიგურაციის ფაილში. იხილე გარემოს ცვლადები და საიდუმლოები.
CI/CD და Mythex
Mythex CI პაიფლაინს შენთვის არ უშვებს, მაგრამ რამდენიმე იგივე საჭიროებას საკუთარი გზით ფარავს:
- Checkpoint-ები. აგენტის ყოველი წარმატებული ნაბიჯის შემდეგ Mythex ინახავს git checkpoint-ს, და Revert to this point აბრუნებს პროექტს უკან, თუ ცვლილება ცუდად წავიდა. იხილე Chat.
- App Testing. ჩაწერე
/testდა აგენტი დააკლიკებს შენს ცოცხალ პრევიუში როგორც მომხმარებელი და შეატყობინებს გატეხილ ნაკადებს — სასარგებლოა ყოველ გამოქვეყნებამდე. იხილე App Testing. - გამოქვეყნება შეგნებული ნაბიჯია. ცვლილებები ჯერ კერძო პრევიუში ჩნდება; შენი საჯარო აპი მხოლოდ მაშინ განახლდება, როცა ხელახლა გამოაქვეყნებ — უფრო continuous delivery-ს ჰგავს, ვიდრე continuous deployment-ს.
- GitHub სინქრონიზაცია (Pro). სინქრონიზაციის შემდეგ პროექტს GitHub რეპოზიტორიასთან აკავშირებ და შეგიძლია დაამატო შენი GitHub Actions workflow-ები, რომლებიც ყოველ push-ზე ტესტებს უშვებენ. იხილე GitHub და ექსპორტი.
იმ შემოწმებების ჩამონათვალისთვის, რაც ხელით უნდა გაიაროთ ცოცხლად გაშვებამდე, იხილე როგორ გავტესტოთ შენი აპი გაშვებამდე, ხოლო ვერსიების კონტროლთან მუშაობისთვის როგორ გამოვიყენოთ Git AI-ით აშენებულ აპთან.
კითხვები
რას ნიშნავს CI/CD?
CI ნიშნავს continuous integration-ს: კოდის ყოველი ცვლილება ხშირად ერთიანდება და ავტომატურად აგდება და მოწმდება. CD ნიშნავს continuous delivery-ს ან continuous deployment-ს: ტესტებს გავლილი ცვლილებები ავტომატურად მზადდება გამოშვებისთვის (delivery) ან მომხმარებლებამდე მიდის ხელით ნაბიჯის გარეშე (deployment).
რა განსხვავებაა continuous delivery-სა და continuous deployment-ს შორის?
continuous delivery-ის დროს ყოველი ცვლილება, რომელიც პაიფლაინს გაივლის, გამოსაშვებად მზადაა, მაგრამ ადამიანი მაინც წყვეტს, როდის გავუშვათ ის. continuous deployment-ის დროს ყოველი გამავალი ცვლილება ავტომატურად მიდის ცოცხალ სისტემაში, ადამიანის დამტკიცების საფეხურის გარეშე.
მჭირდება CI/CD პატარა აპისთვის, რომელიც AI-ით არის აშენებული?
პირველ დღეს არა. პატარა აპს რამდენიმე მომხმარებლით შეუძლია მუშაობა პრევიუში ტესტირებითა და ხელით გამოქვეყნებით. CI/CD თავს იმართლებს მაშინ, როცა კოდს რამდენიმე ადამიანი ცვლის, როცა რეალური მომხმარებლები აპზე არიან დამოკიდებულნი, ან როცა რაღაც, რაც მუშაობდა, კვლავ იფუჭება.
რომელი ინსტრუმენტები გამოიყენება CI/CD-სთვის?
გავრცელებულია GitHub Actions, GitLab CI/CD, CircleCI და Jenkins, ასევე ჰოსტინგ პლატფორმების ჩაშენებული დეპლოის პაიფლაინები. ყველა ერთსა და იმავე ძირითად საქმეს აკეთებს: ავტომატურად ატარებს საფეხურების სიას, როცა კოდი იცვლება.