🥇 ცნობარი: როგორ მუშაობს უწყვეტი ინტეგრაციის პროცესი

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

/flickr/ ალტუგ კარაკოჩი / CC BY / ფოტო შეცვლილია

ვადა

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

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

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

Story

1996 წელს, მეთოდოლოგიის შემქმნელებმა მიიღეს CI. ექსტრემალური პროგრამირება (XP) — კენტ ბეკი (კენტ ბეკი) და რონ ჯეფრისი (რონ ჯეფრისი) უწყვეტი ინტეგრაცია მათი მიდგომის თორმეტი ძირითადი პრინციპიდან ერთ-ერთი გახდა. XP-ის დამფუძნებლებმა განმარტეს CI მეთოდოლოგიის მოთხოვნები და აღნიშნეს პროექტის დღეში რამდენჯერმე აგების აუცილებლობა.

2000-იანი წლების დასაწყისში, უწყვეტი ინტეგრაციის მეთოდოლოგიას ხელი შეუწყო Agile Alliance-ის ერთ-ერთმა დამფუძნებელმა. მარტინ ფაულერი (მარტინ ფაულერი). CI-სთან მისმა ექსპერიმენტებმა განაპირობა ამ სფეროში პირველი პროგრამული ინსტრუმენტის, CruiseControl-ის შექმნა. პროგრამა შეიქმნა მარტინის კოლეგის, მეთიუ ფოემელის მიერ.

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

CI პროგრამული უზრუნველყოფის გაჩენასთან ერთად, სულ უფრო მეტმა კომპანიამ დაიწყო ამ პრაქტიკის დანერგვა. Forrester-ის კვლევის თანახმად [გვ. 5] მოხსენება], 2009 წელს, გამოკითხული ორმოცდაათი ტექნოლოგიური კომპანიის 86% იყენებდა ან ნერგავდა CI მეთოდებს.

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

როგორ აკეთებს ამას მუშაობა

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

პროცესის ზოგადი სქემა შეიძლება წარმოდგენილი იყოს შემდეგნაირად:

CI მეთოდოლოგია დეველოპერებს უამრავ მოთხოვნას უყენებს:

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

განხორციელების სირთულეები

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

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

გამოკითხვების მიხედვით [გვ.14] მუხლი], უწყვეტი ინტეგრაცია ზრდის კომპანიის თანამშრომლების სამუშაო დატვირთვას (ყოველ შემთხვევაში, თავიდან მაინც). მათ ახალი ინსტრუმენტების ათვისება უწევთ და კოლეგები ყოველთვის არ ეხმარებიან ტრენინგში. ამიტომ, მათ ახალი ჩარჩოებისა და სერვისების „გზაში“ გააზრება უწევთ.

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

/flickr/ მათი / CC BY-SA

ვინც იყენებს

IT გიგანტები Google პირველები იყვნენ, ვინც მეთოდის უპირატესობები დააფასა. იყენებს უწყვეტი ინტეგრაცია 2000-იანი წლების შუა პერიოდიდან. CI დაინერგა საძიებო სისტემაში შეფერხებების პრობლემის გადასაჭრელად. უწყვეტმა ინტეგრაციამ ხელი შეუწყო პრობლემების სწრაფად აღმოჩენას და გამოსწორებას. ახლა CI-ს იყენებს IT გიგანტის ყველა განყოფილება.

უწყვეტი ინტეგრაცია მცირე კომპანიებსაც ეხმარება და CI ინსტრუმენტებს ასევე იყენებენ ფინანსური და ჯანდაცვის ორგანიზაციები. მაგალითად, Morningstar-ის უწყვეტი ინტეგრაციის სერვისებმა დაუცველობების 70%-ით უფრო სწრაფად გამოსწორებაში დაეხმარა. Philips Healthcare-ის სამედიცინო პლატფორმამ კი განახლებების ტესტირების სიჩქარის გაორმაგება შეძლო.

ინსტრუმენტები

აქ მოცემულია CI-სთვის რამდენიმე პოპულარული ინსტრუმენტი:

Jenkins — ერთ-ერთი ყველაზე პოპულარული CI სისტემა. ის მხარს უჭერს ათასზე მეტ დანამატს სხვადასხვა VCS-თან, ღრუბლოვან პლატფორმებთან და სხვა სერვისებთან ინტეგრაციისთვის. ჩვენ ასევე ვიყენებთ Jenkins-ს 1cloud-ში: ინსტრუმენტს ჩვენი DevOps სისტემის ნაწილიაის რეგულარულად ამოწმებს ტესტირებისთვის განკუთვნილ Git-ის ფილიალს.
Buildbot — Python-ის ჩარჩო საკუთარი უწყვეტი ინტეგრაციის პროცესების დასაწერად. ხელსაწყოს საწყისი დაყენება საკმაოდ რთულია, მაგრამ ეს კომპენსირდება ფართო პერსონალიზაციის ვარიანტებით. ჩარჩოს უპირატესობებს შორის მომხმარებლები ხაზს უსვამენ მის დაბალ რესურსულ ინტენსივობას.
დარბაზი CI — Pivotal-ის სერვერი, რომელიც იყენებს Docker-ის კონტეინერებს. Concourse CI ინტეგრირდება ნებისმიერ ინსტრუმენტთან და ვერსიის კონტროლის სისტემასთან. დეველოპერები აღნიშნავენ, რომ სისტემა შესაფერისია ნებისმიერი ზომის კომპანიებში სამუშაოდ.
Gitlab CI — GitLab-ის ვერსიის კონტროლის სისტემაში ჩაშენებული ინსტრუმენტი. სერვისი მუშაობს ღრუბელში და კონფიგურაციისთვის იყენებს YAML ფაილებს. Concourse-ის მსგავსად, Gitlab CI ვრცელდება Docker კონტეინერები, რომლებიც ხელს უწყობენ სხვადასხვა პროცესების ერთმანეთისგან იზოლირებას.
კოდირება — ღრუბლოვანი CI სერვერი, რომელიც მუშაობს GitHub-თან, GitLab-თან და BitBucket-თან. პლატფორმა არ საჭიროებს ხანგრძლივ საწყის დაყენებას — Codeship-ს აქვს სტანდარტული წინასწარ დაინსტალირებული CI პროცესები. მცირე (თვეში 100-მდე ბილდინგის) და ღია კოდის პროექტებისთვის, Codeship ხელმისაწვდომია უფასოდ.