Slack-ში გამოყენებული პროექტის განლაგების მეთოდოლოგია

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

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

როგორ მუშაობს დღეს პროექტის განლაგების პროცესები

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

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

Checkpoint სისტემის ინტერფეისი, რომელიც გამოიყენება Slack-ში პროექტების განსათავსებლად

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

▍1. გამოშვების ფილიალის შექმნა

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

▍2. განლაგება დადგმის გარემოში

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

▍3. განლაგება საწარმოო და კანარის გარემოში

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

▍4. ეტაპობრივი გაშვება წარმოებაში

თუ ახალი გამოშვების მონიტორინგის ინდიკატორები აღმოჩნდება სტაბილური და თუ პროექტის განლაგების შემდეგ კანარის გარემოში არ მიგვიღია რაიმე პრეტენზია, ჩვენ ვაგრძელებთ წარმოების სერვერების ეტაპობრივ გადატანას ახალ გამოშვებაზე. განლაგების პროცესი დაყოფილია შემდეგ ეტაპებად: 10%, 25%, 50%, 75% და 100%. შედეგად, ჩვენ შეგვიძლია ნელ-ნელა გადავიტანოთ წარმოების ტრაფიკი სისტემის ახალ გამოშვებაზე. ამასთან, გვაქვს დრო, რომ გამოვიკვლიოთ სიტუაცია, თუ რაიმე ანომალია გამოვლინდა.

▍ რა მოხდება, თუ განლაგების დროს რამე არასწორედ მოხდება?

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

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

განლაგების სისტემის სამშენებლო ბლოკები

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

▍სწრაფი განლაგება

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

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

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

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

1. წარმოების სერვერები აკონტროლებენ Consul key. 2. გასაღები იცვლება, ეს ეუბნება სერვერებს, რომ მათ უნდა დაიწყონ ახალი კოდის ჩამოტვირთვა. 3. სერვერები გადმოწერენ tarball ფაილებს აპლიკაციის კოდით

▍ატომური განლაგება

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

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

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

1. აპლიკაციის კოდის გახსნა „ცივ“ დირექტორიაში. 2. სისტემის გადართვა "ცივ" დირექტორიაზე, რომელიც ხდება "ცხელი" (ატომური ოპერაცია)

შედეგები: აქცენტის გადატანა სანდოობაზე

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

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

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

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

წყარო: www.habr.com