ისწავლეთ Git ბრძანებები, მაგრამ გსურთ წარმოიდგინოთ, როგორ მუშაობს უწყვეტი ინტეგრაცია (CI) სინამდვილეში? ან იქნებ გსურთ თქვენი ყოველდღიური საქმიანობის ოპტიმიზაცია? ეს კურსი მოგცემთ პრაქტიკულ უნარებს GitHub საცავების გამოყენებით უწყვეტი ინტეგრაციისთვის. ეს კურსი არ არის გამიზნული იყოს ოსტატი, რომელზეც შეგიძლიათ უბრალოდ დააწკაპუნოთ; პირიქით, თქვენ შეასრულებთ იგივე მოქმედებებს, რასაც ადამიანები რეალურად აკეთებენ სამუშაოზე, ისევე როგორც აკეთებენ ამას. მე აგიხსნით თეორიას, როდესაც თქვენ გაივლით ჩართულ ნაბიჯებს.

Რას ვაკეთებთ?

პროგრესთან ერთად, ჩვენ თანდათან შევქმნით ტიპიური CI ნაბიჯების ჩამონათვალს, რაც ამ სიის დამახსოვრების შესანიშნავი გზაა. სხვა სიტყვებით რომ ვთქვათ, ჩვენ შევქმნით იმ ქმედებების ჩამონათვალს, რომლებსაც დეველოპერები ახორციელებენ უწყვეტი ინტეგრაციის, უწყვეტი ინტეგრაციის დროს. ჩვენ ასევე გამოვიყენებთ ტესტების მარტივ კომპლექტს ჩვენი CI პროცესის რეალურთან მიახლოებისთვის.

ეს GIF სქემატურად აჩვენებს ვალდებულებებს თქვენს საცავში, კურსის გავლისას. როგორც ხედავთ, აქ არაფერია რთული და მხოლოდ ყველაზე საჭირო.

თქვენ გაივლით შემდეგ სტანდარტულ CI სცენარებს:

• მუშაობა ფუნქციაზე;
• ხარისხის უზრუნველსაყოფად ავტომატური ტესტების გამოყენება;
• პრიორიტეტული ამოცანის შესრულება;
• განშტოებების შერწყმისას კონფლიქტის მოგვარება (შერწყმის კონფლიქტი);
• წარმოების გარემოში წარმოიქმნება შეცდომა.

რას ისწავლი?

თქვენ შეძლებთ უპასუხოთ შემდეგ კითხვებს:

• რა არის უწყვეტი ინტეგრაცია (CI)?
• რა ტიპის ავტომატიზირებული ტესტები გამოიყენება CI-ში და რა მოქმედებების საპასუხოდ ხდება ისინი?
• რა არის მოზიდვის მოთხოვნები და როდის არის ისინი საჭირო?
• რა არის ტესტზე ორიენტირებული განვითარება (TDD) და როგორ უკავშირდება ის CI-ს?
• უნდა გავაერთიანო თუ შევცვალო ცვლილებები?
• დააბრუნოს თუ გაასწოროს შემდეგ ვერსიაში?

თავიდან ყველგან ვთარგმნიდი რაღაცეებს, როგორიცაა "მოზიდვის მოთხოვნები", მაგრამ შედეგად გადავწყვიტე ფრაზების დაბრუნება ინგლისურად ზოგიერთ ადგილას, რათა შემემცირებინა ტექსტის სიგიჟის ხარისხი. მე ხანდახან გამოვიყენებ „პროგრამისტ სურჟიკს“, როგორც მშვენიერი ზმნა „ასრულებენ“, სადაც ადამიანები რეალურად იყენებენ მას სამსახურში.

რა არის უწყვეტი ინტეგრაცია?

უწყვეტი ინტეგრაცია, ან CI, არის ტექნიკური პრაქტიკა, რომლის დროსაც გუნდის თითოეული წევრი აერთიანებს თავის კოდს საერთო საცავში დღეში ერთხელ მაინც და მიღებული კოდი მაინც უნდა იყოს აგებული შეცდომების გარეშე.

ამ ტერმინთან დაკავშირებით უთანხმოებაა

კამათის წერტილი არის ინტეგრაციის სიხშირე. ზოგიერთი ამტკიცებს, რომ კოდის შერწყმა მხოლოდ დღეში ერთხელ არ არის საკმარისი იმისათვის, რომ რეალურად მოხდეს უწყვეტი ინტეგრაცია. მაგალითი არის გუნდი, სადაც ყველა იღებს ახალ კოდს დილით და აერთიანებს მას ერთხელ საღამოს. მიუხედავად იმისა, რომ ეს არის გონივრული წინააღმდეგობა, ზოგადად მიღებულია, რომ დღეში ერთხელ განმარტება საკმაოდ პრაქტიკული, სპეციფიკური და შესაფერისია სხვადასხვა ზომის გუნდებისთვის.

კიდევ ერთი წინააღმდეგობა არის ის, რომ C++ აღარ არის ერთადერთი ენა, რომელიც გამოიყენება განვითარებაში და უბრალოდ, უშეცდომოდ შეკრების მოთხოვნა, როგორც დადასტურების საშუალება, სუსტია. ტესტების ზოგიერთი ნაკრები (მაგალითად, ერთეული ტესტები შესრულებული ადგილობრივად) ასევე წარმატებით უნდა დასრულდეს. ამ მომენტში, საზოგადოება მიდის იმისკენ, რომ ეს მოთხოვნა გახდეს და მომავალში "build + unit tests" ალბათ ჩვეულებრივი პრაქტიკა გახდება, თუ ეს უკვე არ არის.

უწყვეტი ინტეგრაცია განსხვავდება უწყვეტი მიწოდება (უწყვეტი მიწოდება, CD) იმით, რომ არ საჭიროებს გამოშვების კანდიდატს ყოველი ინტეგრაციის ციკლის შემდეგ.

საფეხურების სია, რომლებსაც გამოვიყენებთ კურსის განმავლობაში

1. შეიყვანეთ უახლესი კოდი. შექმენით ფილიალი master. Მუშაობის დაწყება.
2. შექმენით ვალდებულებები თქვენს ახალ ფილიალზე. ააშენეთ და გამოსცადეთ ადგილობრივად. საშვი? გადადით შემდეგ ეტაპზე. მარცხი? შეასწორეთ შეცდომები ან ტესტები და სცადეთ ხელახლა.
3. გადადით თქვენს დისტანციურ საცავში ან დისტანციურ ფილიალში.
4. შექმენით გაყვანის მოთხოვნა. განიხილეთ ცვლილებები, დაამატეთ მეტი ვალდებულებები დისკუსიის გაგრძელებისას. გაიარეთ ტესტები ფუნქციების ფილიალში.
5. შერწყმა/გადანერგვა ოსტატისგან. გაიარეთ ტესტები შერწყმის შედეგზე.
6. განლაგება ფუნქციური ფილიალიდან წარმოებამდე.
7. თუ ყველაფერი კარგია წარმოებაში გარკვეული პერიოდის განმავლობაში, შეაერთეთ ცვლილებები მასტერში.

️ მომზადება

დარწმუნდით, რომ გაქვთ სწორი პროგრამული უზრუნველყოფა

ამ კურსის გასავლელად დაგჭირდებათ Node.js и Git კლიენტი.

თქვენ შეგიძლიათ გამოიყენოთ ნებისმიერი Git კლიენტი, მაგრამ მე მივცემ მხოლოდ ბრძანებებს ბრძანების ხაზისთვის.

დარწმუნდით, რომ დაინსტალირებული გაქვთ Git კლიენტი, რომელიც მხარს უჭერს ბრძანების ხაზს

თუ ჯერ არ გაქვთ Git კლიენტი, რომელიც მხარს უჭერს ბრძანების ხაზს, შეგიძლიათ იპოვოთ ინსტალაციის ინსტრუქციები აქ.

მოამზადეთ საცავი

თქვენ უნდა შექმნათ პირადი ასლი (ჩანგალი) შაბლონის საცავი კურსის კოდით GitHub-ზე. მოდით შევთანხმდეთ დავარქვათ ეს პირადი ასლი კურსის საცავი.

Შესრულებულია? თუ თქვენ არ შეგიცვლიათ ნაგულისხმევი პარამეტრები, თქვენი კურსის საცავი სავარაუდოდ გამოიძახება continuous-integration-team-scenarios-students, ის მდებარეობს თქვენს GitHub ანგარიშში და URL ასე გამოიყურება

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

უბრალოდ ამ მისამართს დავურეკავ <URL репозитория>.

კუთხის ფრჩხილები მოსწონს <тут> ეს ნიშნავს, რომ თქვენ უნდა შეცვალოთ ასეთი გამონათქვამი შესაბამისი მნიშვნელობით.

Დარწმუნდი, რომ GitHub მოქმედებები შედის ამ კურსის საცავისთვის. თუ ისინი არ არის ჩართული, გთხოვთ, ჩართოთ ისინი გვერდის შუაში არსებულ დიდ ღილაკზე დაწკაპუნებით, რომელზეც შეგიძლიათ მოხვდეთ მოქმედებების დაწკაპუნებით GitHub ინტერფეისში.

თქვენ ვერ შეძლებთ კურსის დასრულებას ჩემი ინსტრუქციის შესაბამისად, თუ GitHub Actions არ არის ჩართული.

თქვენ ყოველთვის შეგიძლიათ გამოიყენოთ GitHub-ის უნარი, გამოაქვეყნოს Markdown, რათა ნახოთ სიის მიმდინარე მდგომარეობა, რომელსაც აქ ვქმნით.

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

პასუხების შესახებ

მიუხედავად იმისა, რომ ამ კურსის დასრულების საუკეთესო გზაა ამის გაკეთება საკუთარ თავს, შესაძლოა გარკვეული სირთულეები შეგექმნათ.

თუ გრძნობთ, რომ არ გესმით რა უნდა გააკეთოთ და არ შეგიძლიათ გააგრძელოთ, შეგიძლიათ გადახედოთ თემას solution, რომელიც თქვენს საწყის საცავშია.
გთხოვთ, არ გაერთიანდეთ solution в master კურსის განმავლობაში. თქვენ შეგიძლიათ გამოიყენოთ ეს ფილიალი იმის გასარკვევად, თუ რა უნდა გააკეთოთ, ან შეადაროთ თქვენი კოდი ავტორის, ყველა იმ შესაძლებლობის გამოყენებით, რომელსაც Git გვაძლევს. თუ მთლიანად დაიკარგეთ, შეგიძლიათ მთლიანად შეცვალოთ თქვენი ფილიალი master ტოტზე solution და შემდეგ გადააყენეთ თქვენი სამუშაო დირექტორია თქვენთვის საჭირო კურსის საფეხურზე.

გამოიყენეთ ეს მხოლოდ იმ შემთხვევაში, თუ ნამდვილად გჭირდებათ

ჩააბარეთ თქვენი კოდი

git add .
git commit -m "Backing up my work"

ეს ბრძანებები

• გადარქმევა master в master-backup;
• გადარქმევა solution в master;
• გადახდა ახალ ფილიალში master და გადაწერეთ სამუშაო დირექტორიას შინაარსი;
• შექმენით "გადაწყვეტის" ფილიალი "მასტერისგან" (რომელიც ადრე იყო "გადაწყვეტა") იმ შემთხვევაში, თუ მომავალში დაგჭირდებათ "გადაწყვეტის" ფილიალი.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

ამ ნაბიჯების შემდეგ შეგიძლიათ გამოიყენოთ git log master იმის გასარკვევად, რომელი ვალდებულება გჭირდებათ.
თქვენ შეგიძლიათ გადააყენოთ თქვენი სამუშაო დირექტორია ამ commit-ზე შემდეგნაირად:

git reset --hard <the SHA you need>

თუ შედეგით კმაყოფილი ხართ, რაღაც მომენტში მოგიწევთ საცავის თქვენი ვერსიის გამოქვეყნება დისტანციურ საცავში. არ დაგავიწყდეთ ცალსახად მიუთითოთ დისტანციური ფილიალი, როდესაც ამას აკეთებთ.

git push --force origin master

გთხოვთ გაითვალისწინოთ, რომ ჩვენ ვიყენებთ git push --force. ნაკლებად სავარაუდოა, რომ ამის გაკეთება ძალიან ხშირად მოგინდეთ, მაგრამ ჩვენ გვაქვს ძალიან კონკრეტული სცენარი აქ ერთი საცავის მომხმარებლით, რომელსაც, გარდა ამისა, ესმის რას აკეთებს.

მუშაობის დაწყება

დავიწყოთ ჩვენი CI ნაბიჯების სიის შედგენა. ჩვეულებრივ, თქვენ იწყებდით ამ ნაბიჯს დისტანციური საცავიდან კოდის უახლესი ვერსიის შემოწმებით, მაგრამ ჩვენ ჯერ არ გვაქვს ლოკალური საცავი, ამიტომ ჩვენ მას კლონირებთ დისტანციურიდან.

️ ამოცანა: განაახლეთ ლოკალური საცავი, შექმენით ფილიალი master, მუშაობის დაწყება

1. კურსის საცავიდან კლონირება <URL репозитория>.
2. გარბოდა npm install კურსის საცავის დირექტორიაში; ჩვენ გვჭირდება Jest-ის დასაყენებლად, რომელსაც ვიყენებთ ტესტების გასაშვებად.
3. შექმენით ფილიალი და დაასახელეთ feature. გადაერთეთ ამ თემაში.

4. დაამატეთ ტესტის კოდი ci.test.js კომენტარებს შორის, რომლებიც ამას მთხოვენ.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. დაამატეთ ტექსტი ფაილში პირველი 4 ნაბიჯით ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   ბრძანებები

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

შექმენით ვალდებულებები ახალ ფილიალზე, შექმენით და გამოსცადეთ ადგილობრივად

ჩვენ ვაპირებთ დავაყენოთ ტესტები ჩადენამდე გასაშვებად და შემდეგ ჩავწეროთ კოდი.

ტიპიური სცენარები, როდესაც ტესტები ავტომატურად მუშაობს

• ადგილობრივად:
  • მუდმივად ან შესაბამისი კოდის ცვლილებების საპასუხოდ;
  • შენახვაზე (ინტერპრეტაციული ან JIT-შედგენილი ენებისთვის);
  • აწყობის დროს (როდესაც საჭიროა შედგენა);
  • ჩადენის შესახებ;
  • საზიარო საცავში გამოქვეყნებისას.

• build სერვერზე ან build გარემოზე:
  • როდესაც კოდი გამოქვეყნებულია პირად ფილიალში/საცავში.
  • ამ თემაში კოდის ტესტირება მიმდინარეობს.
  • შერწყმის პოტენციური შედეგი შემოწმებულია (ჩვეულებრივ master).
  • როგორც უწყვეტი ინტეგრაციის ეტაპი/უწყვეტი მიწოდების მილსადენი

როგორც წესი, რაც უფრო სწრაფად მუშაობს სატესტო კომპლექტი, მით უფრო ხშირად შეძლებთ მის გაშვებას. ტიპიური ეტაპის განაწილება შეიძლება ასე გამოიყურებოდეს.

• ერთეულის სწრაფი ტესტები - აშენების დროს, CI მილსადენში
• ნელი ერთეულის ტესტები, სწრაფი კომპონენტის და ინტეგრაციის ტესტები - commit-ზე, CI მილსადენში
• ნელი კომპონენტისა და ინტეგრაციის ტესტები - CI მილსადენში
• უსაფრთხოების ტესტირება, დატვირთვის ტესტირება და სხვა შრომატევადი ან ძვირადღირებული ტესტები - CI/CD მილსადენებში, მაგრამ მხოლოდ მშენებლობის გარკვეულ რეჟიმებში/ეტაპებზე/მილსადენებში, მაგალითად, გათავისუფლების კანდიდატის მომზადებისას ან ხელით მუშაობისას.

️ დავალება

მე გთავაზობთ ტესტების ხელით გაშვებას ჯერ ბრძანების გამოყენებით npm test. ამის შემდეგ, მოდით დავამატოთ git hook ჩვენი ტესტების ჩასატარებლად. არის ერთი დაჭერა: Git hook არ განიხილება საცავის ნაწილად და, შესაბამისად, შეუძლებელია GitHub-ის კლონირება დანარჩენი კურსის მასალებთან ერთად. Hook-ის დასაყენებლად საჭიროა გაშვება install_hook.sh ან დააკოპირეთ ფაილი repo/hooks/pre-commit ადგილობრივ დირექტორიაში .git/hooks/.
როდესაც თქვენ ჩაიდენთ ვალდებულებას, ნახავთ, რომ ტესტები გაშვებულია და ისინი ამოწმებენ, არის თუ არა გარკვეული საკვანძო სიტყვები სიაში.

1. შეასრულეთ ტესტები ხელით ბრძანების გაშვებით npm test თქვენი კურსის საცავის საქაღალდეში. შეამოწმეთ, რომ ტესტები დასრულებულია.
2. დააყენეთ commit hook (pre-commit hook) გაშვებით install_hook.sh.
3. განახორციელეთ ცვლილებები თქვენს ადგილობრივ საცავში.
4. დარწმუნდით, რომ ტესტები ჩატარდება ჩადენამდე.

თქვენი საცავი ასე უნდა გამოიყურებოდეს ამ ნაბიჯების შესრულების შემდეგ.

ბრძანებები

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

გამოაქვეყნეთ კოდი დისტანციურ საცავში ან დისტანციურ ფილიალში

როგორც კი ისინი დაასრულებენ ადგილობრივ მუშაობას, დეველოპერები, როგორც წესი, თავიანთ კოდს საჯაროდ აწვდიან, რათა ის საბოლოოდ იყოს ინტეგრირებული საზოგადოებასთან. GitHub-ით, ეს ჩვეულებრივ მიიღწევა ნამუშევრის გამოქვეყნებით ან საცავის პირად ასლზე (პერსონალური ჩანგალი) ან პირად ფილიალში.

• ჩანგლებით, დეველოპერი კლონირებს დისტანციურ საზიარო საცავს, ქმნის მის პირად დისტანციურ ასლს, რომელიც ასევე ცნობილია როგორც ჩანგალი. შემდეგ ის კლონირებს ამ პერსონალურ საცავს ლოკალურად სამუშაოდ. როდესაც სამუშაო დასრულებულია და ვალდებულებები შესრულებულია, ის უბიძგებს მათ თავის ჩანგალში, სადაც ისინი ხელმისაწვდომია სხვებისთვის და შეიძლება ინტეგრირებული იყოს საერთო საცავში. ეს მიდგომა ჩვეულებრივ გამოიყენება ღია კოდის პროექტებში GitHub-ზე. ის ასევე გამოიყენება ჩემს მოწინავე კურსში [Team Work and CI with Git] (http://devops.redpill.solutions/).
• კიდევ ერთი მიდგომაა გამოიყენოთ მხოლოდ ერთი დისტანციური საცავი და მხოლოდ ფილიალის დათვლა master გაზიარებული საცავი "დაცულია". ამ სცენარში, ინდივიდუალური დეველოპერები აქვეყნებენ თავიანთ კოდს დისტანციური საცავის ფილიალებში, რათა სხვებმა შეხედონ ამ კოდს, თუ ყველაფერი რიგზეა, შეაერთონ იგი master საერთო საცავი.

ამ კონკრეტულ კურსში ჩვენ გამოვიყენებთ სამუშაო პროცესს, რომელიც იყენებს ფილიალებს.

გამოვაქვეყნოთ ჩვენი კოდი.

️ დავალება

• გამოაქვეყნეთ ცვლილებები დისტანციურ ფილიალში, იგივე სახელით, როგორც თქვენი სამუშაო ფილიალი

ბრძანებები

git push --set-upstream origin feature

შექმენით გაყვანის მოთხოვნა

შექმენით pull მოთხოვნა სათაურით ნაბიჯების მიმოხილვა. Დაინსტალირება feature როგორც „თავის ტოტი“ და master „ბაზის ტოტის“ მსგავსად.

დარწმუნდით, რომ დააინსტალირეთ master მის ჩანგალი საცავი როგორც "საბაზისო ფილიალი", მე არ ვუპასუხებ თხოვნებს კურსის მასალების საცავში ცვლილებების შესახებ.

GitHub ლინგოში „ბაზა ფილიალი“ არის ის ფილიალი, რომელზედაც თქვენ აფუძნებთ თქვენს სამუშაოს, ხოლო „ხელმძღვანელი ფილიალი“ არის ის ფილიალი, რომელიც შეიცავს შემოთავაზებულ ცვლილებებს.

განიხილეთ ცვლილებები, დაამატეთ ახალი ვალდებულებები დისკუსიის გაგრძელებისას

გაყვანის მოთხოვნა (PR)

გაყვანის მოთხოვნა (PR) არის კოდის განხილვისა და დოკუმენტაციის, ასევე კოდის განხილვის ჩატარების საშუალება. Pull მოთხოვნები დასახელებულია ინდივიდუალური ცვლილებების მთლიან კოდში ინტეგრირების ზოგადი გზით. როგორც წესი, ადამიანი კლონირებს პროექტის დისტანციურ ოფიციალურ საცავს და მუშაობს კოდზე ადგილობრივად. ამის შემდეგ ის დებს კოდს თავის პირად დისტანციურ საცავში და სთხოვს ოფიციალურ საცავზე პასუხისმგებელ პირებს აიღონ (გაიყვანოს) მისი კოდი ადგილობრივ საცავებში, სადაც ისინი განიხილავენ და შესაძლოა ინტეგრირებულნი (შერწყმა) მისი. ეს კონცეფცია ასევე ცნობილია სხვა სახელებით, მაგალითად, შერწყმის მოთხოვნა.

თქვენ ნამდვილად არ გჭირდებათ გამოიყენოთ GitHub-ის ან მსგავსი პლატფორმების pull მოთხოვნის ფუნქცია. განვითარების გუნდებმა შეიძლება გამოიყენონ კომუნიკაციის სხვა მეთოდები, მათ შორის პირისპირ კომუნიკაცია, ხმოვანი ზარები ან ელ. აქ არის რამდენიმე მათგანი:

• ორგანიზებული დისკუსიები კონკრეტულ კოდექსის ცვლილებებთან დაკავშირებით;
• როგორც ავტოტესტერის და კოლეგების მიერ მიმდინარე სამუშაოს შესახებ უკუკავშირის სანახავად;
• კოდექსის განხილვის ფორმალიზება;
• რათა მოგვიანებით გაიგოთ ამა თუ იმ კოდის უკან არსებული მიზეზები და მოსაზრებები.

როგორც წესი, თქვენ ქმნით გაყვანის მოთხოვნას, როდესაც გჭირდებათ რაიმეს განხილვა ან გამოხმაურების მიღება. მაგალითად, თუ თქვენ მუშაობთ ფუნქციაზე, რომელიც შეიძლება განხორციელდეს ერთზე მეტი გზით, შეგიძლიათ შექმნათ pull-მოთხოვნა კოდის პირველ სტრიქონამდე, რათა გაუზიაროთ თქვენი იდეები და განიხილოთ თქვენი გეგმები თქვენს კოლაბორატორებთან. თუ სამუშაო უფრო მარტივია, მოზიდვის მოთხოვნა იხსნება, როდესაც რაღაც უკვე შესრულებულია, ჩადენილია და შეიძლება განიხილოს. ზოგიერთ სცენარში, შეიძლება დაგჭირდეთ PR-ის გახსნა მხოლოდ ხარისხის კონტროლის მიზეზების გამო: ავტომატური ტესტების გასაშვებად ან კოდის მიმოხილვის დაწყება. რაც არ უნდა გადაწყვიტოთ, არ დაგავიწყდეთ @მოხსენით ის ადამიანები, ვისი თანხმობაც გსურთ თქვენი მოზიდვის მოთხოვნაში.

როგორც წესი, პიარის შექმნისას აკეთებთ შემდეგს.

• მიუთითეთ რის შეცვლას სთავაზობთ და სად.
• დაწერეთ აღწერა, რომელშიც ახსნილია ცვლილებების მიზანი. შეიძლება გინდოდეს:
  • დაამატეთ რაიმე მნიშვნელოვანი, რაც არ არის აშკარა კოდიდან, ან რაიმე სასარგებლო კონტექსტის გასაგებად, როგორიცაა შესაბამისი #შეცდომები და ჩადენილი ნომრები;
  • @მონიშნეთ ნებისმიერი, ვისთანაც გსურთ დაიწყოთ მუშაობა, ან შეგიძლიათ @აღნიშნოთ ისინი კომენტარებში მოგვიანებით;
  • სთხოვეთ კოლეგებს დაეხმარონ რაიმეში ან შეამოწმონ რაიმე კონკრეტული.

როგორც კი PR-ს გახსნით, ასეთ შემთხვევებში კონფიგურირებული ტესტები შესრულდება. ჩვენს შემთხვევაში, ეს იქნება ტესტების იგივე ნაკრები, რომელიც ჩვენ ჩავატარეთ ადგილობრივად, მაგრამ რეალურ პროექტში შეიძლება იყოს დამატებითი ტესტები და შემოწმებები.

გთხოვთ დაელოდოთ ტესტების დასრულებას. თქვენ შეგიძლიათ იხილოთ ტესტების სტატუსი PR დისკუსიის ბოლოში GitHub ინტერფეისში. გააგრძელეთ ტესტების დასრულების შემდეგ.

️ დაამატეთ შენიშვნა CI ნაბიჯების სიის შემთხვევითობის შესახებ

ამ კურსში გამოყენებული სია არის თვითნებური და სუბიექტური, ამის შესახებ უნდა დავამატოთ შენიშვნა.

️ ამოცანა: შექმენით pull მოთხოვნა ამ კომენტარისთვის

1. ფილიალზე გადართვა master.
2. შექმენით ფილიალი სახელად bugfix.
3. დაამატეთ შენიშვნის ტექსტი ფაილის ბოლოს ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. შეასრულეთ ცვლილებები.
5. გამოაქვეყნეთ თემა bugfix დისტანციურ საცავში.
6. შექმენით მოზიდვის მოთხოვნა სახელად შენიშვნის დამატება თავის ტოტით bugfix და ბაზის ფილიალიmaster.

დარწმუნდით, რომ დააინსტალირეთ master მის ჩანგალი საცავი როგორც "საბაზისო ფილიალი", მე არ ვუპასუხებ თხოვნებს კურსის მასალების საცავში ცვლილებების შესახებ.

ასე უნდა გამოიყურებოდეს თქვენი საცავი.

ბრძანებები

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

მოთხოვნის დამტკიცება "შენიშვნის დამატება"

️ დავალება

1. შექმენით გაყვანის მოთხოვნა.
2. დააწკაპუნეთ "გაერთიანების მოთხოვნა".
3. დააჭირეთ "დაადასტურეთ შერწყმა".
4. დააწკაპუნეთ "წაშლა ფილიალის", ჩვენ აღარ გვჭირდება.

ეს არის შერწყმის შემდეგ ვალდებულებების დიაგრამა.

️ გააგრძელეთ მუშაობა და დაამატეთ ტესტები

მოზიდვის მოთხოვნაზე თანამშრომლობა ხშირად იწვევს დამატებით სამუშაოს. ეს ჩვეულებრივ კოდის განხილვის ან განხილვის შედეგია, მაგრამ ჩვენს კურსში ჩვენ ვაპირებთ ამის მოდელირებას ახალი ელემენტების დამატებით ჩვენს CI ნაბიჯების სიაში.

უწყვეტი ინტეგრაცია, როგორც წესი, მოიცავს გარკვეული ტესტის გაშუქებას. ტესტის დაფარვის მოთხოვნები განსხვავდება და ჩვეულებრივ გვხვდება დოკუმენტში, რომელსაც ეწოდება "წვლილის სახელმძღვანელო მითითებები". ჩვენ გავამარტივებთ და დავამატებთ ტესტს თითოეული ხაზისთვის ჩვენს საკონტროლო სიაში.

დავალებების შესრულებისას, ჯერ სცადეთ ტესტების შესრულება. თუ სწორად დააინსტალირეთ pre-commit დაამაგრეთ ადრე, ახლად დამატებული ტესტი ჩატარდება, ჩავარდება და არაფერი ჩაიდენს. გაითვალისწინეთ, რომ ასე ვიცით, რომ ჩვენი ტესტები რეალურად ამოწმებს რაღაცას. საინტერესოა, რომ თუ ჩვენ დავიწყეთ კოდით ტესტების დაწყებამდე, ტესტების ჩაბარება შეიძლება ნიშნავს, რომ კოდი მუშაობდა ისე, როგორც მოსალოდნელი იყო, ან რომ ტესტები რეალურად არ ამოწმებდნენ არაფერს. გარდა ამისა, ტესტები რომ არ გვეწერა თავიდან, შეიძლება საერთოდ დაგვევიწყებინა, რადგან ამას არაფერი გაგვახსენებდა.

ტესტზე ორიენტირებული განვითარება (TDD)

TDD გირჩევთ დაწეროთ ტესტები კოდის წინ. ტიპიური სამუშაო პროცესი TDD-ის გამოყენებით ასე გამოიყურება.

1. დაამატეთ ტესტი.
2. ჩაატარეთ ყველა ტესტი და დარწმუნდით, რომ ახალი ტესტი ვერ ჩაივლის.
3. დაწერე კოდი.
4. გაიარეთ ტესტები, დარწმუნდით, რომ ყველა ტესტი გაივლის.
5. გადააკეთეთ თქვენი კოდი.
6. გამეორება.

იმის გამო, რომ ტესტების შედეგები, რომლებიც წარუმატებელი აღმოჩნდა, ჩვეულებრივ ნაჩვენებია წითლად, ხოლო ჩაბარებული ტესტები ჩვეულებრივ ნაჩვენებია მწვანედ, ციკლი ასევე ცნობილია, როგორც წითელ-მწვანე-რეფაქტორი.

️ დავალება

ჯერ სცადეთ ტესტების ჩადენა და მათი წარუმატებლობის დაშვება, შემდეგ დაამატეთ და ჩაწერეთ თავად CI ნაბიჯების სიის ტექსტი. ნახავთ, რომ ტესტები გადის („მწვანე“).
შემდეგ გამოაქვეყნეთ ახალი კოდი დისტანციურ საცავში და უყურეთ ტესტების გაშვებას GitHub ინტერფეისში, მოთხოვნის განხილვისა და PR სტატუსის განახლების ბოლოში.

1. ფილიალზე გადართვა feature.

2. დაამატეთ ეს ტესტები ci.test.js ბოლო ზარის შემდეგ it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. სცადეთ ტესტების ჩატარება. თუ pre-commit Hook დაყენებულია, ჩადენის მცდელობა წარუმატებელი იქნება.
4. შემდეგ დაამატეთ ეს ტექსტი ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. შეიტანეთ და განახორციელეთ ცვლილებები ადგილობრივად.
6. განათავსეთ ცვლილებები ფილიალში feature.

ახლა თქვენ უნდა გქონდეთ მსგავსი რამ

ბრძანებები

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

კონფლიქტის შერწყმა

გადადით მოთხოვნის შეცვლაზე ნაბიჯების მიმოხილვა.

მიუხედავად იმისა, რომ ჩვენ არაფერი დაგვიშავებია და ჩვენი კოდის ტესტები გაიარა, ფილიალის გაერთიანება მაინც არ შეგვიძლია feature и master. ეს იმიტომ, რომ სხვა თემა bugfix გაერთიანდა master სანამ ამ პიარზე ვმუშაობდით.
ეს ქმნის სიტუაციას, როდესაც დისტანციური ფილიალი master აქვს უფრო ახალი ვერსია, ვიდრე ის, რომელზედაც ჩვენ ფილიალს ვაფუძნებდით feature. ამის გამო ჩვენ არ შეგვიძლია უბრალოდ HEAD-ის გადახვევა master ძაფის ბოლომდე feature. ამ სიტუაციაში, ჩვენ გვჭირდება ან შერწყმა ან გამოვიყენოთ ვალდებულებები feature რებაზირება master. GitHub-ს შეუძლია რეალურად შეასრულოს ავტომატური შერწყმა, თუ არ არის კონფლიქტები. სამწუხაროდ, ჩვენს სიტუაციაში, ორივე ფილიალს აქვს კონკურენტული ცვლილებები ფაილში ci.md. ეს სიტუაცია ცნობილია, როგორც შერწყმის კონფლიქტი და ჩვენ უნდა მოვაგვაროთ ის ხელით.

შერწყმა ან ხელახალი ბაზა

შერწყმა

• ქმნის დამატებით შერწყმის ვალდებულებას და ინახავს სამუშაო ისტორიას.
  • ინახავს ფილიალების თავდაპირველ ვალდებულებებს მათი ორიგინალური დროის შტამპებითა და ავტორებით.
  • ინახავს ვალდებულებების SHA-ს და აკავშირებს მათ ცვლილების მოთხოვნის განხილვაში.
• მოითხოვს კონფლიქტის ერთჯერად მოგვარებას.
• სიუჟეტს ხდის არაწრფივი.
  • სიუჟეტი შეიძლება რთული წასაკითხი იყოს ფილიალების დიდი რაოდენობის გამო (IDE კაბელს მოგაგონებთ).
  • ართულებს ავტომატურ გამართვას, მაგ. git bisect ნაკლებად სასარგებლო - ის იპოვის მხოლოდ შერწყმის ვალდებულებას.

რებეზი

• გამეორებები ხდება მიმდინარე ფილიალიდან ერთიმეორის მიყოლებით.
  • გენერირებულია ახალი დავალებები ახალი SHA-ებით, რაც იწვევს GitHub-ში შესრულებულ ვალდებულებებს ემთხვევა თავდაპირველ მოთხოვნებს, მაგრამ არა შესაბამის კომენტარებს.
  • ვალდებულებები შეიძლება ხელახლა გაერთიანდეს და შეიცვალოს პროცესში, ან თუნდაც გაერთიანდეს ერთში.
• შეიძლება საჭირო გახდეს მრავალი კონფლიქტის მოგვარება.
• საშუალებას გაძლევთ შეინარჩუნოთ ხაზოვანი ამბავი.
  • სიუჟეტი შეიძლება იყოს უფრო ადვილი წასაკითხი, თუ ის არ არის ძალიან გრძელი უსაფუძვლო მიზეზის გამო.
  • ავტომატური გამართვა და პრობლემების მოგვარება ცოტა უფრო ადვილია: შესაძლებელს ხდის git bisect, შეუძლია ავტომატური დაბრუნება უფრო ნათელი და პროგნოზირებადი გახადოს.
• მოითხოვს ფილიალის გამოქვეყნებას მიგრირებული ვალდებულებებით დროშით --force როდესაც გამოიყენება გაყვანის მოთხოვნებთან ერთად.

როგორც წესი, გუნდები თანხმდებიან, რომ ყოველთვის გამოიყენონ იგივე სტრატეგია, როდესაც მათ სჭირდებათ ცვლილებების შერწყმა. ეს შეიძლება იყოს "სუფთა" შერწყმა ან "სუფთა" დასრულება თავზე, ან რაღაც შუალედში, მაგალითად, ზემოდან დასრულებული ინტერაქტიულად (git rebase -i) ადგილობრივად ფილიალებისთვის, რომლებიც არ არის გამოქვეყნებული საჯარო საცავში, მაგრამ გაერთიანდება "საჯარო" ფილიალებისთვის.

აქ ჩვენ გამოვიყენებთ შერწყმას.

️ დავალება

1. დარწმუნდით, რომ კოდი ადგილობრივ ფილიალშია master განახლებულია დისტანციური საცავიდან.
2. ფილიალზე გადართვა feature.
3. ფილიალთან შერწყმის დაწყება master. შერწყმის კონფლიქტი კონკურენტული ცვლილებების გამო ci.md.
4. მოაგვარეთ კონფლიქტი ისე, რომ ჩვენი CI ნაბიჯების სია და მის შესახებ შენიშვნა ტექსტში დარჩეს.
5. გამოაქვეყნეთ შერწყმის ვალდებულება დისტანციურ ფილიალში feature.
6. შეამოწმეთ მოთხოვნის სტატუსი GitHub UI-ში და დაელოდეთ სანამ შერწყმა გადაწყდება.

ბრძანებები

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Ყოჩაღ!

თქვენ დაასრულეთ სია და ახლა თქვენ უნდა დაადასტუროთ მოთხოვნის მოთხოვნა master.

️ ამოცანა: დაადასტურეთ pull-მოთხოვნა „ნაბიჯების განხილვა“

1. გახსენით გაყვანის მოთხოვნა.
2. დააწკაპუნეთ "გაერთიანების მოთხოვნა".
3. დააჭირეთ "დაადასტურეთ შერწყმა".
4. დააჭირეთ "წაშლა ფილიალს", რადგან ის აღარ გვჭირდება.

ეს არის თქვენი საცავი ამ მომენტში

პროდუქტის შეცდომა

ნათქვამია, რომ „ტესტირება შეიძლება გამოვიყენოთ შეცდომების არსებობის საჩვენებლად, მაგრამ არასოდეს მათი არარსებობის საჩვენებლად“. მიუხედავად იმისა, რომ ჩვენ გვქონდა ტესტები და მათ არ გვიჩვენეს შეცდომები, მზაკვრული ხარვეზი შემოვიდა წარმოებაში.

ასეთ სცენარში ჩვენ უნდა ვიზრუნოთ:

• რა არის განლაგებული წარმოებაში;
• კოდი თემაში master შეცდომით, საიდანაც დეველოპერებს შეუძლიათ ახალი სამუშაოს დაწყება.

უნდა დავაბრუნო თუ გავასწორო შემდეგ ვერსიაში?

უკან დაბრუნება არის ცნობილი, ადრეული ვერსიის განლაგების პროცესი წარმოებაში და შეცდომის შემცველი ვალდებულებების დაბრუნება. "Fixing Forward" არის დამატებით ფიქსაცია master და რაც შეიძლება მალე განათავსეთ ახალი ვერსია. იმის გამო, რომ API-ები და მონაცემთა ბაზის სქემები იცვლება, როდესაც კოდი განლაგებულია წარმოებაში, უწყვეტი მიწოდებით და კარგი ტესტის დაფარვით, უკან დაბრუნება, როგორც წესი, ბევრად უფრო რთული და სარისკოა, ვიდრე მისი დაფიქსირება შემდეგ ვერსიაში.

ვინაიდან უკან დაბრუნება ჩვენს შემთხვევაში არანაირ რისკს არ შეიცავს, ამ გზას გავალთ, რადგან ეს გვაძლევს საშუალებას

• დააფიქსირეთ შეცდომა პროდუქტზე რაც შეიძლება მალე;
• კოდის გაკეთება master დაუყოვნებლივ შესაფერისი ახალი სამუშაოს დასაწყებად.

️ დავალება

1. ფილიალზე გადართვა master ადგილობრივად.
2. განაახლეთ ადგილობრივი საცავი დისტანციური საცავიდან.
3. დააბრუნეთ PR შერწყმის ვალდებულება ნაბიჯების მიმოხილვა в master.
4. გამოაქვეყნეთ ცვლილებები დისტანციურ საცავში.

ეს არის საცავის ისტორია, რომელშიც შერწყმის ვალდებულება დაბრუნდა

ბრძანებები

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ თვითტესტი

Დარწმუნდი, რომ ci.md შერწყმის დაბრუნების შემდეგ აღარ შეიცავს ტექსტს "sneaky bug".

დააფიქსირეთ CI ნაბიჯების სია და დააბრუნეთ სამაგისტრო

ჩვენ მთლიანად დავაბრუნეთ ფილიალის შერწყმის ვალდებულება. feature. კარგი ამბავი ის არის, რომ ჩვენ ახლა არანაირი შეცდომა არ გვაქვს master. ცუდი ამბავი ის არის, რომ ჩვენი უწყვეტი ინტეგრაციის ნაბიჯების ძვირფასი სიაც გაქრა. ასე რომ, იდეალურ შემთხვევაში, ჩვენ უნდა გამოვიყენოთ შესწორება იმ ვალდებულებებზე feature და დააბრუნეთ ისინი master გამოსწორებასთან ერთად.

ჩვენ შეგვიძლია მივუდგეთ პრობლემას სხვადასხვა გზით:

• დააბრუნეთ ვალდებულება, რომელიც გააუქმებს შერწყმას feature с master;
• ნაბიჯი ავალდებულებს ყოფილი feature.

განვითარების სხვადასხვა გუნდი იყენებს განსხვავებულ მიდგომებს ამ შემთხვევაში, მაგრამ ჩვენ გადავიტანთ სასარგებლო ვალდებულებებს ცალკე ფილიალში და შევქმნით ცალკე pull მოთხოვნას ამ ახალი ფილიალისთვის.

️ დავალება

1. შექმენით თემა ე.წ feature-fix და გადაერთეთ მასზე.

2. გადაიტანეთ ყველა ვალდებულება ყოფილი ფილიალიდან feature ახალ თემაში. მიგრაციის დროს წარმოქმნილი გაერთიანების კონფლიქტების მოგვარება.

   

3. დაამატეთ რეგრესიის ტესტი ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. ჩაატარეთ ტესტები ადგილობრივად, რათა დარწმუნდეთ, რომ ისინი არ ჩავარდებიან.
5. წაშალეთ ტექსტი "შეპარული შეცდომით". ci.md.
6. დაამატეთ ტესტის ცვლილებები და ნაბიჯების სიის ცვლილებები ინდექსში და ჩაიდინეთ ისინი.
7. გამოაქვეყნეთ ფილიალი დისტანციურ საცავში.

თქვენ უნდა დაასრულოთ მსგავსი რამ:

ბრძანებები

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

შექმენით გაყვანის მოთხოვნა.

შექმენით pull მოთხოვნა სათაურით ფუნქციის დაფიქსირება. Დაინსტალირება feature-fix როგორც „თავის ტოტი“ და master „ბაზის ტოტის“ მსგავსად.
გთხოვთ დაელოდოთ ტესტების დასრულებას. ტესტების სტატუსის ნახვა შეგიძლიათ პიარის დისკუსიის ბოლოში.

დარწმუნდით, რომ დააინსტალირეთ master მის ჩანგალი საცავი როგორც "საბაზისო ფილიალი", მე არ ვუპასუხებ თხოვნებს კურსის მასალების საცავში ცვლილებების შესახებ.

მოთხოვნის დამტკიცება "ფუნქციის შესწორება"

მადლობა შესწორებისთვის! გთხოვთ, დაადასტუროთ ცვლილებები master გაყვანის მოთხოვნიდან.

️ დავალება

1. დააწკაპუნეთ "გაერთიანების მოთხოვნა".
2. დააჭირეთ "დაადასტურეთ შერწყმა".
3. დააჭირეთ "წაშლა ფილიალს", რადგან ის აღარ გვჭირდება.

ეს არის ის, რაც ამ მომენტში უნდა გქონდეთ.

გილოცავთ!

თქვენ დაასრულეთ ყველა ის ნაბიჯი, რომელსაც ხალხი ჩვეულებრივ დგამს უწყვეტი ინტეგრაციის დროს.

თუ შეამჩნევთ რაიმე პრობლემას კურსთან დაკავშირებით ან იცით, როგორ გააუმჯობესოთ ის, გთხოვთ, შექმენით პრობლემა საცავები სასწავლო მასალებით. ამ კურსსაც აქვს ინტერაქტიული ვერსია GitHub Learning Lab-ის პლატფორმის გამოყენებით.

წყარო: www.habr.com