DevOps LEGO: как подредихме тръбопровода на кубчета

Веднъж доставихме система за електронно управление на документи на клиент в едно съоръжение. И след това към друг обект. И още един. И на четвъртата, и на петата. Толкова се увлечехме, че стигнахме до 10 раздадени обекта. Получи се мощно... особено когато трябваше да внесем промените. Като част от доставката до производствената верига, 5 сценария на системата за тестване в крайна сметка изискват 10 часа и 6-7 служители. Такива разходи ни принудиха да правим доставки възможно най-рядко. След три години работа не издържахме и решихме да подправим проекта с щипка DevOps.

Сега цялото тестване се провежда за 3 часа и в него участват 3 души: инженер и двама тестери. Подобренията са ясно изразени в цифри и водят до намаляване на така обичания TTM. Според нашия опит има много повече клиенти, които могат да се възползват от DevOps, отколкото тези, които дори знаят за него. Ето защо, за да доближим DevOps до хората, разработихме прост конструктор, за който ще говорим по-подробно в тази публикация.

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

Обикновено работим с клиента чрез договор и в този случай интересите ни леко се разминават. Клиентът разглежда проекта стриктно в рамките на бюджета и техническите спецификации. Може да е трудно да му се обяснят ползите от различни DevOps практики, които не са включени в техническите спецификации. Ами ако той се интересува от бързи версии с добавена бизнес стойност или от изграждането на конвейер за автоматизация?

Уви, когато работите с предварително одобрени разходи, този интерес не винаги се намира. В нашата практика имаше случай, когато трябваше да вземем разработката на безскрупулен и небрежен изпълнител. Беше ужасно: нямаше актуални изходни кодове, кодовата база на една и съща система беше различна при различните инсталации, документацията отчасти липсваше и отчасти беше с ужасно качество. Разбира се, клиентът не е имал контрол върху изходния код, асемблирането, версиите и т.н.

Досега не всеки знае за DevOps, но щом говорим за предимствата му, за реално спестяване на ресурси, очите на всички клиенти светват. Така че броят на заявките, които включват DevOps, се увеличава с времето. Тук, за да говорим лесно на един език с клиентите, трябва бързо да свържем бизнес проблемите и DevOps практиките, които ще помогнат за изграждането на подходяща линия за разработка.

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

Създаване на DevOps конструктор

Agile има свой собствен манифест. ITIL има своя собствена методология. DevOps има по-малко късмет - все още не е придобил шаблони и стандарти. Макар че някои се опитват определят зрелостта на компаниите въз основа на оценка на тяхното развитие и оперативни практики.

За щастие, известната компания Gartner през 2014г събран и анализира ключови DevOps практики и връзките между тях. Въз основа на това пуснах инфографика:

Взехме го като основа за нашия конструктор. Всяка от четирите области има набор от инструменти - събрахме ги в база данни, идентифицирахме най-популярните, идентифицирахме точки на интеграция и подходящи механизми за оптимизация. Като цяло се оказа 36 практики и 115 инструмента, една четвърт от които са с отворен код или безплатен софтуер. След това ще говорим за това какво сме постигнали във всяка област и като пример за това как това беше приложено в проекта за създаване на техническо управление на документи, с който започнахме публикацията.

процеси

В прословутия проект EDMS системата за управление на техническата документация беше разгърната по една и съща схема на всеки от 10-те обекта. Инсталацията включва 4 сървъра: сървър на база данни, сървър на приложения, пълнотекстово индексиране и управление на съдържанието. В инсталацията те работят в рамките на един възел и са разположени в центъра за данни в съоръженията. Всички обекти се различават леко в инфраструктурата, но това не пречи на глобалното взаимодействие.

Първо, според практиките на DevOps, автоматизирахме инфраструктурата локално, след това донесохме доставката до тестовата верига и след това до продукта на клиента. Всеки процес беше разработен стъпка по стъпка. Настройките на средата са фиксирани в системата на изходния код, като се има предвид, че комплектът за разпространение е компилиран за автоматично актуализиране. В случай на промени в конфигурацията, инженерите просто трябва да направят съответните промени в системата за контрол на версиите - и след това автоматичната актуализация ще се извърши без проблеми.

Благодарение на този подход процесът на тестване е значително опростен. Преди това проектът имаше тестери, които не правеха нищо, освен ръчно да актуализират стендовете. Сега просто идват, виждат, че всичко работи и правят по-полезни неща. Всяка актуализация се тества автоматично - от повърхностното ниво до автоматизацията на бизнес сценария. Резултатите се публикуват като отделни отчети в TestRail.

Култура

Непрекъснатото експериментиране се обяснява най-добре чрез примера на дизайна на теста. Тестването на система, която все още не съществува, е творческа работа. Когато пишете план за тестване, трябва да разберете как да тествате правилно и кои клонове да следвате. И също така намерете баланс между време и бюджет, за да определите оптималния брой проверки. Важно е да изберете точно необходимите тестове, да помислите как потребителят ще взаимодейства със системата, да вземете предвид средата и възможните външни фактори. Невъзможно е без непрекъснато експериментиране.

Сега за културата на взаимодействие. Преди това имаше две противоположни страни - инженери и разработчици. Разработчиците казаха: „Не ни интересува как ще бъде пуснат. Вие сте инженери, вие сте умни, уверете се, че работи без повреди". Инженерите отговориха: „Вие, разработчиците, сте твърде невнимателни. Нека бъдем по-внимателни и ще пускаме вашите издания по-рядко. Защото всеки път, когато ни дадете изтекъл код, не ни е ясно как да взаимодействаме.. Това е въпрос на културно взаимодействие, който е структуриран по различен начин от гледна точка на DevOps. Тук както инженерите, така и разработчиците са част от единен екип, който е фокусиран върху постоянно променящ се, но в същото време надежден софтуер.

В рамките на един екип специалистите са решени да си помагат. Както беше преди? Например, подготвяха се някакви дебели инструкции за внедряване, дълги около 50 страници.Инженерът го прочете, нещо не разбра, изруга и помоли разработчика в три часа сутринта да коментира. Разработчикът коментира и също ругае - в крайна сметка никой не беше доволен. Освен това, естествено, имаше някои грешки, защото не можете да запомните всичко в инструкциите. И сега инженерът, заедно с разработчика, пише скрипт за автоматизирано внедряване на приложна софтуерна инфраструктура. И говорят помежду си практически на един и същи език.

Хора

Размерът на екипа се определя от обхвата на актуализацията. Екипът се набира при формирането на доставката, като включва заинтересовани от общия екип на проекта. След това се пише план за актуализиране с отговорните за всеки етап и екипът докладва, докато напредва. Всички членове на екипа са взаимозаменяеми. Като част от екипа имаме и резервен разработчик, но той почти никога не трябва да се свързва.

Технология

В технологичната диаграма са подчертани няколко точки, но под тях има куп технологии - можете да издадете цяла книга с техните описания. Така че ще подчертаем най-интересното.

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

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

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

В допълнение към инфраструктурните скриптове и конвейери, подходът „Документация като код“ също се използва за документиране. Благодарение на това е лесно да свържете нови хора към проекта, да ги запознаете със системата въз основа на функциите, описани например в тестовия план, както и да използвате повторно тестови случаи.

Непрекъснато доставяне и наблюдение

В последната статия относно DevOps говорихме за това как избрахме инструменти за внедряване на непрекъсната доставка и наблюдение. Често не е необходимо да пренаписвате нищо - достатъчно е да използвате предварително написани скриптове, правилно да изградите интеграция между компонентите и да създадете обща конзола за управление. И всички процеси могат да бъдат стартирани с помощта на един бутон или график.

На английски език има различни понятия, непрекъсната доставка и непрекъснато внедряване. И двете могат да се преведат като „непрекъсната доставка“, но всъщност има малка разлика между тях. В нашия проект за технически документооборот на разпределена енергийна компания се използва по-скоро Доставка - когато инсталирането за производство се извършва по команда. При разполагане инсталирането става автоматично. Непрекъснатата доставка в този проект като цяло е станала централната част на DevOps.

Като цяло, чрез събиране на определени параметри можете ясно да разберете защо практиките на DevOps са полезни. И предайте това на ръководството, което наистина обича числата. Общият брой стартирания, времето за изпълнение на етапите на скрипта, делът на успешните стартирания - всичко това пряко влияе върху любимото време за пускане на пазара на всички, тоест времето от ангажиране към системата за контрол на версиите до пускането на версия на производствена среда. С внедряването на необходимите инструменти инженерите получават ценни индикатори по пощата, а ръководителят на проекта ги вижда на таблото. По този начин можете веднага да оцените предимствата на новите инструменти. И можете да ги изпробвате на вашата инфраструктура с помощта на дизайнера DevOps.

Кой ще има нужда от нашите DevOps дизайнер?

Да не се преструваме: като за начало той ни стана полезен. Както вече казахме, трябва да говорите на един език с клиента и с помощта на дизайнера DevOps можем бързо да начертаем основата за такъв разговор. Бизнес специалистите ще могат сами да преценят от какво имат нужда и така да се развиват по-бързо. Опитахме се да направим дизайнера възможно най-подробен, като добавихме куп описания, така че всеки потребител да разбере какво избира.

Форматът на дизайнера ви позволява да вземете предвид съществуващите разработки на компанията в процесите на изграждане и автоматизацията. Няма нужда да събаряте всичко и да го изграждате наново, ако можете само да изберете решения, които се интегрират добре със съществуващите процеси и които могат просто да запълнят празнините.

Може би вашето развитие вече е преминало на по-високо ниво и нашият инструмент ще изглежда твърде „капитански“. Но го намираме за полезно за себе си и се надяваме, че ще бъде полезно за някои от читателите. Напомняме ви връзка към проектанта - ако има нещо, получавате схемата веднага след въвеждане на първоначалните данни. Ще бъдем благодарни за вашите отзиви и допълнения.

Източник: www.habr.com