DevOps არის პროგრამული უზრუნველყოფის დამუშავებისა და მიწოდების პრაქტიკის შერწყმა.
ტესტერები, რომლებიც მონაწილეობენ DevOps– ის მიწოდების მოდელში, იწყებენ კითხვების დასმას:
ეს პოსტი განიხილავს ინსტრუმენტებს, სტრატეგიებსა და პრაქტიკებს, რომლებიც უნდა განვახორციელოთ DevOps მსოფლიოში ეფექტურად შესამოწმებლად, ავტომატიზაციისა და უწყვეტი ტესტირების მიღებაში DevOps.
როგორ გადაიზარდა ტესტირება ჩანჩქერიდან DevOps- ისკენ?
ტესტირებისა და ხარისხის უზრუნველყოფის პრაქტიკამ მნიშვნელოვანი ცვლილება განიცადა ჩანჩქერის, Agile და ახლა DevOps– ის დღიდან. ჩანჩქერის მოდელში ტესტირება განიხილებოდა, როგორც პროგრამული უზრუნველყოფის განვითარების ციკლის ეტაპი. ტესტერები და ტესტირების ძალისხმევა ძალიან გაუგებარი იყო, სადაც ტესტერები იყვნენ ტესტირების ჯგუფის ნაწილი და ხშირად განცალკევებული იყვნენ განვითარების ჯგუფისგან.
ტესტერები ფლობდნენ ტესტირების სტრატეგია და განიხილებოდნენ, როგორც ხარისხის მეკარეები. ტესტირება ძირითადად სახელმძღვანელო იყო და ეს ხდებოდა პროგრამული უზრუნველყოფის სრულად შემუშავების შემდეგ და წარმოების გამოსვლამდე.
ანალოგიურად, პროგრამული უზრუნველყოფის მიწოდებას დიდი დრო სჭირდებოდა. ცალკეული ოპერატიული გუნდი იყო პასუხისმგებელი პროგრამული უზრუნველყოფის წარმოებაში გამოშვებაზე, რაც, საუკეთესო შემთხვევაში, ხდებოდა რამდენიმე თვეში ერთხელ. კომუნიკაციის / თანამშრომლობის დაბალი დონე არ იყო Ops– ის გუნდსა და Dev– ის გუნდს შორის.
Agile მოდელმა შექმნა ცვლილება განვითარებისა და ტესტირების სივრცეში, ასევე გამოშვების სიხშირეში. პროგრამული უზრუნველყოფა შემუშავდა განმეორებით და ნელა. Scrum, რომელიც მეთოდოლოგიაა Agile მიწოდების მოდელში, სწრაფად გახდა ძალიან პოპულარული.
განვითარების მცდელობად დაიშალა რამდენიმე მოკლე განმეორება, რაც ჩვეულებრივ გრძელდებოდა 2-4 კვირის განმავლობაში. თითოეული განმეორება შექმნის პოტენციურად დატვირთულ პროგრამულ უზრუნველყოფას ახალი ან არსებული მახასიათებლების დამატებით.
ტესტერები შემუშავების ჯგუფის ნაწილი გახდა და ტესტირება გახდა პროგრამული უზრუნველყოფის პარალელური საქმიანობა, ვიდრე SDLC- ის დასრულების ეტაპი. ტესტირების აქტივობა გახდა საერთო პასუხისმგებლობა და ხარისხის გუნდი ეკუთვნოდა განვითარების ჯგუფს.
Agile მოდელმა გააერთიანა განვითარების და ტესტირების პრაქტიკა და გაუხსნა გზა პროგრამული უზრუნველყოფის უფრო სწრაფად მიწოდებას, თუმცა, წარმოება რეალური განაწილება მაინც გააკეთა ცალკეულმა TechOps ჯგუფმა.
მიუხედავად იმისა, რომ TechOps– ის გუნდს უნდა ჰქონოდა ცოდნა სერვერების, ქსელების და განლაგების შესახებ, ისინი ჩვეულებრივ არ იცნობდნენ თითოეული გამოშვების დეტალებს. დეველოპერული გუნდისთვის გამოხმაურება ნელი იყო. თუ გამოცემაში ხარვეზი არსებობდა, ჩვეულებრივ, რამდენიმე საათს დასჭირდებოდა შემუშავების ჯგუფისთვის საკითხის გაცნობა.
DevOps Agile მოდელს კიდევ უფრო ნაბიჯად გადადგამს, გამოშვებისა და განლაგების აქტივობებს უფრო ახლოვდება შემუშავებისა და ტესტირებისთვის. ეს ნიშნავს, რომ სწრაფი გუნდი საკუთარ თავზე აგებს პასუხს მათ მიერ შექმნილი პროგრამული უზრუნველყოფის შემუშავებაზე, ტესტირებაზე და გამოშვებაზე.
ტესტირება DevOps– ში მოიცავს პროგრამული უზრუნველყოფის შემუშავებასა და მიწოდებას მთელი ციკლის განმავლობაში. ტესტერები აღარ არიან ორიენტირებული მხოლოდ ფუნქციონალურ ტესტირებაზე და მახასიათებლების გადამოწმებაზე.
როგორც ტესტერები, ჩვენ ასევე უნდა ვიყოთ ჩართული ოპერაციების ტესტირებაში, შესრულების ტესტირებაში, უსაფრთხოების ბაზისურ ტესტირებაში, ასევე შეგვიძლია წარმოების მონაცემებისა და ჟურნალების მონიტორინგი და ანალიზი.
დენ ეშბის აქვს შესანიშნავი პოსტი DevOps– ში ტესტირების შესახებ, რომელშიც ის აღწერს
თქვენ ხედავთ, რატომ იბრძვიან ადამიანები იმის გასაგებად, თუ სად ჯდება ტესტირება ისეთ მოდელში, რომელიც მას საერთოდ არ ახსენებს. ჩემთვის ტესტირება ჯდება თითოეულ მოდელში.
მართლაც, DevOps მოდელის ტესტირება შეიძლება მოხდეს და უნდა მოხდეს თითოეულ ეტაპზე. იმ სწრაფი ტესტი სტრატეგიის პოსტი , ჩვენ აღვწერეთ თუ როგორ ჯდება ტესტირება Agile მოდელში.
DevOps– ის ტესტირების სტრატეგიას შეუძლია განაგრძოს შემდეგი სექციების დამატება:
DevOps- ის მოდელში ინსტრუმენტებისა და ტექნოლოგიების არჩევანი ასე მნიშვნელოვანი ხდება. ინსტრუმენტების არჩევანი საშუალებას აძლევს ორგანიზაციას, მაღალი სიჩქარით განაცხადებისა და მომსახურებების მიწოდება.
DevOps– ში უფრო მეტი ყურადღება ექცევა ავტომატიზირებულ ტესტირებას, რადგან ჩვენ გვინდა შევქმნათ ისეთი კულტურა, სადაც შეგვიძლია სწრაფად და საიმედოდ ავწიოთ კოდი სისტემებს.
ავტომატიზირებული ფუნქციური ტესტების გარდა, მიწოდების მილსადენში უნდა გვქონდეს აგრეთვე შესრულების ტესტების, ასევე უსაფრთხოების / გამძლეობის ტესტების კომპლექტი.
რა თქმა უნდა, ზემოაღნიშნული ავტომატიზირებული ტესტების განხორციელების შესაძლებლობა, უპირველეს ყოვლისა, არის ავტომატიზირებული მშენებლობისა და მიწოდების მილსადენის მშენებლობა უწყვეტი ინტეგრაციის ინსტრუმენტში, მაგალითად ჯენკინსი.
წარმოებაში ტესტი სულაც არ ნიშნავს თქვენი ფუნქციური / შესრულების ტესტირების სკრიპტების შესრულებას ცოცხალი სისტემის წინააღმდეგ, სადაც მომხმარებლები იყენებენ პროგრამას.
ჩვენ შეგვიძლია დავიწყოთ A / B ან მრავალფეროვანი ტესტების ტენდენციების ანალიზი. ჩვენ ასევე შეგვიძლია სერვერების მონიტორინგი ნებისმიერი უცნაური ქცევისთვის, როგორიცაა მეხსიერების გაჟონვა, პროცესორის მაღალი გამოყენება და ა.შ.
როგორ შეცვალა ამ ყველაფერმა DevOps– ში ტესტერებისა და ტესტირების როლი?
ახლა ტესტერებს უნდა ჰქონდეთ მინიმუმ შემდეგი ცოდნა და უნარები, რათა შეძლონ ეფექტურად განახორციელონ ტესტირების აქტივობები