უწყვეტი ინტეგრაციის მაგალითი BuildBot-თან

(სურათი კომპიუტერიზატორი საწყისი Pixabay)

Hi!

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

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

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

ინფორმაციის

ინფორმაციის

1. რატომ BuildBot?
2. კონცეფცია, რომელსაც ხელმძღვანელობს BuildMaster
3. მონტაჟი
4. პირველი ნაბიჯები

5. კონფიგურაცია. ეტაპობრივად რეცეპტი

5.1 BuildmasterConfig
5.2 მუშები
5.3 change_source
5.4 გრაფიკები

5.5 BuildFactory
5.6 მშენებელი

6. საკუთარი კონფიგურაციის მაგალითი

6.1 თქვენი ბატონისკენ მიმავალ გზაზე.cfg
6.2 მუშაობა svn
6.3 წერილი თქვენ: რეპორტიორებს უფლება აქვთ განაცხადონ

Ჩვენ ეს შევძელით! გილოცავ

1. რატომ BuildBot?

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

გაჩერდი! ვინმეს ნამდვილად გამოიყენა იგი თავის პროექტებში? გამოდის კი многие გამოიყენეს იგი თავიანთ ამოცანებში. შეიძლება მოიძებნოს მაგალითები გამოყენება BuildBot და Google კოდების არქივებში.

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

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

ასე რომ, ჩვენი "ინსტრუმენტული კვარტეტი". ჩემთვის მე გამოვყავი ოთხი თვისება BuildBot:

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

2. კონცეფცია, რომელსაც ხელმძღვანელობს BuildMaster

ამოცანების განაწილების არქიტექტურაში ცენტრალურია BuildMaster. ეს არის სერვისი, რომელიც:

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

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

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

BuildMaster გადასცემს ბრძანებებს ყველას მუშა-y და ის, თავის მხრივ, ასრულებს მათ. ანუ, გამოდის, რომ პროექტის აშენების და ტესტირების პროცესი შეიძლება გაგრძელდეს მუშა-e მუშაობს Windows-ზე და სხვა Worker-ზე, რომელიც მუშაობს Linux-ზე.

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

3. მონტაჟი

მაშ, წავიდეთ. მე გამოვიყენებ Ubuntu 18.04-ს, როგორც მასპინძელს. ერთს დავდებ მასზე BuildMaster-ა და ერთი მუშა-ა. მაგრამ ჯერ უნდა დააინსტალიროთ python3.7:

sudo apt-get update
sudo apt-get install python3.7

მათთვის, ვისაც 3.7.2-ის ნაცვლად python3.7.1 სჭირდება, შეგიძლიათ გააკეთოთ შემდეგი:

sudo apt-get update
sudo apt-get software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get install python3.7
sudo ln -fs /usr/bin/python3.7 /usr/bin/python3
pip3 install --upgrade pip

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

/*Все что под sudo будет установленно для всех пользователей в директорию /usr/local/lib/python3.7/dist-packages*/

#На хосте который производит мониторинг Worker-ов 
sudo pip install twisted #Библиотека twisted
sudo pip install buildbot #BuildMaster
#Дополнительный функционал
pip install pysqlite3 #Устанавливаем базу sqllite в учебных целях
pip install jinja2 #framework наподобие django, для web и для почтовых рассыллок
pip install autobahn #Web cокеты для связи BuildMaster->Worker
pip install sqlalchemy sqlalchemy-migrate #Для отображения схемы базы данных
#Для Web отображения BuildBot-a
pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view
pip install python-dateutil #Отображение дат в web
#На стороне хоста который непосредственно осуществляет сборку и тестирование 
pip install buildbot-worker #Worker
#Дополнительный функционал
sudo pip install virtualenv #Виртуальная среда 

4. პირველი ნაბიჯები

შექმნის დრო BuildMaster. ის ჩვენს საქაღალდეში იქნება /სახლი/ჰაბრ/ოსტატი.

mkdir master
buildbot create-master master # Собственно сдесь и создаем

Შემდეგი ნაბიჯი. შევქმნათ მუშა. ის ჩვენს საქაღალდეში იქნება /სახლი/ჰაბრ/მუშა.

mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password

როცა გარბიხარ მუშა, შემდეგ ნაგულისხმევად შეიქმნება /სახლი/ჰაბრ/მუშა საქაღალდე პროექტის სახელწოდებით, რომელიც მითითებულია master.cfg. და პროექტის სახელწოდების საქაღალდეში ის შექმნის დირექტორიას ავაშენოთდა გააგრძელებს ამას გადმოტანა. სამუშაო დირექტორია ამისთვის მუშა-და გახდება დირექტორია /home/habr/yourProject/build.

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

BuildMaster и მუშა დაამყარონ კავშირი ერთმანეთთან. ხდება ისე, რომ წყდება და მუშა ელოდება გარკვეული დროის პასუხს BuildMaster-ა. თუ პასუხი არ არის, კავშირი განახლდება. Გასაღები --keepalive=60 უბრალოდ საჭიროა მიუთითოთ დრო, რომლის შემდეგაც დაკავშირება გადატვირთავს.

5. კონფიგურაცია. ეტაპობრივად რეცეპტი

კონფიგურაცია BuildMaster ხორციელდება აპარატის მხარეს, სადაც ჩვენ შევასრულეთ ბრძანება შექმნა-ოსტატი. ჩვენს შემთხვევაში, ეს არის დირექტორია /სახლი/ჰაბრ/ოსტატი. კონფიგურაციის ფაილი master.cfg ჯერ არ არსებობს, მაგრამ თავად ბრძანებამ უკვე შექმნა ფაილი master.cmg.sample. თქვენ უნდა გადაარქვათ სახელი master.cfg.sample в master.cfg

mv master.cfg.sample master.cfg

მოდით გავხსნათ ეს master.cfg. და მოდით შევხედოთ რისგან შედგება. და ამის შემდეგ, მოდით ვცადოთ საკუთარი კონფიგურაციის ფაილის შექმნა.

master.cfg

c['change_source'] = []
c['change_source'].append(changes.GitPoller(
    'git://github.com/buildbot/hello-world.git',
         workdir='gitpoller-workdir', branch='master',
         pollInterval=300))
                        
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
        name="all",
        change_filter=util.ChangeFilter(branch='master'),
        treeStableTimer=None,
        builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
        name="force",
        builderNames=["runtests"]))
                        
factory = util.BuildFactory()
                        
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
                                   env={"PYTHONPATH": "."}))
                        
c['builders'] = []
c['builders'].append(
    util.BuilderConfig(name="runtests",
    workernames=["example-worker"],
    factory=factory))
                         
c['services'] = []
                        
c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
                        
                        
c['buildbotURL'] = "http://localhost:8010/"
                        
c['www'] = dict(port=8010,
                plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
                        
c['db'] = {
    'db_url' : "sqlite:///state.sqlite",
}

5.1 BuildmasterConfig

c = BuildmasterConfig = {} 

BuildmasterConfig — კონფიგურაციის ფაილის ძირითადი ლექსიკონი. ის უნდა იყოს ჩართული კონფიგურაციის ფაილში. მოხერხებულობისთვის, კონფიგურაციის კოდში შემოტანილია მეტსახელი "c". ტიტულები გასაღებები в c["keyFromDist"] არის ფიქსირებული ელემენტები ურთიერთქმედებისთვის BuildMaster. თითოეული გასაღებისთვის, შესაბამისი ობიექტი ჩანაცვლებულია მნიშვნელობის სახით.

5.2 მუშები

c['workers'] = [worker.Worker("example-worker", "pass")]

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

5.3 change_source

c['change_source'] = []
c['change_source'].append(changes.GitPoller(
                            'git://github.com/buildbot/hello-world.git',
                             workdir='gitpoller-workdir', branch='master',
                             pollInterval=300))                

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

პირველი არგუმენტი არის გზა თქვენი საცავამდე.

სამუშაო დირიჟორი წარმოადგენს გზას საქაღალდისკენ, სადაც გვერდითაა მუშა-გზის ნათესავი /home/habr/worker/yourproject/build git შეინახავს საცავის ლოკალურ ვერსიას.

ფილიალი შეიცავს კონკრეტულ ფილიალს საცავში, რომელიც უნდა დაიცვას.

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

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

უმარტივესი მეთოდია გამოკითხვა, რაც გულისხმობს იმას BuildMaster პერიოდულად გამოკითხავს სერვერს საცავთან ერთად. თუ ჩაიდინოს აისახა ცვლილებები საცავში, მაშინ BuildMaster გარკვეული დაგვიანებით შექმნის შიდა ობიექტს შეცვლა და გაუგზავნეთ ღონისძიების დამმუშავებელს Scheduler, რომელიც დაიწყებს პროექტის აშენებისა და ტესტირების ნაბიჯებს მუშა-ე. ამ ნაბიჯებს შორის იქნება მითითებული განახლება საცავი. ზუსტად მუშაეს შექმნის საცავის ლოკალურ ასლს. ამ პროცესის დეტალები ქვემოთ იქნება განხილული მომდევნო ორ ნაწილში. (5.4 и 5.5).

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

5.4 გრაფიკები

c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
        name="all",
        change_filter=util.ChangeFilter(branch='master'),
        treeStableTimer=None,
        builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
        name="force",
        builderNames=["runtests"]))

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


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

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

ForceScheduler ძალიან მარტივი რამ. ამ ტიპის განრიგი გამოწვეულია მაუსის დაწკაპუნებით BuildBot- ვებ ინტერფეისი. პარამეტრებს აქვთ იგივე არსი, რაც აქ SingleBranchScheduler.

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

from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
                              builderNames=["full-solaris"],
                              periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]                    

5.5 BuildFactory

factory = util.BuildFactory()
                        
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
                                   env={"PYTHONPATH": "."}))

periodicBuildTimer განსაზღვრავს ამ პერიოდულობის დროს წამებში.

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

პირველი დამატებული ნაბიჯი ამ მაგალითში არის git სუფთა -d -f -f –x, მაშინ git გადახდა. ეს მოქმედებები შედის პარამეტრში მეთოდი, რომელიც მკაფიოდ არ არის ნათქვამი, მაგრამ გულისხმობს ნაგულისხმევ მნიშვნელობას სუფთა... Პარამეტრი რეჟიმი='დამატებითი' მიუთითებს, რომ ფაილები არის იმ დირექტორიადან, სადაც ჩეჩუტი, მიუხედავად იმისა, რომ არ არის საცავიდან, რჩება ხელუხლებელი.

მეორე დამატებული ნაბიჯი არის სკრიპტის გამოძახება სასამართლო პროცესი პარამეტრით მიესალმები გვერდზე მუშა-ა დირექტორიადან /home/habr/worker/yourproject/build გარემოს ცვლადით PATHONPATH=... ამრიგად, თქვენ შეგიძლიათ დაწეროთ საკუთარი სკრიპტები და შეასრულოთ ისინი გვერდზე მუშა- ყოველ ნაბიჯზე უტილ.ShellCommand. ეს სკრიპტები შეიძლება განთავსდეს პირდაპირ საცავში. შემდეგ ზე ჩეჩუტი-ე ჩავარდებიან /home/habr/worker/yourproject/build. თუმცა, მაშინ არსებობს ორი "მაგრამ":

1. მუშა უნდა შეიქმნას გასაღებით --უმასკი ისე, რომ არ დაბლოკოს აღსრულების უფლებები შემდეგ გადმოტანა-ა.
2. at გიტ ბიძგი-e ამ სკრიპტებიდან თქვენ უნდა მიუთითოთ საკუთრება აღსასრულებელიასე რომ მოგვიანებით ჩეჩუტი-e-მ არ დაკარგა Git სკრიპტის შესრულების უფლება.

5.6 მშენებელი

c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
                                        workernames=["example-worker"],
                                        factory=factory))

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

c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
                                            workernames=["yourWorkerName"],
                                            factory=factory))

ახლა მე გეტყვით პარამეტრებზე BuilderConfig.

სახელი სახელს აზუსტებს მშენებელი-ა. აქ ჩვენ დავასახელეთ თქვენი პროექტი... ეს ნიშნავს, რომ on მუშა- სწორედ ეს გზა შეიქმნება /home/habr/worker/yourproject/build. შედულერი ძებნა მშენებელი მხოლოდ ამ სახელით.

მუშაკთა სახელები შეიცავს ფურცელს მუშა-ს. რომელთაგან თითოეული უნდა დაემატოს გ['მუშაკები'].

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

6. საკუთარი კონფიგურაციის მაგალითი

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

ჩვენ გამოვიყენებთ როგორც ვერსიის კონტროლის სისტემას svn. თავად საცავი განთავსდება რაიმე სახის ღრუბელში. აქ არის ამ ღრუბლის მისამართი svn.host/svn/yourProject/trunk. ღრუბელში ქვეშ svn არის ანგარიშის მომხმარებლის სახელი: მომხმარებელი, passwd: დაგავიწყდათ. სკრიპტები, რომლებიც წარმოადგენენ ნაბიჯებს ავაშენოთ-ა ასევე იქნება ფილიალში svn, ცალკე საქაღალდეში buildbot/worker_linux. ეს სკრიპტები განთავსებულია საცავში შენახული თვისებით შესრულებადი.

BuildMaster и მუშა გაუშვით იმავე მასპინძელზე პროექტი.მასპინძელი .BuildMaster ინახავს მის ფაილებს საქაღალდეში /სახლი/ჰაბრ/ოსტატი. მუშა ის ინახება შემდეგ გზაზე /სახლი/ჰაბრ/მუშა. პროცესის კომუნიკაცია BuildMaster-ა და მუშა-ა ხორციელდება პორტი 4000 პროტოკოლის მიხედვით BuildBot-ა, ანუ 'pb' ოქმი.

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

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

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

ფოსტისთვის საჭიროა ჰოსტი smtp.your.domain - ის იძლევა წერილების გაგზავნის საშუალებას ფოსტიდან [ელ.ფოსტით დაცულია] ავტორიზაციის გარეშე. ასევე მასპინძელზე'SMTP 1025 ფოსტაზე ოქმების მოსმენა ხდება.

პროცესში ჩართულია ორი ადამიანი: admin и მომხმარებელი. ადმინისტრატორი BuildBot. მომხმარებელი არის პირი, რომელიც ახორციელებს ჩაიდინოს-ს.

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

ამ არქიტექტურისთვის მე დავწერე ეს: master.cfg:

master.cfg

import os, re
from buildbot.plugins import steps, util, schedulers, worker, changes, reporters

c= BuildmasterConfig ={}

c['workers'] = [ worker.Worker('yourWorkerName', 'password') ]
c['protocols'] = {'pb': {'port': 4000}} 


svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
                                svnuser="user",
                                svnpasswd="password",
                                pollinterval=60,
				split_file=util.svn.split_file_alwaystrunk
                                )

c['change_source'] =  svn_poller

hourlyscheduler = schedulers.SingleBranchScheduler(
                                name="your-project-schedulers",
				change_filter=util.ChangeFilter(branch=None),
                                builderNames=["yourProject"],
				properties = {'owner': 'admin'}
                                )

c['schedulers'] = [hourlyscheduler]

checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
                        mode='full',
                        method='fresh',
                        username="user",
                        password="password",
                        haltOnFailure=True)

	
projectHost_build = util.BuildFactory()  


cleanProject = steps.ShellCommand(name="Clean",
                 command=["buildbot/worker_linux/pyinstaller_project", "clean"]
                                )
buildProject = steps.ShellCommand(name="Build",
                 command=["buildbot/worker_linux/pyinstaller_project", "build"]
                                )
doxyProject = steps.ShellCommand(name="Update Docs",
                                command=["buildbot/worker_linux/gendoc", []]
                                )
testProject = steps.ShellCommand(name="Tests",
                                command=["python","tests/utest.py"],
                                env={'PYTHONPATH': '.'}
                                )

projectHost_build.addStep(checkout)
projectHost_build.addStep(cleanProject)
projectHost_build.addStep(buildProject)
projectHost_build.addStep(doxyProject)
projectHost_build.addStep(testProject)


c['builders'] = [
        util.BuilderConfig(name="yourProject", workername='yourWorkerName', factory=projectHost_build)
]


template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''

sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
					sendToInterestedUsers=True,
					lookup="your.domain",
					relayhost="smtp.your.domain",
					smtpPort=1025,
					mode="warnings",
					extraRecipients=['[email protected]'],
              messageFormatter=reporters.MessageFormatter(
						template=template_html,
						template_type='html',
						wantProperties=True, 
                                                wantSteps=True)
					)
c['services'] = [sendMessageToAll]

c['title'] = "The process of bulding"
c['titleURL'] = "http://project.host:80/"

c['buildbotURL'] = "http://project.host"

c['www'] = dict(port=80,
                plugins=dict(waterfall_view={}, console_view={}, grid_view={}))


c['db'] = {
    'db_url' : "sqlite:///state.sqlite"
}

ჯერ გჭირდება შექმნა BuildMaster-ა და მუშა-ა. შემდეგ ჩასვით ეს ფაილი master.cfg в /სახლი/ჰაბრ/ოსტატი.

შემდეგი ნაბიჯი არის სერვისის დაწყება BuildMaster- ა

sudo buildbot start /home/habr/master

შემდეგ დაიწყეთ სერვისი მუშა-a

buildbot-worker start /home/habr/worker

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

ქვემოთ აღვწერ ზემოაღნიშნულის ზოგიერთ მახასიათებელს master.cfg.

6.1 თქვენი ბატონისკენ მიმავალ გზაზე.cfg

წერისას ჩემი master.cfg ბევრი შეცდომა იქნება დაშვებული, ამიტომ საჭირო იქნება ჟურნალის ფაილის წაკითხვა. ის ინახება როგორც BuildMaster-ec აბსოლუტური გზა /home/habr/master/twistd.log, და გვერდზე მუშა-ა აბსოლუტური გზა /home/habr/worker/twistd.log. შეცდომის წაკითხვისას და გამოსწორებისას მოგიწევთ სერვისის გადატვირთვა BuildMaster-ა. აი, როგორ კეთდება ეს:

sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master

6.2 მუშაობა svn

svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
                               svnuser="user",
                               svnpasswd="password",
                               pollinterval=60,
                               split_file=util.svn.split_file_alwaystrunk
                        )

c['change_source'] =  svn_poller

hourlyscheduler = schedulers.SingleBranchScheduler(
                            name="your-project-schedulers",
                            change_filter=util.ChangeFilter(branch=None),
                            builderNames=["yourProject"],
                            properties = {'owner': 'admin'}
                        )

c['schedulers'] = [hourlyscheduler]

checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
                     mode='full',
                     method='fresh',
                     username="user",
                     password="password",
                     haltOnFailure=True)

პირველ რიგში, მოდით შევხედოთ svn_poller. ეს ჯერ კიდევ იგივე ინტერფეისია, რეგულარულად ათვალიერებს საცავს წუთში ერთხელ. Ამ შემთხვევაში svn_poller წვდება მხოლოდ ფილიალში მაგისტრალური. იდუმალი პარამეტრი split_file=util.svn.split_file_alwaystrunk ადგენს წესებს: როგორ დაარღვიოს საქაღალდის სტრუქტურა svn ტოტებზე. ის ასევე სთავაზობს მათ შედარებით გზებს. თავის მხრივ split_file_alwaystrunk ამარტივებს პროცესს იმით, რომ საცავი შეიცავს მხოლოდ მაგისტრალური.

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

თვისებები აქ საჭიროა იმისათვის, რომ ადმინისტრატორმა მიიღოს build-ის და ტესტირების შედეგების საფოსტო სიები, როგორც პროცესის მფლობელი.

ნაბიჯი ავაშენოთ-a გადმოტანა შეუძლია მთლიანად წაშალოს ნებისმიერი ფაილი, რომელიც მდებარეობს საცავის ლოკალურ ვერსიაში მუშა-ა. და შემდეგ გააკეთე სრული svn განახლება. რეჟიმი კონფიგურირებულია პარამეტრით რეჟიმი = სრული, მეთოდი = ახალი... Პარამეტრი haltOnTailure ამბობს, რომ თუ svn განახლება შეცდომით შესრულდება, მაშინ მშენებლობისა და ტესტირების მთელი პროცესი უნდა შეჩერდეს, რადგან შემდგომ ქმედებებს აზრი არ აქვს.

6.3 წერილი თქვენ: რეპორტიორებს უფლება აქვთ განაცხადონ

ჟურნალისტებს არის ელექტრონული ფოსტით შეტყობინებების გაგზავნის სერვისი.

template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''
                        
sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
                                          sendToInterestedUsers=True,
                                          lookup="your.domain",
                                          relayhost="smtp.your.domain",
                                          smtpPort=1025,
                                          mode="warnings",
                                          extraRecipients=['[email protected]'],
                                    messageFormatter=reporters.MessageFormatter(
                                                    template=template_html,
                                                    template_type='html',
                                                    wantProperties=True, 
                                                    wantSteps=True)
                                        )
c['services'] = [sendMessageToAll]

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

MailNotifier იყენებს ელ.წერილს შეტყობინებების გასაგზავნად.

template_html ადგენს ტექსტის შაბლონს საინფორმაციო ბიულეტენისთვის. HTML გამოიყენება მარკირების შესაქმნელად. ის მოდიფიცირებულია ძრავით ჯინჯა2 (შეიძლება შედარება ჯანგო). BuildBot აქვს ცვლადების ნაკრები, რომელთა მნიშვნელობები ჩანაცვლებულია შაბლონში შეტყობინების ტექსტის გენერირების პროცესში. ეს ცვლადები ჩასმულია {{ ორმაგი ხვეული ბრეკეტებში }}. Მაგალითად, შემაჯამებელი აჩვენებს დასრულებული ოპერაციების სტატუსს, ანუ წარმატებას ან წარუმატებლობას. ა პროექტები გამოვა თქვენი პროექტი. ასე რომ, საკონტროლო ბრძანებების გამოყენებით ჯინჯა2, ცვლადები BuildBot-a და პითონის სტრიქონების ფორმატირების ხელსაწყოები, შეგიძლიათ შექმნათ საკმაოდ ინფორმაციული შეტყობინება.

MailNotifier შეიცავს შემდეგ არგუმენტებს.

fromaddr – მისამართი, საიდანაც ყველა მიიღებს ბიულეტენს.

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

მოძებნა, აიხედე ზემოთ — სუფიქსი, რომელიც უნდა დაემატოს იმ მომხმარებლების სახელებს, რომლებიც იღებენ ბიულეტენს. Ისე admin როგორ მიიღებს მომხმარებელი საინფორმაციო ბიულეტენს მისამართზე [ელ.ფოსტით დაცულია].

რელეჰოსტი განსაზღვრავს ჰოსტის სახელს, რომელზეც სერვერი იხსნება SMTP, smptPort განსაზღვრავს პორტის ნომერს, რომელიც უსმენს SMTP სერვერი.

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

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

messageFormatter არის ობიექტი, რომელიც განსაზღვრავს შეტყობინების ფორმატს, მის შაბლონს და ცვლადების ერთობლიობას ჯინჯა2. ვარიანტები, როგორიცაა wantProperties=True и wantSteps=True განსაზღვრეთ ხელმისაწვდომი ცვლადების ეს ნაკრები.

with['services']=[sendMessageTo All] გთავაზობთ სერვისების ჩამონათვალს, რომელთა შორის იქნება ჩვენი რეპორტიორი.

Ჩვენ ეს შევძელით! გილოცავ

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

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

მადლობა ყველას ყურადღებისთვის. Წარმატებები.

წყარო: www.habr.com