სკრიპტებიდან ჩვენს საკუთარ პლატფორმამდე: როგორ მოვახდინეთ განვითარების ავტომატიზაცია CIAN-ში

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

ნულოვანი დონე

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

CIAN-ში ავტომატიზაცია დაიწყო კომპანიის დაარსებიდან 14 წლის შემდეგ. იმ დროს განვითარების გუნდში 35 ადამიანი იყო. ძნელი დასაჯერებელია, არა? რა თქმა უნდა, ავტომატიზაცია არსებობდა რაიმე ფორმით, მაგრამ უწყვეტი ინტეგრაციისა და კოდის მიწოდების ცალკეული მიმართულება 2015 წლიდან დაიწყო. 

იმ დროს ჩვენ გვქონდა Python, C# და PHP უზარმაზარი მონოლითი, განლაგებული Linux/Windows სერვერებზე. ამ მონსტრის გამოსაყენებლად, ჩვენ გვქონდა სკრიპტების ნაკრები, რომლებიც ხელით გავუშვით. ასევე იყო მონოლითის აწყობა, რომელმაც მოიტანა ტკივილი და ტანჯვა კონფლიქტების გამო ტოტების შერწყმის, დეფექტების გამოსწორებისა და აღდგენის დროს „განსხვავებული ამოცანებით მშენებლობაში“. გამარტივებული პროცესი ასე გამოიყურებოდა:

ჩვენ არ ვიყავით კმაყოფილი ამით და გვინდოდა აგვეშენებინა განმეორებადი, ავტომატიზირებული და მართვადი აგებისა და განლაგების პროცესი. ამისთვის დაგვჭირდა CI/CD სისტემა და ავირჩიეთ Teamcity-ის უფასო ვერსიასა და Jenkins-ის უფასო ვერსიას შორის, რადგან მათთან ვმუშაობდით და ორივე გვერგებოდა ფუნქციების ნაკრების თვალსაზრისით. ჩვენ ავირჩიეთ Teamcity, როგორც უახლესი პროდუქტი. იმ დროს ჩვენ ჯერ კიდევ არ გამოვიყენეთ მიკროსერვისის არქიტექტურა და არ ველოდით დავალებების და პროექტების დიდ რაოდენობას.

ჩვენ მივდივართ ჩვენი საკუთარი სისტემის იდეამდე

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

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

ბიზნეს პროცესებში ავტომატიზაციის გაზრდის გამო, Teamcity-ში გაიზარდა პროექტებისა და გაშვებების რაოდენობა. ასე რომ, ახალი პრობლემა გაჩნდა: ერთი უფასო Teamcity ინსტანცია საკმარისი არ იყო (3 აგენტი და 100 პროექტი), დავამატეთ კიდევ ერთი მაგალითი (კიდევ 3 აგენტი და 100 პროექტი), შემდეგ მეორე. შედეგად, ჩვენ მივიღეთ რამდენიმე კლასტერის სისტემა, რომლის მართვა რთული იყო:

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

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

ჩვენ ავტომატიზირებთ ტესტირებას

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

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

ავტომატიზაციის გუნდი

ამჟამად გვყავს 130 დეველოპერისგან შემდგარი პერსონალი და ვაგრძელებთ იზრდებიან. უწყვეტი ინტეგრაციისა და კოდის მიწოდების გუნდი (შემდგომში Deploy and Integration ან DI გუნდი) შედგება 7 ადამიანისგან და მუშაობს 2 მიმართულებით: Integro ავტომატიზაციის პლატფორმის შემუშავება და DevOps. 

DevOps პასუხისმგებელია CIAN საიტის Dev/Beta გარემოზე, Integro გარემოზე, ეხმარება დეველოპერებს პრობლემების გადაჭრაში და განავითაროს ახალი მიდგომები სკალირების გარემოში. Integro-ს განვითარების მიმართულება ეხება როგორც თავად Integro-ს, ასევე მასთან დაკავშირებულ სერვისებს, მაგალითად, ჯენკინსის, Jira-ს, Confluence-ის დანამატებს და ასევე ავითარებს დამხმარე კომუნალურ და აპლიკაციებს განვითარების გუნდებისთვის. 

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

ფენიანი ავტომატიზაციის ტორტი CIAN-ში

ავტომატიზაციაში ჩართული ყველა სისტემა შეიძლება დაიყოს რამდენიმე ფენად:

1. გარე სისტემები (Jira, Bitbucket და ა.შ.). მათთან მუშაობენ განვითარების ჯგუფები.
2. ინტეგრო პლატფორმა. ყველაზე ხშირად, დეველოპერები არ მუშაობენ მასთან პირდაპირ, მაგრამ ეს არის ის, რაც ინარჩუნებს ყველა ავტომატიზაციას.
3. მიტანის, ორკესტრირებისა და აღმოჩენის სერვისები (მაგალითად, ჯეკნინსი, კონსული, მომთაბარე). მათი დახმარებით ჩვენ ვაყენებთ კოდს სერვერებზე და ვუზრუნველყოფთ სერვისების ერთმანეთთან მუშაობას.
4. ფიზიკური ფენა (სერვერები, ოპერაციული სისტემა, დაკავშირებული პროგრამული უზრუნველყოფა). ჩვენი კოდი მუშაობს ამ დონეზე. ეს შეიძლება იყოს როგორც ფიზიკური სერვერი, ასევე ვირტუალური (LXC, KVM, Docker).

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

ხელუხლებელი

მოდით გავამახვილოთ ყურადღება Integro-ზე და დავიწყოთ ტექნოლოგიის დასტათი:

• CentOS 7
• დოკერი + მომთაბარე + კონსული + სარდაფი
• Java 11 (ძველი Integro მონოლითი დარჩება Java 8-ზე)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• კურდღელი MQ 
• Apache Ignite
• კამუნდა (ჩაშენებული)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• ვებ UI: React (CSR) + MobX
• SSO: Keycloak

ჩვენ ვიცავთ მიკროსერვისის განვითარების პრინციპს, თუმცა გვაქვს მემკვიდრეობა Integro-ს ადრეული ვერსიის მონოლითის სახით. თითოეული მიკროსერვისი მუშაობს საკუთარ Docker კონტეინერში და სერვისები ერთმანეთთან ურთიერთობენ HTTP მოთხოვნებისა და RabbitMQ შეტყობინებების საშუალებით. მიკროსერვისები პოულობენ ერთმანეთს კონსულის მეშვეობით და მიმართავენ მას, გადიან ავტორიზაციას SSO-ს მეშვეობით (Keycloak, OAuth 2/OpenID Connect).

როგორც რეალური მაგალითი, განიხილეთ ჯენკინსთან ურთიერთობა, რომელიც შედგება შემდეგი ნაბიჯებისგან:

1. სამუშაო ნაკადის მართვის მიკროსერვისს (შემდგომში Flow microservice) სურს აწარმოოს build Jenkins-ში. ამისათვის ის იყენებს კონსულს მიკროსერვისის IP:PORT-ის საპოვნელად ჯენკინსთან ინტეგრაციისთვის (შემდგომში ჯენკინსის მიკროსერვისი) და უგზავნის მას ასინქრონულ მოთხოვნას ჯენკინსში მშენებლობის დასაწყებად.
2. მოთხოვნის მიღების შემდეგ ჯენკინსის მიკროსერვისი წარმოქმნის და პასუხობს Job ID-ით, რომელიც შემდეგ შეიძლება გამოყენებულ იქნას სამუშაოს შედეგის იდენტიფიცირებისთვის. ამავდროულად, ის იწვევს ჯენკინსში აშენებას REST API ზარის საშუალებით.
3. ჯენკინსი ასრულებს მშენებლობას და დასრულების შემდეგ, აგზავნის ვებ-ჰუკს შესრულების შედეგებით ჯენკინსის მიკროსერვისში.
4. ჯენკინსის მიკროსერვისი, რომელმაც მიიღო ვებჰუკი, წარმოქმნის შეტყობინებას მოთხოვნის დამუშავების დასრულების შესახებ და ანიჭებს მას შესრულების შედეგებს. გენერირებული შეტყობინება იგზავნება RabbitMQ რიგში.
5. RabbitMQ-ის საშუალებით გამოქვეყნებული შეტყობინება აღწევს Flow მიკროსერვისს, რომელიც გაიგებს მისი ამოცანის დამუშავების შედეგს მოთხოვნისა და მიღებული შეტყობინების Job ID-ის შესაბამისობით.

ახლა ჩვენ გვაქვს დაახლოებით 30 მიკროსერვისი, რომლებიც შეიძლება დაიყოს რამდენიმე ჯგუფად:

1. Კონფიგურაციის მართვა.
2. ინფორმაცია და ურთიერთქმედება მომხმარებლებთან (მესინჯერები, ფოსტა).
3. საწყის კოდთან მუშაობა.
4. ინტეგრაცია განლაგების ინსტრუმენტებთან (ჯენკინები, მომთაბარე, კონსული და ა.შ.).
5. მონიტორინგი (გამოშვებები, შეცდომები და ა.შ.).
6. ვებ კომუნალური პროგრამები (UI სატესტო გარემოს მართვისთვის, სტატისტიკის შეგროვებისთვის და ა.შ.).
7. ინტეგრაცია ამოცანების ტრეკერებთან და მსგავს სისტემებთან.
8. სამუშაო ნაკადის მართვა სხვადასხვა ამოცანებისთვის.

სამუშაო პროცესის ამოცანები

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

მოდით შევხედოთ სამუშაო პროცესს, რომელსაც ყველაზე ხშირად ვიყენებთ:

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

სრულად მექანიკური ტესტირება DEV+BETA-ზე კანარის ტესტების გარეშე (ჩვეულებრივ, ასე ვათავისუფლებთ მონოლიტს):

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

დავალების მოძრაობა

მოდით შევხედოთ მთავარ ნაბიჯებს, რომლებიც შესრულებულია, როდესაც დავალება გადადის "DEV ტესტირება + კანარის ტესტები" სამუშაო პროცესში:

1. დეველოპერი ან PM ქმნის დავალებას.

2. დეველოპერი იღებს დავალებას სამუშაოდ. დასრულების შემდეგ ის გადადის IN REVIEW სტატუსზე.

3. Jira აგზავნის Webhook-ს Jira microservice-ში (პასუხისმგებელია Jira-სთან ინტეგრაციაზე).

4. Jira მიკროსერვისი უგზავნის მოთხოვნას Flow სერვისს (პასუხისმგებელია შიდა სამუშაო პროცესებზე, რომლებშიც სამუშაოები შესრულებულია) სამუშაო პროცესის დასაწყებად.

5. Flow სერვისის შიგნით:

• მიმომხილველებს ენიჭებათ დავალება (Users microservice, რომელმაც ყველაფერი იცის მომხმარებლების შესახებ + Jira microservice).
• წყაროს მიკროსერვისის მეშვეობით (მან იცის საცავებისა და ფილიალების შესახებ, მაგრამ თავად კოდით არ მუშაობს), ხდება საცავების ძიება, რომლებიც შეიცავს ჩვენი გამოცემის ფილიალს (ძიების გასამარტივებლად, ფილიალის სახელი ემთხვევა საკითხს. ნომერი ჯირაში). ყველაზე ხშირად, ამოცანას აქვს მხოლოდ ერთი ფილიალი ერთ საცავში; ეს ამარტივებს განლაგების რიგის მართვას და ამცირებს საცავებს შორის დაკავშირებას.
• თითოეული ნაპოვნი ფილიალისთვის ხორციელდება მოქმედებების შემდეგი თანმიმდევრობა:

  ი) სამაგისტრო ფილიალის განახლება (Git microservice კოდთან მუშაობისთვის).
  ii) ფილიალი დაბლოკილია ცვლილებებისგან დეველოპერის მიერ (Bitbucket microservice).
  iii) ამ ფილიალისთვის იქმნება Pull Request (Bitbucket microservice).
  iv) შეტყობინება ახალი Pull Request-ის შესახებ იგზავნება დეველოპერის ჩეთებში (აცნობეთ მიკროსერვისს შეტყობინებებთან მუშაობისთვის).
  v) ამოცანების აგება, ტესტირება და განლაგება დაწყებულია DEV-ზე (ჯენკინსის მიკროსერვისი ჯენკინსთან მუშაობისთვის).
  vi) თუ ყველა წინა ნაბიჯი წარმატებით დასრულდა, მაშინ Integro აყენებს მის დამტკიცებას Pull Request-ში (Bitbucket microservice).

• Integro ელოდება დამტკიცებას გამოყვანის მოთხოვნაში დანიშნული რეცენზენტებისგან.
• როგორც კი მიიღება ყველა საჭირო ნებართვა (მათ შორის, ავტომატური ტესტები დადებითად გაიარა), Integro გადასცემს დავალებას Test on Dev (Jira microservice) სტატუსზე.

6. ტესტერები ამოწმებენ დავალებას. თუ პრობლემები არ არის, მაშინ დავალება გადადის Ready For Build სტატუსზე.

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

8. დავალება გადადის კანარის სტატუსზე (Jira microservice).

9. ჯენკინსი იწყებს განლაგების ამოცანას Nomad-ის მეშვეობით კანარის რეჟიმში (ჩვეულებრივ 1-3 შემთხვევა) და აცნობებს გამოშვების მონიტორინგის სამსახურს (DeployWatch microservice) განლაგების შესახებ.

10. DeployWatch მიკროსერვისი აგროვებს შეცდომის ფონს და საჭიროების შემთხვევაში რეაგირებს მასზე. შეცდომის ფონის გადაჭარბების შემთხვევაში (ფონის ნორმა ავტომატურად გამოითვლება), დეველოპერებს ეცნობებათ Notify microservice-ის მეშვეობით. თუ 5 წუთის შემდეგ დეველოპერმა არ უპასუხა (დააწკაპუნეთ Revert ან Stay), მაშინ იწყება კანარის ინსტანციების ავტომატური დაბრუნება. თუ ფონი არ არის გადაჭარბებული, მაშინ დეველოპერმა ხელით უნდა გაუშვას დავალების განთავსება Production-ში (დაწკაპუნებით ღილაკზე UI-ში). თუ 60 წუთის განმავლობაში დეველოპერმა არ დაიწყო განლაგება წარმოებაში, მაშინ კანარის ინსტანციები ასევე დაბრუნდება უსაფრთხოების მიზეზების გამო.

11. წარმოებაში განლაგების დაწყების შემდეგ:

• დავალება გადადის წარმოების სტატუსზე (Jira microservice).
• ჯენკინსის მიკროსერვისი იწყებს განლაგების პროცესს და აცნობებს DeployWatch მიკროსერვისს განლაგების შესახებ.
• DeployWatch მიკროსერვისი ამოწმებს, რომ ყველა კონტეინერი Production-ზე განახლებულია (იყო შემთხვევები, როცა ყველა არ იყო განახლებული).
• Notify მიკროსერვისის მეშვეობით, შეტყობინება განლაგების შედეგების შესახებ ეგზავნება წარმოებას.

12. დეველოპერებს ექნებათ 30 წუთი, რათა დაიწყონ დავალების უკან დაბრუნება Production-დან, თუ მიკროსერვისის არასწორი ქცევა გამოვლინდება. ამ დროის გასვლის შემდეგ, ამოცანა ავტომატურად გაერთიანდება Master-ში (Git microservice).

13. მასტერში წარმატებული შერწყმის შემდეგ, დავალების სტატუსი შეიცვლება დახურულზე (Jira microservice).

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

რა არის შემდეგი

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

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

წყარო: www.habr.com