კურსის სტუდენტებისთვის მომზადებული სტატიის თარგმანი "DevOps პრაქტიკა და ინსტრუმენტები" OTUS საგანმანათლებლო პროექტში.

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

რატომ ვსაუბრობთ ამაზე?

მეტ კლაინმა დაწერა სტატია "მონორეპოსი: ნუ გთხოვ!"  (მთარგმნელის შენიშვნა: თარგმანი ჰაბრეზე "მონორეპოზიტორები: გთხოვთ ნუ"). მეტი მომწონს, ვფიქრობ ძალიან ჭკვიანია და მისი აზრი უნდა წაიკითხო. მან თავდაპირველად გამოკითხვა Twitter-ზე გამოაქვეყნა:

თარგმანი:
ამ ახალ წელს ვაპირებ მსჯელობას იმაზე, თუ რა სასაცილოა მონორეპოზიტორები. 2019 წელი მშვიდად დაიწყო. ამ სულისკვეთებით, მე გთავაზობთ გამოკითხვას. ვინ არიან დიდი ფანატიკოსები? მხარდამჭერები:
- მონორეპო
- Rust
- არასწორი გამოკითხვა / ორივე

ჩემი პასუხი იყო: "მე ფაქტიურად ორივე მათგანი ვარ". იმის ნაცვლად, რომ ვისაუბროთ იმაზე, თუ როგორ არის რუსტი ნარკოტიკი, მოდი ვნახოთ, რატომ ცდება ის მონორეპოზიტორებთან დაკავშირებით. ცოტა რამ საკუთარ თავზე. მე ვარ Chef Software-ის CTO. ჩვენ გვყავს დაახლოებით 100 ინჟინერი, კოდის ბაზა დაახლოებით 11-12 წლის წინ და 4 ძირითადი პროდუქტი. ამ კოდის ნაწილი არის პოლირეპოზიტორიაში (ჩემი საწყისი პოზიცია), ნაწილი არის მონორეპოზიტორიაში (ჩემი ამჟამინდელი პოზიცია).

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

მე ვეთანხმები მეტის მოსაზრების პირველ ნაწილს:

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

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

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

• კოდების ბაზა მოცულობითია - მე არ მჭირდება მთელი ეს ნაგავი.
• უფრო რთულია ტესტირება, რადგან მე უნდა გამოვცადო მთელი ეს ნაგავი, რომელიც არ მჭირდება.
• გარე დამოკიდებულებებთან მუშაობა უფრო რთულია.
• მე მჭირდება საკუთარი ვირტუალური ვერსიის კონტროლის სისტემები.

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

ის პროვოცირებს კომუნიკაციას და აჩვენებს პრობლემებს

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

რაც უფრო რთული ხდება არქიტექტურა, ერთ გუნდს აღარ შეუძლია მისი მარტო მართვა. ძალიან ცოტა ინჟინერს აქვს მთელი სისტემა თავის თავში. ვთქვათ, თქვენ მართავთ გაზიარებულ A კომპონენტს, რომელსაც იყენებენ გუნდები B, C და D. გუნდი A ახდენს რეფაქტორირებას, აუმჯობესებს API-ს და ასევე ცვლის შიდა განხორციელებას. შედეგად, ცვლილებები არ არის თავსებადი უკან. რა რჩევა გაქვთ?

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

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

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

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

შემდეგ უნდა ვისაუბროთ იმაზე, თუ როგორ გამოვალთ ამ სიტუაციიდან:

1. მხარს უჭერს მრავალ შიდა API-ს და მონიშნავს ძველ ალგორითმს, როგორც მოძველებულს, სანამ D არ შეწყვეტს მის გამოყენებას.
2. მრავალჯერადი გამოშვების ვერსიების მხარდაჭერა, ერთი ძველი ინტერფეისით, ერთი ახალი.
3. გადადეთ A-ს ცვლილებების გამოშვება მანამ, სანამ B, C და D ერთდროულად არ მიიღებენ მას.

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

მრავალი ვერსიის გასაშვებად, ჩვენ გვჭირდება ფილიალი. ახლა ჩვენ გვაქვს ორი კომპონენტი - A1 და A2. B და C გუნდები იყენებენ A2-ს, ხოლო D იყენებს A1-ს. ჩვენ გვჭირდება, რომ ყველა კომპონენტი მზად იყოს გამოსაშვებად, რადგან შესაძლოა საჭირო გახდეს უსაფრთხოების განახლებები და სხვა შეცდომების გამოსწორება, სანამ D-ს შეუძლია წინსვლა. პოლირეპოზიტორიაში ჩვენ შეგვიძლია დავმალოთ ეს ხანგრძლივ ტოტში, რომელიც თავს კარგად გრძნობს. monorepository-ში ჩვენ ვაიძულებთ კოდის შექმნას ახალ მოდულში. D გუნდს კვლავ მოუწევს ცვლილებების შეტანა "ძველ" კომპონენტში. ყველას შეუძლია დაინახოს ღირებულება, რომელსაც ჩვენ ვიხდით აქ - ახლა ჩვენ გვაქვს ორჯერ მეტი კოდი და ნებისმიერი შეცდომის გამოსწორება, რომელიც ეხება A1 და A2-ს, უნდა გავრცელდეს ორივეზე. პოლირეპოზიტორიაში განშტოების მიდგომით, ეს იმალება cherry-pick-ის მიღმა. ჩვენ მიგვაჩნია, რომ ღირებულება უფრო დაბალია, რადგან არ არის დუბლირება. პრაქტიკული თვალსაზრისით, ღირებულება იგივეა: თქვენ შექმნით, გამოუშვით და შეინარჩუნებთ ორ დიდწილად იდენტურ კოდის ბაზას, სანამ არ წაშლით ერთ-ერთ მათგანს. განსხვავება ისაა, რომ მონორეპოზიტორიასთან ერთად ეს ტკივილი პირდაპირი და ხილულია. ეს კიდევ უარესია და ეს კარგია.

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

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

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

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

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

ვინ არიან ყველაზე დიდი ფანატიკოსები? მხარდამჭერები:

• მონორეპო

• Rust

• არასწორი გამოკითხვა / ორივე

მისცა ხმა 33 მომხმარებელმა. 13 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com