Что такое пайплайн проекта

Про пайплайн разработки ресурсов

Давно хотелось как-то записать свои мысли по тому, как лучше организовывать пайплайн контента и его проверок.

В больших проектах, когда скорость разработки контента и его качество сравнимо по важности с надежностью кода и его стабильностью, а по объему значительно превышает его, построение хорошего пайплайна разработки контента становится крайне важным мероприятием.
При этом главное решить для себя что такое правильный и хороший пайплайн.
С одной стороны надо давать производителям контента гибкие и удобные инструменты, а с другой стороны, постоянно следить, что бы гибкость не перерастала в хаос. К сожалению слишком часто сталкивались с ситуациями, когда попытка выдать микроскоп, приводила к тому, что им начинали заколачивать гвозди, не заказывая молоток.
Сначала я думал, что надо как-то ограничивать доступ к микроскопу, чтобы те, кто им не умеют пользоваться не могли взять его в руки, а потом понял, что это полностью неправильный подход. Гораздо легче написать несколько тестов на то, что инструмент используется правильно и отлавливать неправильные случаи использования, объясняя как надо делать правильно. Так и только так можно добиться исправления основной причины ошибки, которая вовсе не в том, что гвоздь забили микроскопом. В конце концов, цель забить гвоздь выполнена и не принципиально как именно, жалко только что время потрачено глупо. Причина ошибки в голове того, кто не подумал заказать молоток и именно ее надо поймать и исправить. Научить человека работать правильно.
Любые запретительные меры бесполезны, если вы не предоставляете человеческой мысли удобное русло, то сначала, она будет накапливаться перед вашими дамбами, там загниет и вот эта тухлятина через некоторое время прорвется и затопит или весь проект или приличную его часть.
Т.к. человек всегда идет по наиболее простому сценарию, надо огромное количество усилий прикладывать к тому, чтобы правильный сценарий использования функционала был и наиболее удобным. Понятно, что всегда есть технологически сложные моменты, которые никуда не денутся, но при этом надо чтобы даже там, правильный путь, был наиболее удобным.
Особенно внимательно относитесь к жалобам людей на неудобства в использовании правильного сценария. Сам факт жалобу указывает что чувство прекрасного сотрудника уже идентично вашему и оно протестует против неудобства на правильном пути и противится хакам и обходам. На такие жалобы надо реагировать максимально быстро, потому как правильный способ мышления, наша величайшая ценность и она под угрозой.
Здесь надо обратить внимание, что одним из краеугольных камней данной системы является то, что у исправления ошибок должен быть более высокий приоритет, чем у создания новых фичей и контента. Иначе все ваши чекеры, билды отлавливающие странные ситуации не заставят людей думать правильно. Ведь именно исправление ошибки, правильным использованием фичи — читать — правильное понимание фичи в мозгу создателя контента — является нашим самым желанным результатом. Важно чтобы времени прошло мало и человек не забыл, что и зачем он делал. Иначе понятие правильно и неправильно у него в мозгу не свяжутся прочно.
Конечна данная система должна постоянно эволюционировать вместе с проектом. По возможности находя очередное феерическое «скрещивание микроскопа, молотка и газонокосилки» надо аккуратно добавлять его в тесты. Конечно в идеальном мире, надо продумывать все это пока фича еще в разработке, но в реальном такое почти не получается делать. К сожалению (((.
Еще стоит отметить, что не стоит увлекаться сложностью чеков, т.к. всегда стоит понимать, что дизайн может поменяться и часть ограничений надо будет снимать. Поэтому лучше много маленьких тривиальных проверок, которые легко переписывать, дополнять, или отключать при необходимости, чем несколько мега крутых, сложных чеков, в которых вы сами не разберетесь через месяц, не прочитав толмуд описания. Оно вам надо? Поймите, точнее вспомните о том, что вам потом еще объяснять логичность этой ошибки человеку делающему контент, который зачастую ни разу не технический специалист. Желательно чтобы сам факт провала проверки практически однозначно указывал на ошибку. Не забывайте, наша цель головы наших сотрудников, которые тоже хотят делать все правильно, просто не всегда понимают сразу как. Простые проверки легко донести до их понимания.
Вас пугает, что одна ошибка породит кучу провалившихся тестов? Зря! Чем больше тестов провалилось, тем глубже допущена ошибка, тем она важнее. Это ведь прекрасно, когда поглядев на отчет, можно сразу оценить масштаб катастрофы, не вчитываясь в детали.
К этому конечно стоит прибавить безжалостную войну с дублированием. Это один из злейших врагов всего IT. Скопировать дом в реальном мире, и добавить на него пару рющечек, в реальном мире равносильно постройке нового дома. В IT к сожалению это дело нескольких кликов. В итоге потом выясняется, что у этого дома плохо спроэктирован фундамент и его надо переделать. В итоге зачастую переделывается только оригинал, а копии продолжают нести в себе все баги, пока их не найдут отдельно. Ужасная, но к сожалению регулярная ситуация. Если с кодом это можно хоть как-то забороть, то с данными автоматически это сделать очень тяжело.
Единственное что можно делать легко, это уничтожать дублирование между полями данных. Благо это можно делать в собственном мозгу. Далее находя потенциальные функциональные зависимости, надо или сразу истреблять их, или делать процедуры, которые будут реализовывать эти функциональные зависимости. Т.е. объявляя одно из полей исходным, мы жестко перепрописываем значения в зависимых, даже если руками их кто-то пытается выставить в другое значение, помечая изменение, как сделанное автоматически. Обычно человек видя, что его значение сбрасывает автоматика, понимает, что не прав и делает все как положено.
К раздолбаям и любителям всегда делать по своему не желающим учиться, система должна быть безжалостна. Их головы это неисправимые ошибки в системе и от них лучше избавляться. Поэтому их вопли о железном занавесе и запрете креатива не стоит особо слушать. Креатив это умение сделать красиво в указанных рамках, а не вообще как моя левая пятка хочет.

Правильный пайплайн должен быть удобным для правильного использования и агрессивен к неправильному.
Простые чеки, простые и понятные тулзы, простые интерфейсы, сами подсказывают людям как делать правильно.
Неправильно использование пресекается по возможности мягко, но безальтернативно. Обход должен быть крайне затруднен. Помните человек всегда пойдет туда где проще, поэтому приглашайте его на правильный путь, затрудняя неправильные.

Источник

Пайплайн: что это такое и в чем его преимущества

Задача любого бизнеса – это приносить прибыль, и в этом ему поможет пайплайн продаж. Для стабильного дохода нужен контроль всех процессов. Ведь как увеличить доходы, если руководитель не знает, как справляется с потоком заявок отдел продаж? Pipeline – это как раз один из таких инструментов, без которого здесь не обойтись. Благодаря ему менеджер отслеживает статус клиента, а руководитель контролирует работу всего отдела. Что такое пайплайн, как его использовать в менеджменте и причем тут CRM-система, вы сейчас узнаете из этой статьи.

Что такое пайплайн

Пайплан продаж – это документ, отчёт или сводка, в которой собраны данные по движению клиентов. В пайплайн прописаны статусы всех сделок: от подачи заявки до подписания договора или совершения оплаты. Обычно пайплайн выглядит как большая и сводная таблица или журнал продаж. Многие назовут это «старшим братом» CRM-системы, но в Excel и будут правы.

То есть, можно сказать, что pipeline – это и старший брат воронки продаж. Оба инструмента призваны обеспечить планирование и оценить эффективность компании. Однако все-таки они отличаются друг от друга. Обычно в воронке продаж делается фокус на конверсию и этапы, а пайплайн – это сборник историй превращения заявки в сделку.

Из чего состоит пайплайн:

Пайплайн содержит в себе множество данных и сведений о процессе сделок с клиентами. Если вы попробуйте построить на основе этого документа воронку продаж, то у вас получится это сделать. А вот создать пайплайн из воронки не выйдет, потому что последняя склеена из меньшего количества информации. Воронка не способна дать информацию, которую бы хватило для прогнозов, анализа и менеджмента по пайплайн.

Цель pipeline – оценка качества, процесса и количества всех сделок здесь и сейчас. Также этот отчёт служит для составления прогнозов на конкретный период.

Что такое Sales Pipeline Management

Sales Pipeline Management – это менеджмент на основе данных по продажам, управление по пайплайн. В данном случае менеджер отслеживает и руководит каждой сделкой на всех этапах продаж. Он доводит заявку до оформление договора, чтобы принести прибыль компании.

А руководитель мониторит не одну сделку, а все сразу по каждому менеджеру. И чтобы объективно оценить результаты продаж, пайплайн надо разделять на несколько этапов.

Этапы pipeline

Пайплайн можно и нужно делить на этапы работ, например: планирование на завтра и неделю вперед. Планирование на более долгий срок, например, месяц и квартал – это прерогатива высшего руководства.

Этап планирования – на этой стадии менеджер и руководители оценивают ход продаж и прогнозируют сделки. Это нужно для того, чтобы грамотно перераспределить задачи, сфокусироваться на том, что требует скорого завершения. Помимо этого, планирование на день и неделю вперед служит для того, чтобы сделать набросок будущей стратегии.

Этап действий – в соответствие с выработанным планом менеджер и руководитель переходят к работе с клиентами из pipeline. Например, во время планирования выяснилось, что с тремя клиентами еще не согласованы встречи и не велись переговоры по согласованию договора. Вероятность успеха завершения сделки оценивается в 70%. Тогда сотрудники получают команду – как можно скорее закрыть этих клиентов.

Этап анализа – подводятся итоги рабочего дня, руководители оценивают сотрудников, составляют отчетность. Менеджеры, довольные результатами, уходят домой, а руководители думают, над приростом каких показателей предстоит потрудиться. Здесь круг замыкается – снова возвращаются к этапу планирования.

Как использовать пайплайн продаж в CRM

Сюда тоже попадают данные по лидам и статусам, но в автоматическом режиме. Тем самым исполнитель снимает с себя ряд рутинных задач с помощью CRM.

По сути, CRM-система – это и есть отчёт продаж, потому что там отслеживаются те же метрики и показатели, которые прописываются в pipeline.

Отчетность и показатели

Как уже было сказано выше, пайплайн продаж служит и для отчётности. Сотрудники и руководители стремятся улучшить ряд показателей, которые прописываются в этом документе:

Именно эти показатели в обязательном порядке прописываются в этом отчёте. Чем короче даты и больше вырученной суммы, тем счастливее отдел продаж. И тут мы пришли к важному вопросу: что же надо делать руководителю, чтобы увеличивать эти показатели?

Основные принципы управления

От руководителя требуется придерживаться нескольких принципов, если он хочет управлять по пайплайн:

Преимущества управления продажами по пайплайн

У менеджмента по пайплайн есть несколько преимуществ:

Заключение

Хоть CRM-системы практически полностью заменили pipeline как журнал сделок, этот документ послужит вам на пользу. Управление по пайплайн помогает отделу продаж рациональнее расходовать ресурсы, указывает на зоны роста и задает темп работ. Пайплайн – это один из инструментов контроля всех бизнес-процессов компании. Используйте принципы управления по пайплайн в бизнесе и маркетинге, чтобы повысить показатели продаж.

Источник

О пайплайне

Самое простое объяснение пайплайна – это конвейер, порядок работы, к которому все привыкли и которому нужно обучиться. Но в реальности все чуть-чуть сложнее. Чтобы хорошо играть в трехмерку, нужно понимать правила игры. Иначе можно застрять и потерять интерес.

Это первая часть статей о пайплайне, где я расскажу:

Давай немного отвлечемся от трехмерки. Три измерения — слишком много, одного будет достаточно; поговорим о книгах. Что нужно, чтобы напечатать книгу? На самом деле процесс простой:

Написать — сверстать — напечатать — сшить — продать.

Все очень просто, типичный конвейер производства. Но на деле есть подводные камни.

Все мы иногда рассказываем истории, я очень люблю их рассказывать. Но как мы «создаем» истории? Какие процессы происходят в голове?

Представь: у тебя есть ощущение. Например, впечатление от классной тачки, горячей девчонки или гниющей помойки; от чего угодно. Оно только что появилась в глубине твоего бессознательного. Чтобы даже осознать о чем это ощущение, твой мозг проводит сложнейшие вычисления, вспоминает всю безумно огромную систему языка: слова, звуки, правила их взаимодействия и смыслы, какие мы. Нужно повторить эту работу сотни и тысячи раз, чтобы получить рассказ, а случайный набор слов в историю не сложится. Так же и трехмерка, ее нужно тренировать и воспитывать, изучать формы и пятна, фактуры, запоминать интересные сочетания, законы топологии, принципы равертки. Язык — это система. Если ты постоянно практикуешь эту систему, с опытом начинают получаться понятные, и захватывающие рассказы. Невозможно месяц с нуля поучить язык и сразу написать шедевр. Так же и с трехмеркой. Ты знаешь, как написать письмо своей бабушке, мы все этому учились первые 5 лет школы. А знаешь, как написать интересный рассказ? Ты, кажется, умеешь делать модельки, а знаешь, что делает их понятными, выразительными и, мое любимое слово, сочными?

Художник использует полигоны и текстуры (в 2д холст и краски, в скульптуре глину). Писатель использует слова. Чтобы замоделить калаш, танк, персонажа, или построить композицию — мы собираем, двигаем и красим формы, как писатели из слов и предложений собирают рассказы и романы; они подчиняются очень строгим правилам грамматики, логики, композиции и ритму повествования. Наш язык просто на три измерения сложнее, и поэтому требует конкретики. Чтобы описать осень писателю требуется от нескольких строк до страниц, объем и время работы зависит от «детализации». Например, можно написать просто «была осень», и каждый читатель воображает «свою» осень: для кого-то это дожди и слякоть, для других листопад и приятный морозец. Чтобы отмоделить осень —придется немного запариться конкретикой, но это дает нам силу Однозначности! Почему в арте мы легко отличаем дожди от листопадов? Нам помогают пятна, из которых собираются силуэты, и композиция, а так же фактуры, свет, цвета, дизайн и т.д. Все детали вашей работы важны, но слабые формы сложно спасти крутыми фактурами (так тоже бывает). Хороший художник рассказывает историю своими работами. Для художника естественно делиться информацией, будь то харизматичный персонаж, звездная ночь, или небольшая история. Здесь рождается наша острая потребность в референсах. Но даже до чтения рефов нужно дорасти; пока я не изучил основы художественной грамотности — совершенно не умел читать и подражать действительности, но об этом как-нибудь в другой раз.

Описание Чичикова в «Мертвых душах», и его иллюстрации (авторов не знаю). Гоголю хватило двух десятков слов, но художники вынуждены рисовать конкретный и точный образ.

Вспомни, как ты учился писать! Да уж, занятия русского были очень скучными, но какие эффективные: мы все умеем писать и читать! Мне было не просто учиться. Я писал (да и до сих пор пишу) кривыми, неровными буквами с кучей ошибок, не понимая, в каком порядке и какие слова ставить. Запятых не было совсем, мысль была не собрана и воспринималась с трудом, либо была наивной и глупой, и в лучшем случае получалась не специально смешной.

Дети так мило пишут

Написав сотню сочинений и диктантов, проведя тысячи часов в безжалостных интернет баталиях, обсуждая симпатичные задницы и крутые 3д работы, публикуя картинки в соцсети, составляя тз, выдумывая оправдания, объяснительные, и написав несколько статей вроде этой — я научился делать внятные высказывания.

Трехмерке я научился точно так же: сотни маленьких и больших моделей, эксперименты с формами и композицией, изучение технологий и проекты самой разной сложности, от баловства до серъезного производства, от афиш с бутылками дешевого шампуня до работы с Wargaming, Gaijin и Blur — все это потихоньку учило меня читать и писать на языке арта. На самом деле большую часть моего опыта в 3д я не умел моделить хорошо, но коллеги и лиды заразили меня любопытством, и я сел изучать основы изобразительного искусства, на английском это называют «Fundamentals» (обычно показывается на 2д. Кажется, наша школа одна из первой стала показывать их в 3д пространстве, по крайней мере я не такого не видел, если знаете — пришлите мне). Конечно, существует тысяча толковых художников, которые утверждают, что они и без основ хорошо работают, но как правило они лукавят, а основы им помогают прокачать арт директора и коллеги. Я слушал какой-то выпуск арт кафе, в котором Мачей Кучара и Эш Торп обсуждают, как все детство рисовали на полях в тетрадях роботов и чудовищ, но настоящий прогресс начался, когда они доросли до фундаментальных основ.

«Лучше один раз увидеть, чем сто раз услышать» — простая поговорка, которая хорошо объясняет всю мощь визуального языка.

Сколько всего я рассказал о том, как сделать драфт, первый этап пайплайна, а ведь это только поверхностных охват темы! А как же остальные этапы? Например, чтобы издать книгу, текст нужно отдать на верстку и печать, и здесь тоже полно подводных камней: какие шрифты выбрать, как сверстать текст, где дефис «-» а где длинное тире «—», где “кавычки”, а где «ёлочки», нужно не забыть проверить на ошибки, отдать в печать: как печатать, лазером, струйным принтером или с помощью клише; какая краска пойдет на принтер, и сколько этой краски нужно, чтобы она хорошо отпечаталась и не растеклась; нужно нарезать и сшить листы, чтобы текст не был отрезан и сшит куда не надо; сделает обложку и отбить тиснение. Это не очевидный технический ритуал по превращению цифрового файла с текстом в бумажную книгу.

В трехмерке тоже есть есть большой технологический процесс, который нужно пройти, чтобы засунуть модель в игру. Какие здесь есть подводные камни? Да полно! В каком стиле должна быть модель, какой поликаунт, как попасть в масштаб, нужен ли нормал или нет, пбр шейдер или старый диффуз со спекуларом, а может и без спекулара, какой текстель, ракурс камеры, будет ли объект анимироваться, как заригать, как и где печь, не забыть сделать скосы для запечки, какие скульптить или генерить фактуры, какого разрешения будут текстуры, объект на переднем или заднем плане, правильно триангулировать, нужна ли альфа, какого цвета материалы, как паковать текстуры, как экспортнуть в движок, делать лилоды, создать геометрию коллизии, выставить свет, а это ведь вершина айзберга! В одном юви есть море своих заморочек: но об этом в другой раз. Самый популярный пайплайн в работе над современными играми выглядит так:

Драфт — хайполи — лоуполи — развертка — запечка — текстуры — экспорт в игру.

Но на самом деле пайплайны бывают разные, и с опытом художник вырабатывает собственный ритуал. Я в геймдеве предпочитал вот такой:

Драфт — лоуполи — хайполи — развертка — запечка нормала — фактуры — запечка остальных карт — драфт текстур — правка геометрии — полировка текстур — экспорт в игру.

Он чуть запутаннее популярного, но мне с ним удобнее работать, я знаю, что в большинстве моих моделей хайполи нужна только для фасок, фактуры я научился делать без скульпта, на этапе мапинга я не особо отслеживаю, правильно ли сделаны оверлапы, зато проверяю и правлю их после драфта текстур, а еще подгоняю все спорные места и швы, косяки на ао, нормале и колор айди.

А на мультфильме мой пайплайн был такой:

Драфт — покраска и риг драфта — экспорт для аниматика — мид поли — развертка — покраска — экспорт в проект.

Слева драфт, справа модель под рендер. Полностью показывать ее пока что нельзя, ждите весны.

Мне было важно быстро, не запариваясь на геометрию сделать симпатичный финальный меш, покрасить его и заригать, чтобы аниматоры к вечеру уже могли использовать эту геометрию в работе над черновым аниматиком. Как видишь, суть одна и та же, но на этапы работы влияют требования проекта. Для видео игр, например, не нужно было красить и ригать дратфы, зато приходилось запариваться над лоуполи и запечкой. Посмотрит пайплайн великолепной Inside. Просто≠примитивно, великолепная работа художников с силуэтами, светом, контрастами и цветами делает игру очень стильной, не смотря на простой пайплайн моделлера:

Драфт — лоуполи — покраска — риг — экспорт в игру.

Если статья бдет популярной — во второй части поговорим о том, как стиль и технологии формируют пайплайн. Я раскажу, насколько разный пайплайн у, кажется, одинаковых проектов: World of Tanks и War Thunder.

В школе XYZ мы провели целых три курса, в которых подробно разбираем все этапы пайплайна. Вот наши лекции о художественных и технических основах текстурирования, юви развертке и о работе с запеченым нормалом. У нас в дискорде таких видео еще навалом! Мы рассказываем обо всех этапах работы: драфте, лоуполи, хайполи, запечке карт, создании атласов и так далее.

Если ты хочешь пройти наши суровые и мощные курсы от А до Я и качнуть все этапы своего пайплайна, то пиши в личные сообщения группы. Твоя жизнь не никогда не будет прежней.

Я заебался это писать. А ты, дорогой Автор, просто Гришковец от мира статей по трехмерке. Пиши еще.

Источник

Руководство для начинающих: создаем DevOps-пайплайн

Если вы новичок в DevOps, взгляните на эту инструкцию по созданию вашего первого конвейера из пяти этапов.

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

Мое путешествие по DevOps

Раньше я работал в облачной команде Citi Group, разрабатывая веб-приложение Infrastructure-as-a-Service (IaaS) для управления облачной инфраструктурой Citi, но меня всегда интересовало, как сделать процесс развития более эффективным и привнести позитивные культурные изменения в команду разработчиков. Ответ я нашел в книге, рекомендованной Грегом Лавендером (Greg Lavender), техническим директором Citi по облачной архитектуре и инфраструктуре. Книга называлась «Проект Феникс» (The Phoenix Project), и в ней объясняются принципы DevOps, при этом она читается как роман.

В таблице на обороте книги показано, как часто различные компании развертывают свои системы в среде для выпуска релизов:

Amazon: 23 000 в день
Google: 5 500 в день
Netflix: 500 в день
Facebook: Раз в день
Twitter: 3 раза в неделю
Типичная компания: Раз в 9 месяцев

Как вообще возможны частоты Amazon, Google и Netflix? Все потому, что эти компании придумали, как сделать почти идеальный DevOps-конвейер.

Мы были далеки от этого, пока не внедрили DevOps в Citi. Тогда в моей команде были разные окружения, но развертывание на сервере разработки было полностью ручным. Все разработчики имели доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. Проблема заключалась в том, что сервер выключался всякий раз, когда несколько пользователей одновременно пытались выполнить развертывание, поэтому разработчики должны были сообщать друг другу о своих намерениях, что было довольно болезненно. Кроме того, существовали проблемы с низкоуровневым тестовым покрытием кода, громоздкими процессами ручного развертывания и отсутствием возможности отслеживать развертывание кода, связанного с определенной задачей или пользовательской историей.

Я понял, что нужно что-то делать, и нашел коллегу-единомышленника. Мы решили сотрудничать в создании первоначального DevOps-конвейера – он установил виртуальную машину и сервер приложений Tomcat, пока я работал над Jenkins, интегрировал Atlassian Jira и BitBucket, а также работал над тестовым покрытием кода. Этот сайд-проект был очень успешным: мы почти полностью автоматизировали многие процессы, достигли практически 100% работоспособности нашего сервера разработки, обеспечили отслеживание и улучшили тестовое покрытие кода, а также добавили возможность связывать ветки в Git с задачами в Jira или развертыванием. Большинство инструментов, которые мы использовали для построения нашего конвейера DevOps, имели открытый исходный код.

Теперь я понимаю, насколько простым был наш DevOps-пайплайн: мы не использовали расширения вроде Jenkins files или Ansible. Однако, этот простой конвейер работал хорошо, возможно, благодаря принципу Парето (также известному как правило 80/20).

Краткое введение в DevOps и пайплайн CI/CD

Если вы спросите несколько человек: «Что такое DevOps?», то вы, вероятно, получите несколько разных ответов. DevOps, как и Agile, развивался, чтобы охватить множество различных дисциплин, но большинство людей согласятся с некоторыми вещами: DevOps — это практика разработки программного обеспечения или жизненный цикл разработки программного обеспечения (SDLC), центральным принципом которой является изменение культуры, в которой разработчики и не-разработчики существуют в среде, в которой:

Автоматизированы операции, которые ранее выполнялись вручную;
Каждый делает то, что умеет лучше всего;
Количество внедрений за определенный отрезок времени увеличивается; Увеличивается пропускная способность;
Повышается гибкость разработки.

Хотя наличие правильных программных инструментов — не единственное, что нужно для создания среды DevOps, некоторые инструменты необходимы. Ключевой инструмент – непрерывная интеграция и непрерывное развертывание (CI/CD). В этом конвейере среды имеют различные стадии (например, DEV, INT, TST, QA, UAT, STG, PROD), многие операции автоматизированы, а разработчики могут писать высококачественный код, добиваться гибкости разработки и высокой частоты развертываний.

В этой статье описывается пятиэтапный подход к созданию DevOps-конвейера, аналогичного изображенному на следующей диаграмме, с использованием инструментов с открытым исходным кодом.

Шаг 1: Методы CI/CD

Первое, что вам нужно – инструмент для CI/CD. Jenkins, инструмент с открытым исходным кодом, основанный на Java, и распространяемый по лицензии MIT, является тем средством, которое популяризировало направление DevOps и стало стандартом де-факто.

Так что же такое Jenkins? Считайте, что это некий волшебный универсальный пульт дистанционного управления, который может разговаривать с различными службами и инструментами и организовывать их. Сам по себе CI/CD инструмент, такой как Jenkins, бесполезен, но он становится более мощным по мере того, как подключается к различным инструментам и сервисам.

Jenkins – всего лишь один из многих инструментов с открытым исходным кодом для CI/CD, который вы можете использовать для построения DevOps-пайплайна.

Jenkins: Creative Commons and MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Вот как выглядят DevOps-процессы с инструментом CI/CD:

У вас есть инструмент CI/CD, работающий на вашем локалхосте, но на данный момент вы мало что можете сделать. Давайте перейдем на следующий этап путешествия в мир DevOps.

Шаг 2: Управление системами контроля исходного кода

Лучший (и, возможно, самый простой) способ проверить, что ваш инструмент CI/CD может творить магию – интегрироваться с инструментом контроля исходного кода (SCM). Зачем вам нужен контроль над исходным кодом? Предположим, вы разрабатываете приложение. Всякий раз, когда вы создаете приложение, вы программируете, и неважно, используете вы Java, Python, C++, Go, Ruby, JavaScript или какой-нибудь из газиллионов языков программирования. Код, который вы пишете называется исходным кодом. В начале, особенно когда вы работаете в одиночку, вероятно, можно поместить все в локальную директорию. Но когда проект становится больше, и вы приглашаете других людей к сотрудничеству, вам нужен способ предотвращения конфликтов при эффективном обмене модификациями. Вам также нужен способ восстановления предыдущих версий, потому что создание бекапов и копирование/вставка в них уже устаревает. Вам (и вашим товарищам по команде) нужно что-то получше.

Именно здесь средство контроля исходного кода становится практически необходимостью. Этот инструмент сохраняет ваш код в репозиториях, ведет учет версий и координирует работу участников проекта.

Хотя существует множество инструментов контроля исходного кода, Git является стандартом, и это верно. Я настоятельно рекомендую использовать Git, хотя, если угодно, есть и другие варианты с открытым исходным кодом.

Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Так выглядит DevOps-пайплайн с добавлением средств контроля исходного кода.

Инструмент CI/CD может автоматизировать процессы проверки, получения исходного кода и сотрудничества между членами. Неплохо? Но как сделать из этого работающее приложение, чтобы миллиарды людей могли его использовать и оценить?

Шаг 3: Создание инструмента автоматизации сборки

Отлично! Вы можете проверять код и вносить изменения в систему контроля исходного кода, а также приглашать своих друзей к сотрудничеству в разработке. Но вы еще не создали приложение. Чтобы сделать веб-приложение, его нужно скомпилировать и упаковать в развертываемый пакетный формат или запустить в виде исполняемого файла. (Обратите внимание, что интерпретируемый язык программирования, такой как JavaScript или PHP, не нуждается в компиляции).

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

Здорово! Вы можете поместить файлы конфигурации инструмента автоматизации сборки в систему управления исходным кодом и позволить вашему инструменту CI/CD собрать все воедино.

Все хорошо, не так ли? Но где развернуть ваше приложение?

Шаг 4: Сервер для веб-приложений

Пока что у вас есть упакованный файл, который может быть как исполняемым, так и устанавливаемым. Для того чтобы любое приложение было действительно полезным, оно должно предоставлять какую-то службу или интерфейс, но вам нужен контейнер для размещения вашего приложения.

Сервер для веб-приложений представляет собой именно такой контейнер. Сервер обеспечивает среду, в которой может быть определена логика развертываемого пакета. Также сервер предоставляет интерфейс и предлагает веб-сервисы, открывая сокеты для внешнего мира. Вам нужен HTTP-сервер, а также некоторая среда (например, виртуальная машина) для его установки. А пока, давайте предположим, что вы узнаете об этом дальше (хотя я расскажу о контейнерах ниже).

Существует несколько серверов для веб-приложений с открытым исходным кодом.

Ваш DevOps-пайплайн почти готов к использованию. Хорошая работа!

Хотя на этом можно остановиться и заниматься интеграцией самостоятельно, качество кода – важная вещь для разработчика приложений, и об этом нужно беспокоиться.

Шаг 5: Покрытие тестирования кода

Реализация тестов может быть еще одним громоздким требованием, но разработчики должны ловить любые ошибки в приложении на ранней стадии и улучшать качество кода, чтобы гарантировать, что конечные пользователи будут удовлетворены. К счастью, существует множество инструментов с открытым исходным кодом для тестирования вашего кода и формирования рекомендаций по улучшению его качества. Еще лучше то, что большинство инструментов CI/CD могут подключаться к этим инструментам и автоматизировать процесс.

Тестирование кода состоит из двух частей: фреймворки для тестирования кода, которые помогают писать и запускать тесты, а также инструменты для формирования предложений, которые помогают улучшить качество кода.

Системы тестирования кода

Системы рекомендаций по улучшению кода

Обратите внимание, что большинство инструментов и фреймворков, упомянутых выше, написаны для Java, Python и JavaScript, поскольку C++ и C# являются проприетарными языками программирования (хотя GCC и имеет открытый исходный код).

Теперь, когда вы реализовали инструменты покрытия кода тестами, ваш DevOps-пайплайн должен быть похож на диаграмму, показанную в начале этого руководства.

Дополнительные шаги

Как я уже говорил, вы можете размещать свой сервер на виртуальной машине или сервере, но контейнеры являются популярным решением.

Что такое контейнеры? Краткое объяснение заключается в том, что виртуальная машина нуждается в огромном объеме памяти операционной системы, превышающем размер приложения, в то время как контейнеру нужно всего лишь несколько библиотек и конфигураций для запуска приложения. Очевидно, что у виртуальной машины все еще существуют важные области применения, но контейнер – это легкое решение для хостинга приложения, в том числе сервера приложений.

Хотя существуют и другие варианты контейнеров, наиболее популярными являются Docker и Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Промежуточные средства автоматизации

Наш DevOps-пайплайн в основном ориентирован на совместное создание и развертывание приложений, но существует множество других вещей, которые можно сделать с помощью DevOps-инструментов. Одной из них является использование инструментов Infrastructure as Code (IaC), которые также известны как средства промежуточной автоматизации. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного программного обеспечения. Так, например, инструмент автоматизации может извлекать приложения вроде сервера веб-приложений, базы данных и инструмента мониторинга, с правильными конфигурациями и развертывать их на сервере приложений.

Вот несколько инструментов промежуточной автоматизации с открытым исходным кодом:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache или GPL

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

Источник