DevOps LEGO: како го поставивме гасоводот во коцки

Еднаш доставивме електронски систем за управување со документи на клиент во еден објект. А потоа на друг објект. И уште еден. И на четвртиот и на петтиот. Толку се занесевме што стигнавме до 10 дистрибуирани објекти. Испадна моќно... особено кога стигнавме да ги испорачаме промените. Како дел од испораката до производното коло, 5 сценарија на системот за тестирање на крајот бараа 10 часа и 6-7 вработени. Таквите трошоци не принудија да вршиме испораки што е можно поретко. По три години работа, не можевме да издржиме и решивме да го зачиниме проектот со малку DevOps.

Сега целото тестирање се одвива за 3 часа, а во него учествуваат 3 лица: инженер и двајца тестери. Подобрувањата се јасно изразени во бројки и доведуваат до намалување на многу саканиот TTM. Според нашето искуство, има многу повеќе клиенти кои можат да имаат корист од DevOps отколку оние кои воопшто знаат за тоа. Затоа, за да го доближиме DevOps до луѓето, развивме едноставен конструктор, за кој подетално ќе зборуваме во овој пост.

Сега да ви кажеме подетално. Една енергетска компанија распоредува систем за управување со технички документи во 10 големи капацитети. Не е лесно да се движите низ проекти од овој размер без DevOps, бидејќи голем дел од мануелната работа во голема мера ја одложува работата, а исто така го намалува квалитетот - целата рачна работа е полн со грешки. Од друга страна, има проекти каде што има само една инсталација, но сè треба да работи автоматски, постојано и без неуспех - на пример, истите системи за проток на документи во големите монолитни организации. Во спротивно, некој ќе ги направи поставките рачно, ќе заборави на упатствата за распоредување - и како резултат на тоа, во производството поставките ќе се изгубат и сè ќе пропадне.

Обично работиме со клиентот преку договор, и во овој случај нашите интереси малку се разликуваат. Клиентот го гледа проектот строго во рамките на буџетот и техничките спецификации. Може да биде тешко да му се објаснат придобивките од различните практики на DevOps кои не се вклучени во техничките спецификации. Што ако тој е заинтересиран за брзи изданија со додадена деловна вредност или за изградба на гасовод за автоматизација?

За жал, кога работите со однапред одобрена цена, овој интерес не секогаш се наоѓа. Во нашата практика, имаше случај кога требаше да го собереме развојот на бескрупулозниот и невнимателен изведувач. Беше страшно: немаше ажурирани изворни кодови, основата на кодови на истиот систем беше различна на различни инсталации, документацијата беше делумно отсутна, а делумно со ужасен квалитет. Се разбира, клиентот немаше контрола врз изворниот код, склопувањето, изданијата итн.

Засега не секој знае за DevOps, но штом зборуваме за неговите предности, за вистинската заштеда на ресурси, очите на сите клиенти светат. Така, бројот на барања кои вклучуваат DevOps се зголемува со текот на времето. Овде, за лесно да го зборуваме истиот јазик со клиентите, треба брзо да ги поврземе деловните проблеми и практиките на DevOps што ќе помогнат да се изгради соодветна развојна линија.

Значи, имаме збир на проблеми од една страна, и знаење, практики и алатки за DevOps од друга. Зошто да не го споделите искуството со сите?

Креирање на конструктор DevOps

Agile има свој манифест. ITIL има своја методологија. DevOps е помалку среќен - сè уште нема стекнато шаблони и стандарди. Иако некои се обидуваат одредување на зрелоста на компаниите врз основа на проценка на нивниот развој и оперативни практики.

За среќа, добро познатата компанија Гартнер во 2014 г собрани и ги анализираше клучните практики на DevOps и односите меѓу нив. Врз основа на ова, објавив инфографик:

Го земавме како основа за нашата конструктор. Секоја од четирите области има сет на алатки - ги собравме во база на податоци, ги идентификувавме најпопуларните, идентификувавме точки за интеграција и соодветни механизми за оптимизација. Севкупно испадна 36 практики и 115 алатки, од кои една четвртина се со отворен код или слободен софтвер. Следно, ќе зборуваме за тоа што сме постигнале во секоја област и, како пример, за тоа како тоа беше имплементирано во проектот за креирање на управување со технички документи, со кој го започнавме постот.

Процеси

Во озлогласениот проект ЕДМС, системот за управување со техничка документација беше распореден според истата шема на секој од 10-те објекти. Инсталацијата вклучува 4 сервери: сервер за бази на податоци, сервер за апликации, индексирање на целосен текст и управување со содржина. Во инсталацијата, тие работат во еден јазол и се наоѓаат во центарот за податоци на објектите. Сите објекти се разликуваат малку во инфраструктурата, но тоа не ја попречува глобалната интеракција.

Прво, според практиките на DevOps, ја автоматизиравме инфраструктурата локално, потоа ја донесовме испораката до колото за тестирање, а потоа до производот на клиентот. Секој процес беше разработен чекор по чекор. Поставките на околината се фиксирани во системот на изворниот код, земајќи предвид кој комплет за дистрибуција е компајлиран за автоматско ажурирање. Во случај на промени во конфигурацијата, инженерите едноставно треба да ги направат соодветните промени во системот за контрола на верзијата - а потоа автоматското ажурирање ќе се одвива без проблеми.

Благодарение на овој пристап, процесот на тестирање е значително поедноставен. Претходно, проектот имаше тестери кои не правеа ништо освен рачно ажурирање на штандовите. Сега само доаѓаат, гледаат дека се работи и прават повеќе корисни работи. Секое ажурирање се тестира автоматски - од нивото на површината до автоматизација на деловните сценарија. Резултатите се објавени како посебни извештаи во TestRail.

Култура

Континуираното експериментирање најдобро се објаснува преку примерот на дизајнот на тестот. Тестирањето на систем кој сè уште не постои е креативна работа. Кога пишувате план за тестирање, треба да разберете како правилно да тестирате и кои гранки да ги следите. И, исто така, пронајдете рамнотежа помеѓу времето и буџетот за да го одредите оптималниот број на проверки. Важно е да ги изберете точно потребните тестови, да размислите како корисникот ќе комуницира со системот, да ја земе предвид околината и можните надворешни фактори. Невозможно е да се направи без континуирано експериментирање.

Сега за културата на интеракција. Претходно, имаше две спротивставени страни - инженери и програмери. Програмерите рекоа: „Не ни е грижа како ќе биде лансирана. Вие сте инженери, вие сте паметни, погрижете се да работи без дефекти“. Инженерите одговориле: „Вие програмерите сте премногу невнимателни. Да бидеме повнимателни и поретко ќе ги пуштаме вашите изданија. Затоа што секогаш кога ќе ни дадете шифра што протекува, не ни е јасно како да комуницираме“.. Ова е прашање на културна интеракција што е структурирано поинаку од перспектива на DevOps. Овде, и инженерите и програмерите се дел од единствен тим кој е фокусиран на постојано менување, но во исто време и доверлив софтвер.

Во рамките на истиот тим, специјалистите се решени да си помагаат едни на други. Како што беше порано? На пример, се подготвуваа некои дебели инструкции за распоредување, долги околу 50 страници.Инженерот го прочита, не разбра нешто, пцуеше и побара од развивачот во три часот наутро да коментира. Инвеститорот коментираше и исто така пцуеше - на крајот, никој не беше среќен. Плус, природно, имаше некои грешки, бидејќи не можете да запомните сè во упатствата. И сега инженерот, заедно со развивачот, пишува скрипта за автоматско распоредување на инфраструктурата за апликативен софтвер. И тие зборуваат меѓу себе практично на ист јазик.

Луѓе

Големината на тимот се одредува според обемот на ажурирањето. Тимот е регрутиран за време на формирањето на испораката, вклучува заинтересирани од генералниот проектен тим. Потоа се пишува план за ажурирање со одговорните за секоја фаза, а тимот известува додека напредува. Сите членови на тимот се заменливи. Како дел од тимот, имаме и резервен развивач, но тој речиси никогаш не мора да се поврзе.

Технологија

Во технолошкиот дијаграм се истакнати неколку точки, но под нив има куп технологии - би можеле да објавите цела книга со нивните описи. Така, ќе ги истакнеме најинтересните.

Инфраструктурата како код

Сега, веројатно, овој концепт нема да изненади никого, но претходно описите на инфраструктурите оставија многу да се посакуваат. Инженерите ужасно ги погледнаа упатствата, опкружувањата за тестирање беа единствени, беа негувани и негувани, честичките од прашина беа издувани од нив.

Во денешно време никој не се плаши да експериментира. Постојат основни слики на виртуелни машини, има готови сценарија за распоредување средини. Сите шаблони и скрипти се зачувани во систем за контрола на верзијата и се ажурираат веднаш. Претходно, кога беше неопходно да се достави пакет на штанд, се појави јаз во конфигурацијата. Сега само треба да додадете линија во изворниот код.

Покрај инфраструктурните скрипти и цевководи, пристапот Документација како код се користи и за документација. Благодарение на ова, лесно е да се поврзат нови луѓе со проектот, да се запознаат со системот врз основа на функциите опишани, на пример, во планот за тестирање, а исто така и повторно да се користат тест случаи.

Континуирана испорака и следење

Во последната статија за DevOps, разговаравме за тоа како избравме алатки за спроведување на континуирана испорака и следење. Честопати нема потреба да се препишува ништо - доволно е да се користат претходно напишани скрипти, правилно да се изгради интеграција помеѓу компонентите и да се создаде заедничка конзола за управување. И сите процеси може да се стартуваат со користење на едно копче или распоред.

На англиски има различни концепти, континуирано испорака и континуирано распоредување. И двете може да се преведат како „континуирана испорака“, но всушност има мала разлика меѓу нив. Во нашиот проект за проток на технички документи на дистрибуирана енергетска компанија, попрво се користи Испорака - кога инсталацијата за производство се случува на команда. Во Deployment, инсталацијата се случува автоматски. Континуирана испорака во овој проект генерално стана централниот дел на DevOps.

Општо земено, со собирање одредени параметри, можете јасно да разберете зошто практиките на DevOps се корисни. И пренесете го ова на менаџментот, кој навистина сака бројки. Вкупниот број на лансирања, времето на извршување на фазите на сценариото, уделот на успешните лансирања - сето ова директно влијае на омиленото време на пазарот на сите, односно на времето од извршување до системот за контрола на верзијата до објавување на верзијата на производствена средина. Со имплементацијата на потребните алатки, инженерите добиваат вредни показатели по пошта, а менаџерот на проектот ги гледа на контролната табла. На овој начин можете веднаш да ги оцените придобивките од новите алатки. И можете да ги испробате на вашата инфраструктура користејќи го дизајнерот DevOps.

Кому ќе му требаат нашите Дизајнер на DevOps?

Да не се преправаме: за почеток ни стана корисен. Како што веќе рековме, треба да зборувате на ист јазик со клиентот, а со помош на дизајнерот DevOps можеме брзо да ја скицираме основата за таков разговор. Бизнис специјалистите ќе можат сами да проценат што им треба и на тој начин побрзо да се развиваат. Се обидовме да го направиме дизајнерот што е можно подетален, додавајќи еден куп описи за секој корисник да разбере што избира.

Форматот на дизајнерот ви овозможува да ги земете предвид постојните случувања на компанијата во градежните процеси и автоматизацијата. Нема потреба да рушите сè и да го обновите ако можете само да изберете решенија кои добро се интегрираат со постоечките процеси и кои едноставно можат да ги пополнат празнините.

Можеби вашиот развој веќе се пресели на повисоко ниво и нашата алатка ќе изгледа премногу „капетанска“. Но, сметаме дека е корисно за себе и се надеваме дека ќе биде корисно за некои од читателите. Ве потсетуваме врска до дизајнерот - ако има нешто, дијаграмот го добивате веднаш по внесувањето на првичните податоци. Ќе ви бидеме благодарни за вашите повратни информации и дополнувања.

Извор: www.habr.com