საუკეთესო DevOps პრაქტიკა დეველოპერებისთვის. ანტონ ბოიკო (2017)

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

ნება მომეცით წარმოგიდგინოთ ჩემი თავი, სრულად ვაღიარებ, რომ ოთახში არიან ადამიანები, რომლებიც არ მიცნობენ. მე მქვია ანტონ ბოიკო, მე ვარ Microsoft Azure MVP. რა არის MVP? ეს არის Model-View-Presenter. Model-View-Presenter ზუსტად მე ვარ.

გარდა ამისა, ამჟამად მე ვიკავებ გადაწყვეტის არქიტექტორის პოზიციას Ciklum-ში. ახლახანს შევიძინე ასეთი ლამაზი დომენი და განვაახლე ჩემი ელ.წერილი, რომელსაც ჩვეულებრივ ვაჩვენებ პრეზენტაციებზე. შეგიძლიათ მომწეროთ: me [ძაღლი] byokoant.pro. შეგიძლიათ მომწეროთ კითხვებით. მე ჩვეულებრივ ვპასუხობ მათ. ერთადერთი ის არის, რომ მე არ მინდა მივიღო კითხვები ელექტრონული ფოსტით, რომლებიც ეხება ორ თემას: პოლიტიკას და რელიგიას. სხვა ყველაფრის შესახებ შეგიძლიათ მომწეროთ ელექტრონული ფოსტით. ცოტა დრო გავა, გიპასუხებ.

რამდენიმე სიტყვა საკუთარ თავზე:

• უკვე 10 წელია ამ სფეროში ვარ.
• მაიკროსოფტში ვმუშაობდი.
• მე ვარ უკრაინული აზურ თემის დამფუძნებელი, რომელიც სადღაც 2014 წელს დავაარსეთ. ჩვენ ჯერ კიდევ გვაქვს და ვავითარებთ მას.
• მე ასევე ვარ Azure-ის კონფერენციის დამფუძნებლის მამა, რომელსაც ვუმასპინძლებთ უკრაინაში.
• მე ასევე ვეხმარები კიევში Global Azure Bootcamp-ის ორგანიზებას.
• როგორც ვთქვი, მე ვარ Microsoft Azure MVP.
• საკმაოდ ხშირად ვსაუბრობ კონფერენციებზე. ძალიან მიყვარს კონფერენციებზე საუბარი. გასული წლის განმავლობაში დაახლოებით 40-ჯერ მოვახერხე შესრულება. თუ თქვენ გაივლით უკრაინას, ბელორუსიას, პოლონეთს, ბულგარეთს, შვედეთს, დანიას, ნიდერლანდებს, ესპანეთს ან აძლევთ ან აიღებთ ევროპის სხვა ქვეყანას, მაშინ სავსებით შესაძლებელია, რომ როდესაც მიდიხართ კონფერენციაზე, რომელსაც აქვს ღრუბლის თემა. თქვენ შეიძლება მნახოთ მომხსენებელთა სიაში.
• ასევე ვარ Star Trek-ის ფანი.

მოდით ვისაუბროთ ცოტა დღის წესრიგზე. ჩვენი დღის წესრიგი ძალიან მარტივია:

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

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

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

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

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

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

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

ამ სლაიდს მეორე არაოფიციალური სახელიც აქვს. შეგიძლიათ ინტერნეტში მოძებნოთ, რათა გაიგოთ, რა არის DevOps-ის 3 მუშკეტერი. შესაძლებელია, რომ თქვენ იპოვით ამ სტატიას. რატომ 3 მუშკეტერი? ქვემოთ წერია: ადამიანები, პროცესები და პროდუქტები, ე.ი. PPP – პორთოსი, პორთოსი და პორთოსი. აქ არის DevOps-ის 3 მუშკეტერი. ეს სტატია უფრო დეტალურად აღწერს, თუ რატომ არის ეს მნიშვნელოვანი და რას გულისხმობს.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ასევე, როცა კოდს ერთმანეთში აერთიანებთ, ე.ი. ბრძანებას შორის, ეს საშუალებას გაძლევთ ასევე ნახოთ, თუ როგორ გამოიყურება ის UI-ზე.

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

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

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

მაგრამ პრობლემა სხვა იყო. როდესაც ჩვენ განვათავსეთ ჩვენი php საიტის ახალი ვერსია, როგორ განვათავსეთ იგი? ყველაზე ხშირად ვხსნიდით Far Manager ან სხვა რამეს. და ატვირთე ეს ფაილები FTP-ზე. და ჩვენ უცებ მივხვდით, რომ ჩვენ გვქონდა პატარა, პატარა შეცდომა, მაგალითად, დაგვავიწყდა მძიმით დავსვა ან დაგვავიწყდა მონაცემთა ბაზის პაროლის შეცვლა და არის პაროლი მონაცემთა ბაზისთვის, რომელიც არის ლოკალურ ჰოსტზე. ჩვენ გადავწყვიტეთ სწრაფად დავუკავშირდეთ FTP-ს და დაარედაქტიროთ ფაილები. ეს მხოლოდ ცეცხლია! ეს არის ის, რაც პოპულარული იყო 90-იან წლებში.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

რატომ? რა თქმა უნდა, კარგი იქნება, თუ თითოეულ დეველოპერს ექნება ვირტუალური მანქანა, რომელიც იმუშავებს 24/7. მაგრამ, ალბათ, ეს თქვენთვის სიახლეა, შესაძლოა, ყურადღება არ მიაქციეთ, მაგრამ თავად დეველოპერი არ მუშაობს 24/7. დეველოპერი ჩვეულებრივ მუშაობს დღეში 8 საათის განმავლობაში. მაშინაც კი, თუ ის სამსახურში ადრე მოდის, მას აქვს დიდი ლანჩი, რომლის დროსაც ის დადის სპორტდარბაზში. დაე, იყოს დღეში 12 საათი, როდესაც დეველოპერი რეალურად იყენებს ამ რესურსებს. ჩვენი კანონმდებლობით, კვირაში 5 დღედან 7 გვაქვს სამუშაო დღეებად.

შესაბამისად, სამუშაო დღეებში ეს მანქანა არ უნდა მუშაობდეს 24 საათის განმავლობაში, არამედ მხოლოდ 12 საათის განმავლობაში, ხოლო შაბათ-კვირას ეს მანქანა საერთოდ არ უნდა მუშაობდეს. როგორც ჩანს, ყველაფერი ძალიან მარტივია, მაგრამ რა არის აქ სათქმელი? ამ მარტივი პრაქტიკის განხორციელებით ამ ძირითად გრაფიკზე, ის საშუალებას გაძლევთ შეამციროთ ამ გარემოს შენარჩუნების ღირებულება 70%-ით, ანუ თქვენ აიღეთ თქვენი დეველოპმენტის, QA, დემო, გარემოს ფასი და გაყავით 3-ზე.

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

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

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

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

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

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

გასაგებია მადლობა!

თუ კითხვები არ არის, ვფიქრობ, შეგვიძლია დავასრულოთ. Გმადლობთ!

წყარო: www.habr.com