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

მოდით განვიხილოთ, რატომ არის CI ინსტრუმენტები და CI სრულიად განსხვავებული რამ.

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

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

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

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

თუ თქვენ იცნობთ კითხვას, მაშინ ინსტრუმენტების ჩამოთვლისთანავე, ისინი გეტყვიან, რომ CI არის, როდესაც თქვენ ქმნით და აწარმოებთ ტესტებს Pull Request-ში commit-ისთვის.

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

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

და მათ გადაჭრეს გუნდურად მუშაობის ტკივილი!

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

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

ერთმა დაასრულა ფუნქცია უფრო სწრაფად და გააერთიანა მასტერში.

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

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

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

მათ შექმნეს ყლორტი.

ერთი მოკვდა, ყველაფერი კარგად იყო, დავალება გაართვა.

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

ამ დროის განმავლობაში მეორე დეველოპერმა სხვა რამ გააკეთა.

პირველმა დაასრულა მესამე დავალება.

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

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

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

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

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

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

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

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

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

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

ზოგადად, ინტეგრაცია ნიშნავს თქვენი კოდის აღებას და მასტერში გადატანას.

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

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

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

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

წარმოვიდგინოთ, რომ რატომღაც 2020 წელს ვართ ინტერნეტის გარეშე. და ჩვენ ვმუშაობთ ადგილობრივად. ჩვენ არ გვყავს ჯენკინსი. Ეს კარგია. თქვენ მაინც შეგიძლიათ განაგრძოთ და შექმნათ ადგილობრივი ფილიალი. მასში რაღაც კოდი დაწერე. დავალება 3-4 საათში დავასრულეთ. ჩვენ გადავედით ოსტატზე, გავაკეთეთ git pull და გავაერთიანეთ ჩვენი ფილიალი იქ. მზადაა. თუ ამას ხშირად აკეთებთ, გილოცავთ, თქვენ გაქვთ უწყვეტი ინტეგრაცია!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ის გირჩევთ გამოიყენოთ მსგავსი ტესტი, რათა დარწმუნდეთ, რომ საკმარისი პრაქტიკა გაქვთ.

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

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

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

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

მოკლედ კიდევ ერთხელ შევაჯამებ:

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

კითხვები

რა ვუყოთ არა დაშლილ ამოცანებს?

დაშლა. Რა არის პრობლემა? შეგიძლია მაგალითი მოიყვანო, რომ არის დავალება და არ არის დაშლილი?

არის ამოცანები, რომლებიც არ შეიძლება დაიშალოს სიტყვიდან „სრულიად“, მაგალითად, ისეთები, რომლებიც საჭიროებენ ძალიან ღრმა გამოცდილებას და რომელთა გადაჭრაც შესაძლებელია ერთი თვის განმავლობაში, რათა მიაღწიოთ საჭმლის მომნელებელ შედეგს.

თუ სწორად მესმის, მაშინ არის რაღაც დიდი და რთული ამოცანა, რომლის შედეგი მხოლოდ ერთ თვეში გამოჩნდება?

Დიახ ეს სწორია. დიახ, შედეგის შეფასება შესაძლებელი იქნება არა უადრეს ერთი თვისა.

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

ჯარიმა. მაშინ რა აზრი აქვს?

რა აზრი აქვს ყოველდღე წვრილმანების მოკვლას?

დიახ.

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

გმადლობთ, თემა დახურულია!

(ოლეგ სოროკა) შემიძლია დავამატო? ყველაფერი სწორად თქვი, ერთი ფრაზა მინდა დავამატო.

Ისე.

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

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

სწორად გავიგე, რომ გგონიათ, რომ ზოგადად აზრი არ აქვს ინვესტირებას საინჟინრო პრაქტიკაში, თუ რომელიმე დავალების შესრულებას ერთი თვე სჭირდება?

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

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

ბაზა მხოლოდ წინ მიიწევს, დიახ.

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

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

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

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

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

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

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

ჩატიდან არის შეკითხვა: „თუ განხილვა სავალდებულოა და დიდი დრო სჭირდება, იქნებ ერთი დღე ან მეტი?“

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

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

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

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

Გართულებულია. თუ გსურთ წაიკითხოთ ამბავი გადართვის ფუნქციის შესახებ უფრო დეტალურად, მე ამას გირჩევთ https://trunkbaseddevelopment.com/. და არის მარტინ ფაულერის შესანიშნავი სტატია გადართვის მახასიათებლების შესახებ: რა ტიპები არსებობს, სიცოცხლის ციკლები და ა.შ. გადართვის ფუნქცია რთულია.

და თქვენ ჯერ კიდევ არ უპასუხეთ კითხვას: "ჯენკინსი საჭიროა თუ არა?"

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

ანუ, თუ პრაქტიკა გაქვს, ეს ნიშნავს რომ არ გჭირდება?

Სწორია. მე გირჩევთ Jez Humble ტესტს. იქ ბოლო პუნქტის მიმართ ამბივალენტური დამოკიდებულება მაქვს. მაგრამ ზოგადად, თუ თქვენ გაქვთ სამი რამ, თქვენ მუდმივად ერწყმით, ატარებთ ტესტებს commit-ებზე მასტერში, თქვენ სწრაფად ასწორებთ build-ს მასტერში, მაშინ, ალბათ, სხვა არაფერი დაგჭირდებათ.

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

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

Stop, stop, bash სკრიპტი ასევე კოდია. არ შეეხოთ ჩემს ძველ სიყვარულს.

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

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

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

თუ ვინმეს აქვს შეკითხვები?

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

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

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

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

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

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

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

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

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

დიახ, ეს ყველაფერი ერთმანეთთან არის დაკავშირებული.

ბიზნესებს ასევე ყოველთვის არ ესმით, რომ ამ გზით უნდა წავიდნენ.

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

(დიმიტრი) მე წავიკითხავ განმარტებას ჩატიდან: ”მაგრამ ჩვენ გვჭირდება ბევრი ტესტის გაშუქება სხვადასხვა დონეზე. რამდენი დრო ეთმობა ტესტებს? ეს ცოტა ძვირია და დიდ დროს მოითხოვს“.

(ოლეგი) ეს კლასიკური მცდარი წარმოდგენაა. საკმარისი ტესტები უნდა იყოს იმისთვის, რომ დარწმუნებული იყოთ. უწყვეტი ინტეგრაცია არ არის ის, სადაც ჯერ ტესტების 100% კეთდება და მხოლოდ ამის შემდეგ იწყებ ამ პრაქტიკის გამოყენებას. უწყვეტი ინტეგრაცია ამცირებს თქვენს შემეცნებით დატვირთვას იმის გამო, რომ თითოეული ცვლილება, რომელსაც თვალით ხედავთ, იმდენად აშკარაა, რომ გესმით, ეს რაღაცას დაამტვრევს თუ არა, ტესტების გარეშეც კი. თქვენ შეგიძლიათ სწრაფად შეამოწმოთ ეს თქვენს თავში, რადგან ცვლილებები მცირეა. მაშინაც კი, თუ თქვენ გაქვთ მხოლოდ მექანიკური ტესტერები, ეს მათთვისაც უფრო ადვილია. თქვენ წამოხვედით და თქვით: "ნახე, რამე გატეხილია?" მათ შეამოწმეს და თქვეს: „არა, არაფერი გატეხილია“. რადგან ტესტერმა იცის სად უნდა ეძებოს. თქვენ გაქვთ ერთი commit ასოცირებული კოდის ერთ ნაწილთან. და ეს არის ექსპლუატირებული კონკრეტული ქცევით.

აქ თქვენ, რა თქმა უნდა, მორთული.

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

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

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

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

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

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

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

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

(დიმიტრი) აქ ბევრს, როცა MVP-ს უწოდებენ, ძალიან ეზარებათ რაიმე ნორმალური დაწერონ. და ეს მაინც სხვადასხვა რამეა. არ არის საჭირო MVP გადააქციოთ ცუდ რამედ, რომელიც არ მუშაობს.

დიახ, დიახ, თქვენ მართალი ხართ.

და შემდეგ მოულოდნელად MVP პროდ.

სამუდამოდ.

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

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

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

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

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

ვიდეო (ჩასმულია როგორც მედია ელემენტი, მაგრამ რატომღაც არ მუშაობს):

https://youtu.be/zZ3qXVN3Oic

წყარო: www.habr.com