როგორ ვათავისუფლებთ პროგრამულ პატჩებს GitLab-ში

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

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

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

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

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

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

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

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

რას აკეთებს გამოშვების მენეჯერი?

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

თვითინსტალაციის გამოშვებები და gitlab.com-ის გამოშვებები იყენებენ მსგავს სამუშაო პროცესს, მაგრამ მუშაობს სხვადასხვა დროს, განმარტავს მარინი.

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

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

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

ეს ყველაფერი გამოსწორებაზეა

რა არის პატჩები და რატომ გვჭირდება ისინი?

გამოშვების მენეჯერი წყვეტს გამოუშვას თუ არა გამოსწორება შეცდომის სიმძიმის მიხედვით.

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

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

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

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

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

როგორ ქმნის გამოშვების მენეჯერი პატჩებს

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

/chatops run release prepare 12.10.1

ChatOps მუშაობს Slack-ში, რათა გამოიწვიოს სხვადასხვა მოვლენები, რომლებიც შემდეგ მუშავდება და სრულდება GitLab-ის მიერ. მაგალითად, მიწოდების ჯგუფმა შექმნა ChatOps სხვადასხვა ნივთების ავტომატიზაციისთვის პატჩების გასაშვებად.

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

ქვემოთ მოცემულ ვიდეოში ნაჩვენებია GitLab-ისთვის პაჩის მომზადების ტექნიკური პროცესი.

როგორ მუშაობს ავტომატური განლაგება gitlab.com-ზე

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

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

”ასე რომ, gitlab.com-მდე გვაქვს მრავალი განლაგება, რომელიც მუშაობს სხვადასხვა გარემოში და მას შემდეგ, რაც ეს გარემო კარგ ფორმაშია და ტესტირება აჩვენებს კარგ შედეგებს, გამოშვების მენეჯერი იწყებს gitlab.com-ის განლაგების მოქმედებებს,” - ამბობს მარინი.

CICD ტექნოლოგია gitlab.com-ის განახლებების მხარდაჭერისთვის ავტომატიზირებს მთელ პროცესს იქამდე, რომ გამოშვების მენეჯერმა ხელით უნდა დაიწყოს gitlab.com-ზე წარმოების გარემოს განთავსება.

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

კიდევ რას აკეთებს მიწოდების ჯგუფი?

მთავარი განსხვავება gitlab.com-ის განახლების პროცესებსა და პატჩების შიდა კლიენტებისთვის გამოშვებას შორის არის ის, რომ ეს უკანასკნელი პროცესს მოითხოვს უფრო მეტ დროს და უფრო მეტ ხელით მუშაობას გამოშვების მენეჯერისგან.

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

მიწოდების ჯგუფის ერთ-ერთი მოკლევადიანი მიზანია შეამციროს გამოშვების მენეჯერის ხელით სამუშაოს მოცულობა, რათა დააჩქაროს გამოშვება. გუნდი მუშაობს გათავისუფლების პროცესის გამარტივებაზე, გამარტივებასა და ავტომატიზაციაზე, რაც ხელს შეუწყობს დაბალი სიმძიმის პრობლემების გამოსწორებას (S3 და S4, დაახლ. მთარგმნელი). სიჩქარეზე ფოკუსირება არის შესრულების მთავარი მაჩვენებელი: აუცილებელია შემცირდეს MTTP - დრო შერწყმის მოთხოვნის მიღებიდან gitlab.com-ზე შედეგის განთავსებამდე - მიმდინარე 50 საათიდან 8 საათამდე.

მიწოდების ჯგუფი ასევე მუშაობს gitlab.com-ის Kubernetes-ზე დაფუძნებულ ინფრასტრუქტურაზე მიგრაციაზე.

რედაქტორის ნ.ბ.: თუ უკვე გსმენიათ Kubernetes ტექნოლოგიის შესახებ (და ეჭვი არ მეპარება, რომ გსმენიათ), მაგრამ ჯერ არ შეხებიათ მას ხელით, გირჩევთ მონაწილეობა მიიღოთ ონლაინ ინტენსიურ კურსებში. კუბერნეტის ბაზა, რომელიც 28-30 სექტემბერს გაიმართება და Kubernetes Mega14-16 ოქტომბერს გაიმართება. ეს საშუალებას მოგცემთ დამაჯერებლად ნავიგაცია და ტექნოლოგიასთან მუშაობა.

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

რაიმე იდეა ან რეკომენდაცია ჩვენთვის?

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

წყარო: www.habr.com