XP Days Ukraine - карысны адпачынак, каб лепш працаваць

[Person]
Вадзім Міхайлюк
Java Developer [/ person] [person]
Раман Паўлаў
PM [/ person] [person]
Станіслаў Шымаў
Java Developer [/ person] [person]
эліна Азадова
QA [/ person] [person]
Алёна Надеева
.NET Developer [/ person]

DataArt выступіў брыльянтавым спонсарам на XP Days Ukraine 2013, якая прайшла ў кастрычніку ў Кіеве. Мы разыгралі прызы (тры знешніх вінчэстара на тэрабайт) і памятныя футболкі, пачаставалі ўсіх кавы. Нечаканым забаўкай для ўдзельнікаў стаў новы сябар DataArt - робат Фаня, які ласкава забаўляў гасцей і частаваў цукеркамі. Акрамя таго, Андрэй Альпэрт, Senior PHP Developer DataArt, прадставіць даклад «TDD з AngularJS і Karma».

Мы актыўна ўдзельнічаем у XP Days Ukraine трэці год запар.

Коні дохнуць ад працы! Ад яе адны клопаты. Я люблю працу ўсё ж, але выратуй мяне, о, Божа! А. Гольцер

Больш за 370 чалавек ратаваліся ад працы на канферэнцыі XP Days Ukraine, але не каб увільнуць, а наадварот, - маючы на ​​мэце рабіць любімую працу яшчэ лепш. Прага новых ведаў і абмену досведам не абыйшла і каманду калегаў DataArt, у складзе Алены Надеевой (Кіеў), Вадзіма Міхайлюк (Кіеў), Рамана Паўлава (Харкаў), Станіслава Шымава (Адэса), Эліны Азадовой (Херсон), якія два дні прасьвятліліся, мелі зносіны з калегамі, папіваючы кофеек, дзівіліся раз'язджаліся на ровары робату Фане.

Не гледзячы на ​​зацвярджэнне Бернарда Шоу, што адзіны ўрок, які можна атрымаць з гісторыі - людзі не здабываюць з гісторыі ніякіх урокаў, прынята лічыць карысным ведаць яе, каб пераняць існуючы вопыт. Так Сандэр Hoodendoorn ( "One man, a whiteboard and three markers. Sander on software architecture and patterns", Sander Hoodendoorn. ), Які працуе ў галіне ПА больш за 30 гадоў, расказваў пра свой вопыт, і, што характэрна, адразу пра ўсё. Харызма дакладчыка, яго неабсяжны вопыт і незвычайны фармат дакладу выклікала толькі дзве рэакцыі: WoW і WTF. Пачаўшы з асноў - з нямалаважнага аповеду пра нетрывіяльнай тэхналогіі распрацоўкі метадам Ctrl + C Ctrl + V - ён плаўна перайшоў на больш банальныя MVC / MVP / MVVM, больш вядомыя ўсім як MVWTF. Пад канец дакладу, размалявалі дошку маркерамі (пры чым, смею заўважыць, трыма, як і было заяўлена ў назве даклада), ён не стрымаўся і перайшоў на другую. Ніжэй прадстаўлена фота асабовага боку - вынікі творчасці Сандера.

[Caption id = "attachment_6646" align = "alignnone" width = "525"] © https://twitter.com/xpinjection/status/388686780356370432/photo/1 [/ Caption]

Бенджамін Франклін казаў, што лянота робіць ўсякую справу цяжкім. На шчасце, у ў свеце праграмнага распрацоўкі усё ў дакладнасці да наадварот: менавіта лянота матывуе тварыць. Кіруючыся прынцыпам аптымізацыі ўсёй руціннай працы, цяпер ужо можна атрымліваць асалоду ад нават аўтаматызацыяй напісання кода. Менавіта InteliJ IDEA ўмее спрасціць жыццё распрацоўніка, але мала купіць і паставіць сабе гэты інструмент, немалаважна яшчэ і ўмець ім карыстацца. Маючы на ​​мэце зрабіць жыццё распрацоўніка яшчэ прасцей, Мікалай Чашнікаў ( "Efficient coding in InteliJ IDEA", Nikolay Chashnikov ) Паказаў, як усяго некалькімі націскамі Клава пісаць, выпраўляць і рефакторить код. Ні для каго не сакрэт, што за 50 хвілін ўяўляецца нерэальным вывучыць усе магічныя спалучэння клавіш, але гэта і не было мэтай дакладу. Затое Мікалай паказаў некалькі схаваных фіч, і распавёў некалькі спосабаў аптымізацыі сваёй працы.

Напрыклад, у InteliJ IDEA ёсць фіча, якая паказвае, якія shortcut былі выкарыстаныя і колькі разоў за ўсю гісторыю. Прааналізаваўшы гэтыя дадзеныя, можна яшчэ паскорыць напісанне свайго кода ў будучыні.

Сінхранізацыя - гэта вельмі важна. Каму не спадабаецца мець доступ да актуальных дадзеных з любога наяўнага девайса? Так і ў распрацоўцы вельмі важна, каб на ўсіх серверах была актуальная БД. Менавіта пра тое, як гэтага дасягнуць, і кажа Андрэй Сонцам ( "Agile development of enterprise database code with LiquiBase", Andrei Solntsev ). Бо, напэўна, кожны сутыкаўся з неабходнасцю падтрымкі некалькіх розных баз або накатыванием абнаўлення схемы і дадзеных БД. Не сакрэт, што пры гэтым даводзіцца сутыкацца з адрозненнямі ў сінтаксісе SQL. Дык вось LiqueBase, пра які ідзе гаворка, - Тул, які не проста накладвае ў пэўнай паслядоўнасці наборы sql-інструкцый, хоць гэта таксама можа (гл.), Але і дазваляе апісваць іх на ўласным незалежным ад БД заснаваным на xml-мове. Такім чынам гарантирутеся сінтаксічная правільнасць на любым з падтрымоўваных дыялектаў SQL. Андрэй на прыкладзе паказаў, што xml-канфігурацыя - не недахоп, а перавага сістэмы LiqueBase. Напрыклад, кожны можна гнутка параметризировать спісам БД (oracle, mysql і г.д.) або наборам энвароментов (dev, tests, prod і да т.п.), толькі для якіх ён павінен прымяняцца. Варта таксама адзначыць, што іншыя цікавыя магчымасцямі сістэмы - магчымасць выкарыстоўваць у ченжсетах інструкцыі для загрузкі дадзеных з CSV-файла, а таксама исполения каманд, напрыклад скрыпту бэкапу. А выбар як заўсёды за Вамі!

Яшчэ ў дзяцінстве мы вывучылі, што «разам весела крочыць па прасторах ...». Як паказвае практыка распрацоўкі, код пісаць разам таксама куды весялей: як мінімум, заўсёды карысна абмяняцца вопытам з калегам, буть адзін аднаму взаимополезными, так бы мовіць.

Такі падыход даўно культывуецца ў Xtreme Programming. Каманда, у якой працуюць Вадзім Герасімаў і Андрэй Сонцам ( "EXtreme Banking", Vadim Gerasimov, Andrei Solntsev ), Складаецца ўсяго з чатырох распрацоўшчыкаў, якія ўмеюць рабіць усё і тых, што любяць XP. Дакладчыкі цэлую гадзіну дзяліліся вопытам, распавядалі чаму яны выбралі менавіта тыя, а не іншыя тэхналогіі / метадалогіі. Яны сцвярджаюць, што XP коммандной дух (няма канкрэтнага чалавека, які напісаў той ці іншы код - увесь код належыць камандзе) і дазваляе ў той ці іншай меры разумець, як працуе ўся сістэма цалкам.

Гэта дасягаецца з дапамогай пастаяннай змены пар і ў той ці іншай ступені працы з кожным асобным модулем. У цэлым, хлопцы самі маюць зносіны з заказчыкамі, самі пішуць код, самі ж яго тэстуюць. Нават крэда гэтых хлопцаў абвяшчае: «Пацан накодил, пацан пратэст». Незразумелым застаецца адно: што будзе калі да іх у каманду патрапіць дзяўчына, ці ж дзяўчатам туды не патрапіць?

Варта адзначыць, што не ўсе так любяць парнае праграмаванне. Некаторыя ставяцца да гэтага падыходу некалькі скептычна. Так, у стужцы твітэра з'явілася прыкладна наступнае паведамленне

Чарговым прыхільнікам XP аказаўся Дзмітрый Миндра ( "XP in the real world", Dmytro Mindra ), Які уцягнуты ў распрацоўку крос-платформеннага гульнявога рухавічка, які выкарыстоўваецца больш чым 2 млн гейм-дэвелапераў ва ўсім свеце. У першую чаргу, нельга застацца абыякавым да дакладу Дзмітрыя, дзякуючы яго харызме, вельмі гарачай тэме (бо хто з нас не гуляе ў гульні?) І, вядома ж, арыгінальнасці. Бо хіба можна застацца абыякавым калі дакладчык раптам ўключае шутэр і працягвае даклад, носячыся па лабірынце, страляючы і паказваючы свае слайды, паразвешваныя прама на сценах?

Цяжка ўявіць, як працуе XP у размеркаваных камандах, але Зміцер здолеў данесці на прыкладзе кампаніі Unity 3d, каманды якой раскіданыя па ўсім свеце, што гэта не толькі магчыма, але і вельмі эфектыўна. Созваниваясь па Skype і выкарыстоўваючы TeamViewer непасрэдна для праграмавання, можна дасягнуць тых жа вынікаў што і пры асабістым кантакце. Ну а каб крыху развеяцца, 2 тыдні ў годзе ўсе распрацоўшчыкі адкладаюць ўсю сваю працу, збіраюцца ў адным месцы і ўладкоўваюць HackWeek event, для рэалізацыі якіх-небудзь сваіх ідэй і абмену вопытам.

Працягваючы тэму метадалагічных практык, варта заўважыць, што слепа вынікаючы правілам Agile, мы далёка не абавязкова рыхтуем праект на поспех. Так Мікалай Алименков ( "Tech Lead - required role for Agile project success", Mikalai Alimenkou ) У сваім кароткім дакладзе на тэму ролі Tech Lead ў Agile-праектах трохі іранічна ацаніў метадалогію SCRUM, якая не прадугледжвае выдзеленай ролі архітэктар / тых. кіраўнік у праекце, а мяркуе, што ўсё проста "team members". Дакладчык вызначыў, што Tech Lead - член каманды, здольны прымаць правільныя тэхнічныя рашэнні і якія прыводзяць праект да поспеху. Гэтая роля аб'ядноўвае некалькі подролей: кантакты з камандай, зносін з заказчыкам, архітэктура, пастаўка і рызыкі. Гэты чалавек проста ідэальны для ролі scrum майстар. І што немалаважна, ён таксама піша код! Такім чынам Tech Lead выглядае надзвычай каштоўным членам любой каманды, і за кошт яго можна эканоміць на мэнэджарах. Такога чалавека трэба яшчэ знайсці :)

Як мы памятаем з аповеду Сандера, на жаль, не заўсёды здараецца працаваць у dream-team, і з добра спраектаванымі прыкладаннямі. Так коуч і ментар тэхнічных і бизнескоманд Ola Ellnestam ( "Mikado Method", Ola Ellnestam ) Распавядаў пра legacy code ў адным з яго праектаў, праца з якім нагадвала аўтару бой з гідра з старажытнагрэцкіх міфаў. Код быў настолькі звязаны, што любая змена спараджала мноства памылак зборкі, а іх ухіленне - па некалькі новых на кожнае выпраўленне. Каманда паспрабавала вырашыць праблему ў лоб, т. Е. Выпраўляючы памылку за памылкай, ішлі дні, колькасць файлаў расло, як і колькасць памылак ... Праз два тыдні хлопцы прынялі адважнае рашэнне выкінуць усе гэтыя напрацоўкі і пачаць нанова. Другі раз вырашылі адзначаць усе залежнасці на графе залежнасцяў, да таго часу, пакуль яны не стануць атамарнага. Такім чынам, наступіла не толькі шчасце для каманды, але і, у выніку абагульнення такога вопыту, з'явіўся «Метад Микадо», які атрымаў назву па імі гульні, у якой трэба выцягваць палачкі з кучы, не закрануўшы астатніх і ня разбурыўшы канструкцыі. Калі-небудзь дадзены метад будзе падтрымлівацца асяроддзямі распрацоўкі і дазволіць паскорыць працу, як убудаваныя сродкі рэфактарынгу.

Свет мяняецца вельмі хутка, выходзяць з моды рэчы, нядаўна яшчэ актуальныя тэхналогіі маральна састарваюцца, метады ў фреймворках сыходзяць на пенсію. А што, калі крытычна важны метад для бягучага проета знік з новай версіі праграмнага інструментара? Што ў падобнай сітуацыі рабіць, як будаваць архітэктуру праекта так, каб такія неспадзяванкі не стваралі цяжкасці, распавядае Sander Hoodendoorn ( "How frameworks can kill your projects and patterns to prevent you from getting killed", Sander Hoodendoorn ) У паўтарачасовы прэзентацыі ўсяго за гадзіну. Больш канкрэтных прыкладаў і канкрэтных метадаў барацьбы з патэнцыяльнымі праблемамі, разам са спасылкамі на соответствующуюю літаратуру, у тым ліку, і яго аўтарства, прадставіў дакладчык гледачам.

«Сем разоў адмерай - адзін раз адрэж», - сцвярджае народная мудрасць. Акім Бойка ( "Architecture and Design Validation in .Net", Akim Boyko ) Акцэнтуе ўвагу на тым, што архітэктура і дызайн прыкладанняў павінны тэставацца, як модулі, што дазваляе выяўляць праблемы на ранніх стадыях. Сярод прычын, на думку аўтара, статычная тыпізацыя, прывязка / кантэкст, унутраная «канвенцыя». Для барацьбы з гэтым Акім прапанаваў наступныя "рэцэпты":

• TDD ў агульным;
• фіксацыя і тэставанне залежнасцяў праекта, напр., калі зборка А спасылаецца на Б, а Б - на У, то А ці не павінна спасылацца на В;
• аспектно-арыентаванае праграмаванне на аснове Postsharp, якое дазваляе ўкараняць код валідацыю архітэктурных абмежаванняў;
• дынамічны API кампілятара C # з дапамогай праекта Rolsyn, дазваляе выкарыстоўваць кампілятар для аналізу кода.

Плаўна змяняючы тэму валідацыю на тэму тэставання, нельга не пагадзіцца з Наталляй Рыкол ( "Definition of Quality", Natalya Rykol ), Якая сцвярджае, што, калі вы сядайце ў таксі, не прасіце кіроўцы адвезці вас "дадому", а называеце канкрэтны адрас. Паняцце «якаснага» ПА у кожнага сваё. Якраз таму варта вызначаць вымерна стандарты якасці.

Наталля вельмі падрабязна распавяла пра знешнія і ўнутраныя метрыках якасці, па якіх яго варта ацэньваць, дала рэкамендацыі з уласнага вопыту, як і калі іх лепш ужываць. Немалаважным быў наступны рада: не выкарыстоўваць метрыкі дзеля метрык, т. Е. Ўсе метрыкі павінны падыходзіць канкрэтнаму праекце.

Кажучы пра тэставанне, нельга абыйсці бокам аўтаматызаванае тэставанне, у прыватнасці TDD. Наш калега Андрэй Альпэрт ( "TDD with AngularJS and Karma", Andrey Alpert ) Не застаўся абыякавы да гэтага. Перш за ўсё, ён распавёў пра Angular на практыцы і падзяліўся водгукам аб ім на аснове яго выкарыстання на працягу працяглага часу. Увогуле, UI-код з выкарыстаннем фреймворка ад Google у выпадку пісьменнага прымянення апошняга сапраўды добра чытаецца і змяшчае пераважна незамутненной дэталямі працы з DOM логіку. Што, адпаведна, вельмі спрашчае напісанне тэстаў і распрацоўку праз тэставанне. У той жа час, крывая адносіны калег да выкарыстання Angular - досыць ламаная, са спадамі і скокамі ад «Angular - лепшы фреймворк» да «як мы наогул абралі гэта, праект асуджаны», і назад. Прэзентацыя дакладу Андрэя Альперта .

Працягнуў тэму TDD Мікалай Алименков ( "TDD for database related code, how is it possible?", Mikalai Alimenkou ), Які пастараўся пераканаць аўдыторыю, што напісанне кода баз дадзеных і доступу да дадзеных праз TDD не толькі магчыма, але досыць проста за кошт выкарыстання некаторых выдатных тэхнік і сучасных інструментаў.

Не сакрэт, што дадзеныя значна важней зыходнага кода праграмы. Маніпуляцыі над імі ў продакшене павінны быць максімальна бяспечнымі. Гэта дасягаецца тэставаннем новых зменаў. Трэба тэставаць ўсе, каб быць упэўненым у кодзе БД (схема БД, дадзеныя, спасылачныя цэласнасць дадзеных, аб'екты БД, прадукцыйнасць і інш.). Самае галоўнае, што трэба тэставаць на рэальнай БД. Моки на ўзроўні драйвера БД, або ORM / DAL не вырашаюць задачу тэставання БД. Існуе некалькі вядомых тэхнік тэставання: «чорны скрыню»; тэст - транзакцыя; тэст - «герой» - сам рыхтуе сабе дадзеныя, сам чысціць. Інструменты дзеляцца на групы: для кіравання міграцыямі (Liquibase, dbmigration) і для тэставання (dbunit, Unitils). Т. а., TDD ў базах дадзеных, на думку аўтара, дазваляе пазбавіцца ад «прасцін» чеклистов з таемнымі ведамі, якія патрабуюць ручной працы, дыктуе мінімальна неабходны код змяненняў, поўны кантроль кода доступу дадзеных, лёгкі працэс рэфактарынгу.

У рэальным свеце не заўсёды пакрыццё аўтаматычнымі тэстамі гарантуе шчасце. Войцех Селига ( "Automated Test Hell - Our Journey", Wojciech Seliga ) Распавёў аб праблемах, з якімі сутыкнуўся, пра шляхі іх вырашэння і чаму пры гэтым ён і яго каманда навучыліся. У цэлым, даклад быў прысвечаны case study, як іх кампанія, распрацоўшчык JIRA, змагалася з праблемамі CI. У прыватнасці: чырвоныя білды, дзесяткі тысяч павольных і нестабільных Лягасі -тэст, няправільнае стаўленне да тэстамі ў каманды і ўспрыманне няўдалага білда і г.д. Для паляпшэння сітуацыі хлопцы прадпрынятыя наступныя меры.

• Аптымальны баланс паміж ізаляцыяй, хуткасцю, пакрыццём, намаганнямі.
• Тэсты - гэта не смецце, а такі ж код!
• Ўзроўні білдаў (A1, A2, A3) і выразныя палітыкі. Кожны ўзровень адлюстроўвае глыбіню інтэграцыі тэстаў. Патрабаванні: чым ніжэй узровень, тым вышэй патрабаванні да паспяховасці білда.
• Візуалізацыя працэсу білда важная. Усе павінны бачыць статус і рэагаваць своечасова.
• Навучанне: як пісаць тэсты, палітыкі, добрыя / дрэнныя практыкі.
• Дэтэрмініраванасці тэстаў, барацьба з race conditions.
• Паляпшэнне прадукцыйнасці: тэстаў, git, кампіляцыі, даступнасці білд-агентаў, публікацыі вынікаў.

Каманда з тых чалавек працавала над паляпшэннямі CI больш за год. Яны дасягнулі пэўных поспехаў, базавай мэты не дасягнулі, але былі зроблены наступныя высновы:

• празрыстасць і разуменне рэальных праблем дапамагае з імі змагацца;
• падтрымка вялізнага масіва тэстаў вельмі складаная і працяглая;
• трэба «замяраць» праблему, вырашаць яе, а потым замяраць вынік;
• аўтаматычныя тэсты - гэта не аднаразовая інвестыцыя, а пастаянная праца;
• прадукцыйнасць і яшчэ раз прадукцыйнасць.

Застаецца спадзявацца, што гэтыя высновы прывядуць рабят да канчатковай мэты, і, вядома ж, дапамогуць іншым з рашэннем падобных праблем альбо ўвогуле іх прадухіленнем.

Руцінная праца можа нараджаць у галаве толькі адну думку: «А ці можна гэта аўтаматызаваць?» На шчасце, усё больш і больш сродкаў узнікае для аўтаматызацыі такіх працэсаў.

Аляксандр Дарашэнка. ( "Enterprise Provisioning with Chocolatey", Alexander Doroshenko ), Распрацоўшчык і энтузіяст ALM і DevOps, з натхненнем распавёў, як у апошнія гады ўсё больш скарачалася час разгортвання сервераў і як Chocolatey і Boxstarter дапамагаюць канфігураваць Windows-машыны. Калі каму-небудзь з слухачоў пасля вывучэння сродкаў аўтаматызацыі канфігуравання UNIX-сістэм не хапала такога ж у Windows, даклад у нейкай ступені запоўніў гэты вакуум.

Выкарыстанне Chocolatey і Boxstarter дазваляе, у прыватнасці, атрымліваць ідэнтычныя канфігурацыі і на дэсктопах распрацоўшчыкаў, не кажучы ўжо аб эканоміі часу на пачатак працы з новым праектам. У двух словах, Chocolatey - аналаг apt-get для Windows, а Boxstarter спрашчае канфігурацыю свежаўсталяванай сістэм з дапамогай Chocolatey, дадаючы такія магчымасці, як кіраванне працэсам ўстаноўкі перазагрузкамі, інсталяцыя Windows-абнаўленняў, змена налад сістэмы і т. Д

Ці Можа буянае прыкладанне дазволіць сабе сысці Ў афлайн для деплоя хаця б на пяць хвілін? Можа, вы І скажаце, Што так, але падумайце, колькі карыстальнікаў апынуцца незадаволенымі. Менавіта таму zero downtime - наша ўсё. Так Axel Fontaine ( "Architecting for Continuous Delivery and Zero Downtime", Axel Fontaine ), Распрацоўшчык І кансультант, нагадаў, Што сучасныя кампаніі накшталт Facebook, Flickr, Stackoverflow Даўно перайшлі на Continuous Delivery І праілюстраваў гэтя скрыншотамі. Напрыклад, у StackOverflow ўнізе старонкі пазначаны нумары версіі І дата редеплоя. Прычым звычайны Яна супадае з бягучай, такім чынам, абнаўляецца дастаткова частая. Далей расказаў, як код праходзіць розныя крокі на CI-сэрвэры, пачынаючы ад моманту камітаў і заканчваючы устаноўкай на production і абнаўленнем канфігурацыі. Паводле аўтара, кожны установачны артэфакт, напрыклад, WAR-файл для Java, варта забяспечваць наборам канфігурацыйных файлаў для кожнага энвайромента і выкарыстоўваць аўтавызначэнне для выбару патрэбнага пры запуску. Такім чынам, усё неабходнае знаходзіцца ў адным артэфакце, якім лёгка кіраваць. Таксама згадаў пра Feature Toggles як рашэнне для праблемы залівання на VCS яшчэ не цалкам гатовага кода. Як патлумачыў дакладчык, гэта дазваляе адмовіцца ад фіч-Бранч і весці ўсю працу ў Транк VCS, што спрыяе ранняй інтэграцыі кода. Таксама не былі забытыя Blue / green-деплойменты - як спосаб абнаўлення прыкладанняў з мінімальным downtime.

Падхапіў тэму диплоймента Андрэй Раброў ( "Building deployment pipeline: DevOps way", Andrey Rebrov ), Распрацоўшчык і коуч, які распавёў пра DevOps як пра спосаб павысіць якасць, хуткасць і празрыстасць працэсу паставак праз пераадоленне супярэчнасцяў паміж Dev- і Ops-камандамі. Адзначыў і складнікі гэтага працэсу: Культуру, Аўтаматызацыя, Вымярэнне і Абмен ведамі, што ўвасабляецца ў жыццё шляхам правядзення тимбилдингов, спрашчэння деплоймент-скрыптоў за кошт выкарыстання разнастайных інструментаў, комплекснага маніторынгу логаў і іх аналізу і збору статыстыкі, пабудовы на іх аснове розных графікаў.

Было цікава паглядзець на аналіз логаваў з дапамогай Splunk: доўгі 5-малой запыт выводзіў коррелляцию паміж рознымі падзеямі ў логу, разлічваў сярэднія значэння і адхіленні паказчыкаў.

У Іцхака Адзізеса ёсць выдатнае зацвярджэнне "if it does not get better it gets worse", з якім складана паспрачацца. Таму кожную сістэму, выпушчаную ў прадакшн, трэба падтрымліваць і маніторыць. Андрэй Самиляк ( "DevOps Engineering in real-time", Andriy Samilyak ), Які мае багаты вопыт арганізацыі і каардынацыі DevOps, распавядаў аб праблеме канфігурацыі і падтрымкі сістэм з вельмі шырокай геаграфіяй ў рэжыме 24х7 аперацыйнымі камандамі.

Асноўны інструмент, які яны выкарыстоўваюць для аўтаматызаванага кіравання канфігурацыямі, - Chef, напісаны на Ruby. Гэта адна з чатырох самых магутных сістэм кіравання канфігурацыямі для Linux. Прадукт дазваляе ствараць «рэцэпты», якія апісваюць, як Chef кіруе серверамі прыкладанняў.

Акрамя таго, DevOps-каманда актыўна выкарыстоўвае Jenkins для CI, які дазваляе рабіць многае ў плане кіравання тэставымі, паннаў-атачэннямі і ствараць «пясочніцы» для каманд распрацоўнікаў.

І апошні найбольш важны атрыбут якаснага DevOps, які ў іх актыўна ўкараняецца і развіваецца, - мониторниг. Без яго DevOps проста сьляпы. Іх каманда выкарыстоўвае такія інструменты, як Sensu, Splunk. Гэта выдатныя тулы для агрэгацыі і репортинга розных статыстык працы сервера прыкладанняў.

Ну, і куды ж без аблокаў? Аляксандр Дзямідаў ( "Living in the cloud without system administrators", Alexander Demidov ) Не змог абысці воблака бокам, і распавёў гісторыю вопыту пабудовы высоконагруженных хмарнай сістэмы, распавёў з абгрунтаваннямі таго, чаму яго каманда прыйшла да таго ці іншага рашэння. У першую чаргу даклад будзе цікавы архітэктарам і DevOps-інжынерам ну і ўсім, хто плануе разгортванне сістэм у воблаку Amazon. Асноўныя ідэі, якія хацеў данесці аўтар:

• Amazon - добрае воблака.
• Не верце рэкламе, якая кажа, што хмарныя рашэнні надзейней звычайных: наш досвед паказвае, што хмарныя сістэмы нават такіх правераных кампаній, як Amazon, схільныя збояў на ўзроўні «жалеза» і ўплыву чалавечага фактару.
• Думайце пра маштабаванасці на этапе праектавання прадукту (як прыклад, выкарыстоўваюць абстрактны файлавы API, што дазваляе ім працаваць празрыста з любой хмарнай ФС)!
• Percona (fork MySQL) паказвае лепшыя вынікі, чым MySQL. Гэта і хутчэй рэстарт і вядзе ўнутраную статыстыку запытаў і доступу да дадзеных.
• Майстар-майстар рэплікацыя паміж дата-цэнтрамі з раздзяленнях па цотнасці.
• Ужывайце автомасштабирование сістэмы - выкарыстоўвайце СloudWatch-сістэму для аўтаматычнага старту / выдалення дадатковых нод на падставе сярэдняй загрузкі CPU.
• Любое паведамленне ад сістэмы маніторынгу патрабуе рэакцыі, інакш гэты струмень нікому патрэбны.
• Аўтаматызуе рэакцыю на некаторыя руцінныя паведамленні сістэмы маніторынгу!
• Мониторьте сістэму маніторынгу!
• Пастаянны feedback распрацоўнікам (статыстыка па прадукцыйнасці, логі памылак, логі павольных запытаў і г.д.).

Калі хочаце даведацца больш падрабязна, глядзіце даклад Аляксандра.

Вось так і праляцелі два дні канферэнцыі. Хочацца падзякаваць дакладчыкаў за час, сілы і велізарны досвед, якім ніхто не скупіўся дзяліцца; арганізатараў за такое цудоўнае падзея і, вядома ж, DataArt за магчымасць паўдзельнічаць у ім.

Перш чым завяршыць гэты бясконцы паток літар, напэўна, варта адзначыць, што хутка часу ўсе матэрыялы канферэнцыі будуць даступныя на сайце XP Days ў раздзеле History . Там можна будзе падрабязней азнаёміцца ​​з матэрыяламі, і нават посметреть видосики з дакладамі не толькі тым, хто не ведаў, як разарвацца паміж разумнымі і прыгожымі і на які stage пайсці, але і проста ўсім жадаючым.

наш фотасправаздача

Фотасправаздача ад арганізатараў