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

კოდის დაწერის შემდეგ, თქვენ უნდა დარწმუნდეთ, რომ ის:

1. მუშაობს
2. ეს არ არღვევს არაფერს, მათ შორის თქვენს კოლეგებს დაწერილ კოდს.

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

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

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

როგორ განხორციელდა და განვითარდა უწყვეტი ინტეგრაცია Avito-ს მობილური დეველოპერების გუნდში, როგორ გადავიდნენ ისინი 0-დან 450-მდე აშენებამდე დღეში და რომ კონსტრუქციული მანქანები აწყობენ დღეში 200 საათს, ამბობს ნიკოლაი ნესტეროვი (ნნესტეროვი) არის CI/CD Android აპლიკაციის ყველა ევოლუციური ცვლილების მონაწილე.

სიუჟეტი დაფუძნებულია Android ბრძანების მაგალითზე, მაგრამ მიდგომების უმეტესობა გამოიყენება iOS-ზეც.

ერთხელ Avito Android-ის გუნდში ერთი ადამიანი მუშაობდა. განმარტებით, მას არაფერი სჭირდებოდა უწყვეტი ინტეგრაციისგან: არ იყო ვინმესთან ინტეგრირება.

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

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

ამოწმებს

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

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

იმის გასაგებად, თუ როგორ უნდა განხორციელდეს ეს შემოწმებები, გადავხედოთ განვითარების პროცესს Avito-ში.

ის შეიძლება წარმოდგენილი იყოს სქემატურად ასე:

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

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

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

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

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

იმ დროს, ჩვენი ყველა კონსტრუქცია საკმაოდ სწრაფად დასრულდა, ამიტომ ჩვენ უბრალოდ ჩავრთეთ ARK build, Junit ტესტები და კოდის დაფარვის გამოთვლები, როგორც ბლოკერი pull-ის მოთხოვნისთვის. ჩვენ ჩავრთეთ, ვიფიქრეთ და უარი თქვით კოდის დაფარვაზე, რადგან გვეგონა, რომ ეს არ გვჭირდებოდა.

ორი დღე დაგვჭირდა ძირითადი CI-ის სრულად დაყენებას (შემდგომში დროის შეფასება არის მიახლოებითი, საჭირო მასშტაბისთვის).

ამის შემდეგ ჩვენ დავიწყეთ შემდგომი ფიქრი - ვამოწმებთ კი სწორად? სწორად ვმართავთ აწყობებს pull-ის მოთხოვნებს?

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

ამისათვის ჩვენ დავწერეთ მარტივი bash სკრიპტი premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

სამი დღე დასჭირდა პრობლემის ლოკალიზაციას, გამოსავლის პოვნას და ამ სკრიპტის დაწერას.

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

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

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

დეველოპერები ასრულებენ სამუშაოს და ხსნიან მოთხოვნის მოთხოვნას ამავე დროს. builds დაწყებულია, premerge.sh ამოწმებს ორივე pull მოთხოვნას უახლესი განვითარების მდგომარეობის შესახებ - ყველა შემოწმება მწვანეა. ამის შემდეგ გაერთიანდება A მახასიათებლის pull მოთხოვნა, B მახასიათებლის pull მოთხოვნა... ბუმ! განავითარეთ შესვენებები, რადგან განვითარების კოდი შეიცავს ზარს არარსებულ ფუნქციაზე.

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

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

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

როგორ არ დაარღვიოს განვითარდეს

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

იმის გასაგებად, რამდენი ხანი დასჭირდება ამას, განიხილეთ მაგალითი ორი PR-ით. ჩვენ ვხსნით ორ PR-ს: ორი აშენება, ორი გაშვება ჩეკები. მას შემდეგ, რაც პირველი პიარი გაერთიანდება განვითარებად, მეორე უნდა აღდგეს. საერთო ჯამში, ორი PR მოითხოვს შემოწმების სამ სერიას: 2 + 1 = 3.

პრინციპში, კარგია. მაგრამ ჩვენ გადავხედეთ სტატისტიკას და ჩვენს გუნდში ტიპიური სიტუაცია იყო 10 ღია პიარი, შემდეგ კი შემოწმებების რაოდენობა არის პროგრესის ჯამი: 10 + 9 +... + 1 = 55. ანუ, მივიღოთ 10. PR-ები, თქვენ უნდა გადააკეთოთ 55-ჯერ. და ეს არის იდეალურ სიტუაციაში, როდესაც ყველა შემოწმება გადის პირველად, როდესაც არავინ ხსნის დამატებით მოთხოვნას, სანამ ეს ათეული დამუშავებულია.

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

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

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

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

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

ამ მოდულის დანერგვამდე, ჩვენ საშუალოდ 2,7 მიმოხილვის გაშვებას ვადგენდით თითო მოთხოვნის მოთხოვნით. მოდულით იყო 3,6 გაშვება. ეს შეგვეფერა.

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

Bitbucket მოდულის პირველი ვერსიის დასაწერად ორი კვირა დაგვჭირდა.

ახალი ჩეკები

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

ჩვენ ვფიქრობდით: რატომ დაუშვით შეცდომები, თუ მათი თავიდან აცილება შესაძლებელია? და ამიტომ განახორციელეს სტატიკური კოდის ანალიზი. დავიწყეთ lint-ით, რომელიც შედის Android SDK-ში. მაგრამ იმ დროს მან საერთოდ არ იცოდა კოტლინის კოდით მუშაობა და ჩვენ უკვე გვქონდა კოტლინში დაწერილი აპლიკაციის 75%. ამიტომ, ჩაშენებული პირობა დაემატა lint Android Studio ამოწმებს.

ამისთვის ბევრი გარყვნილება მოგვიწია: ავიღეთ Android Studio, ჩაალაგეთ Docker-ში და გაუშვით CI-ზე ვირტუალური მონიტორით, ისე რომ იფიქროს, რომ მუშაობს ნამდვილ ლეპტოპზე. მაგრამ იმუშავა.

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

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

Firebase ტესტის ლაბორატორია

ის შეირჩა იმიტომ, რომ Firebase არის Google-ის პროდუქტი, რაც იმას ნიშნავს, რომ ის საიმედო უნდა იყოს და ნაკლებად სავარაუდოა, რომ ოდესმე მოკვდეს. ფასები გონივრულია: რეალური მოწყობილობის მუშაობის საათში 5$, ემულატორის მუშაობის საათში 1$.

Firebase ტესტის ლაბორატორიის ჩვენს CI-ში დანერგვას დაახლოებით სამი კვირა დასჭირდა.

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

დოკერი + პითონი + ბაში

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

ხუთი კვირა დასჭირდა საკუთარი სატესტო გარემოს შექმნას.

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

• ARK შეკრება;
• ჯუნიტის ტესტები;
• ლინტი;
• Android Studio ამოწმებს;
• ინსტრუმენტული ტესტები;
• სკრინშოტის ტესტები.

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

რამდენი ხანია ძალიან გრძელი? ჩვენ ავტვირთეთ მონაცემები Bitbucket-დან და TeamCity-დან ანალიზის სისტემაში და მივხვდით ამას ლოდინის საშუალო დრო 45 წუთი. ანუ, დეველოპერი, pull-ის მოთხოვნის გახსნისას, საშუალოდ 45 წუთს ელოდება მშენებლობის შედეგებს. ჩემი აზრით, ეს ბევრია და ასე მუშაობა არ შეიძლება.

რა თქმა უნდა, ჩვენ გადავწყვიტეთ დავაჩქაროთ ყველა ჩვენი აშენება.

დავაჩქაროთ

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

ჩეკების წაშლა, რომლებსაც ძალიან დიდი დრო სჭირდება

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

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

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

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

შედეგად, ჩვენ დავრჩით:

• ARK შეკრება;
• ჯუნიტის ტესტები;
• ინსტრუმენტული ტესტები.

Gradle დისტანციური ქეში

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

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

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

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

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

ქვემოთ მოცემულია ქეში გამოტოვებული გრაფიკი.

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

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

ზემოქმედების ანალიზი

pull-ის მოთხოვნით, ჩვენ ვაგროვებთ git diff-ს და ვპოულობთ შეცვლილ Gradle მოდულებს.

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

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

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

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

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

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

ექვსი კვირა დაიხარჯა დეტალურ გამოხმაურებაზე.

გეგმები

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

გარდა ამისა, არსებობს სხვა გეგმები.

• დააბრუნეთ ლინტი (და სხვა სტატიკური ანალიზი). ჩვენ უკვე ვმუშაობთ ამ მიმართულებით.
• გაუშვით ყველაფერი PR ბლოკერზე ბოლოდან ბოლომდე ტესტები ყველა SDK ვერსიაზე.

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

Советы

მხოლოდ ერთი რჩევა რომ შემეძლოს, ეს იქნებოდა:

გთხოვთ, ფრთხილად იყავით shell სკრიპტებთან!

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

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

#!/usr/bin/env bash
./gradlew assembleDebug

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

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

რა შეიძლება შეიცვალოს?

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

ჩვენ გადავწყვიტეთ ავირჩიოთ მეორე ვარიანტი და ახლა სისტემატურად ვშლით ყველა bash სკრიპტს და ვწერთ უამრავ პერსონალურ gradle ამოცანას.

რჩევა #2: შეინახეთ ინფრასტრუქტურა კოდით.

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

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

რჩევა #3: Docker-ს შეუძლია დაეხმაროს გარემოსთან.

ის ნამდვილად დაეხმარება Android-ის დეველოპერებს; iOS-ს ჯერ არ აქვს, სამწუხაროდ.

ეს არის მარტივი docker ფაილის მაგალითი, რომელიც შეიცავს jdk და android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

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

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

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

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

რჩევა #5: იყავით პრაგმატული უწყვეტი ინტეგრაციის განვითარებისას.

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

რჩევა #6: გამოიყენეთ მზა ხელსაწყოები.

ახლა ბევრი კომპანიაა, რომლებიც უზრუნველყოფენ ღრუბელ CI-ს.

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

რჩევა #7: დიდ გუნდში შიდა გადაწყვეტილებები უფრო მომგებიანია.

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

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

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

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

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

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

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

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

წყარო: www.habr.com