Pipeline что это в программировании

Пайплайн — Основы командной строки

Вы уже знаете, что у одного процесса есть вход, а у другого — выход. При этом их можно подменять. Логично предположить, что их можно и соединить. Этот подход носит название пайплайн (от англ. pipeline). Именно пайплайнам мы уделим внимание в этом уроке.

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

Когда мы учились грепать, то делали это по какому-то одному слову. Но часто возникает задача погрепать по нескольким словам. Не важно, как они расположены внутри строки, главное, что они встречаются там вместе.

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

grep alias .bashrc | grep color # enable color support of handy aliases alias grep='grep --color=auto' alias fgrep='fgrep --color=auto' alias egrep='egrep --color=auto' 

Обратите внимание на | — этот символ называется пайп. Он указывает, что командная оболочка должна взять поток STDOUT одного процесса и соединить его с потоком STDIN другого процесса.

Все утилиты, которые читают файлы, могут принимать данные через поток STDIN. Поскольку утилита grep принимает на вход и возвращает текст, то его можно комбинировать бесконечно:

Запись grep alias .bashrc | grep color можно изменить, используя перенаправление. Так она станет проще для модификации:

cat .bashrc | grep alias | grep color 

В примере выше файл читается катом и отправляется в поток STDIN грепа.

Еще один пример:

cat source | grep Dog | uniq | sort 

Посмотрим, как этот пример работает по шагам:

1. Читается файл source
2. Грепаются входные данные по подстроке Dog
3. Убираются дубли (в исходном файле две одинаковых строки Dog )
4. Сортируются входные данные и выводятся на экран

Пайплайн стал основой философии Unix, которая звучит так:

• Пишите программы, которые делают что-то одно и делают это хорошо
• Пишите программы, которые бы работали вместе
• Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс

Именно поэтому большинство утилит работают с сырым текстом — принимают его на вход и возвращают в поток STDOUT.

Такой подход позволяет получать сложное поведение из крайне простых составных блоков. Такая концепция называется стандартные интерфейсы и хорошо отражена в конструкторах Lego.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Пайплайн

Пайплайн (от английского pipeline — «трубопровод») — это документ, визуализирующий процесс разработки продукта. Он представляет собой последовательность этапов, расположенных так, что конец предыдущего является началом следующего. Благодаря этому создается эффект производственного конвейера или трубопровода, по которому проект движется от первоначальной идеи до конкретного продукта.

«IT-специалист с нуля» наш лучший курс для старта в IT

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

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

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

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

Рассмотрим структуру пайплайна на условном примере разработки компьютерной игры.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Препродакшен (подготовка к производству)

Продолжительность от недели до года, примерно 20% от всего времени разработки.

1. Разработка общей концепции игры: сюжета, особенностей геймплея, главных игровых механик.
2. Определение целевой аудитории.
3. Анализ рынка и конкурентов.
4. Выбор платформы для реализации.
5. Выбор механизма монетизации (если это коммерческий продукт).
6. Планирование сроков разработки.
7. Расчет денежных, материальных и людских ресурсов для разработки.

Выход на этапе препродакшена

Документ игрового дизайна (GDD), включающий:

• концепцию игры;
• жанр;
• сюжет и персонажей;
• основную игровую механику;
• геймплей;
• общий дизайн мира или одного из уровней;
• арты и эскизы;
• механизм монетизации.

Прототип — первоначальный «отрывок» из игры для демонстрации общей идеи. Он не обязательно должен быть играбельным — часто это раскадровка на бумаге, набор артов или небольшой видеоролик . Если создается играбельный прототип, на этом этапе он наполняется низкокачественными моделями.

Продакшен (производство)

Самый продолжительный этап — от 1 года до 4 лет.

1. Создание первого играбельного прототипа с более качественными моделями и фонами для демонстрации игровой механики, возможностей геймплея, общего дизайна будущей игры.
2. Создание «вертикального фрагмента» игры — отрывка длиной от получаса до часа для демонстрации инвесторам или студиям. Он дает почувствовать игровой опыт таким, каким тот будет в финальном релизе.
3. Создание преальфа-версии игры с реализацией полноценного сценария, большинства игровых механик и дизайна. На этом этапе большая часть контента уже добавлена, но возможно его дополнение или сокращение для оптимизации игрового процесса.
4. Создание альфа-версии игры, то есть полноценного релиза, в который можно поиграть от начала и до конца. На этом этапе добавлены все геймплейные возможности и функции, элементы управления. Но остается возможность для их дополнения и/или корректировки.
5. Альфа-тестирование игры сотрудниками (тестировщиками) самого разработчика с последующей доработкой найденных ошибок.
6. Бета-тестирование игры добровольцами из целевой аудитории для получения обратной связи и как часть продвижения продукта на рынок. Доработка предрелизной версии, устранение выявленных недостатков.

Выход на этапе продакшена

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

Постпродакшен

1. Исправление ошибок после релиза финальной версии, выпуск патчей.
2. Создание бонусного контента: DLC, дополнительных персонажей, локаций и т.д.
3. Обновление текстур, моделей персонажей, добавление новых визуальных эффектов и т.д.
4. Сервисная поддержка пользователей — например, в многопользовательских онлайн-играх.

Выход на этапе постпродакшена

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

Это пример общего пайплайна для разработки компьютерной игры, каждый из этапов которого можно тоже представить в виде более узкого «конвейера» со своими этапами и работами. Например, нам нужно ввести в игру нового персонажа, для чего можно составить следующий пайплайн:

• Разработка идеи — проведение мозгового штурма, поиск у конкурентов или в других источниках, отбор лучших вариантов.
• 2D-моделирование — отрисовка двухмерной модели в трех проекциях, эскиза персонажа без фона и в «естественном окружении».
• 3D-моделирование — создание трехмерной модели, наложение цвета и текстур.
• Анимирование — создание виртуального скелета персонажа и его «оживление».
• Интеграция в игру — настройка механик персонажа, добавление визуальных и звуковых эффектов.
• Тестирование персонажа — проведение плей-тестов, настройка игрового баланса, поиск и устранение ошибок, рекомендации по улучшению.
• Релиз — публикация персонажа в игровом дополнении или в онлайн-магазине, получение фидбэка от аудитории, анализ маркетинговых метрик, исправление оставшихся ошибок.

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

Станьте дата-сайентистом и решайте амбициозные задачи с помощью нейросетей

Контроль выполнения пайплайнов

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

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

Это не универсальные метрики. В практике конкретного разработчика они могут быть дополнены или скорректированы в зависимости от условий работы, особенностей корпоративной культуры, специфики проекта и т.д. Тем не менее какие-то критерии должны быть, в противном случае оценить эффективность работы невозможно.

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

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

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

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

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

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

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

Frontend-разработчик

Научитесь создавать удобные и эффектные сайты, сервисы и приложения, которые нужны всем. Сегодня профессия на пике актуальности: в России 9000+ вакансий, где требуется знание JavaScript.

Статьи по теме:

Специалист по компьютерному зрению рассказывает, как увлечение рептилиями помогло перейти из юриспруденции в Data Science.

Михаил Белоус объясняет, почему хороший специалист участвует во всех процессах анализа данных: от сбора до построения модели

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

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

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

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

Пайплайн CI/CD: что это такое, как применяется в разработке и bad practices

Продолжаем тему CI/CD ( Continuous Integration , Continuous Delivery) : в предыдущей части блога мы разобрались, что это за технология и как она может сэкономить рабочее время разработчику. Теперь расскажем о нюансах работы с CI/CD -пайплайнами, плохих практиках, а также версионировании как способе менеджмента изменений в коде.

Детям из Мариуполя нужно 120 ноутбуков для обучения — подари старое «железо», пусть оно работает на будущее Украины

Пайплайн

При объединении CI и CD получаются пайплайны. Все о них слышали, но часто трактуют это понятие по-разному. В одном проекте пайплайном могут назвать отдельную фичу или задачу. Это отчасти верно. И действительно, пайплайн — это последовательность определенных действий, разделенных на логические единицы: сборка проекта, тесты, загрузка артефактов в хранилище, деплой и т.д.

Чтобы избежать недоразумений, на старте проекта или присоединяясь к новой команде согласуйте со всеми привлеченными командами одно значение пайплайна. У вас могут быть CI-пайплайны, CD-пайплайны или их комбинации. Без окончательного определения термина вы будете тратить время на постоянные уточнения. Кто-то создаст у Jira тикет с фразой “У меня не работает пайплайн”. И здесь у вас возникнет вопрос: речь о проблемах со сборником или деплоем?

Учить вас создавать пайплайны в этой статье не будем, но базовые моменты рассмотрим. В первую очередь определите, кто, чем и как занят. Затем зафиксируйте желаемый результат. Пайплайн должен иметь смысл. А главное, им должны пользоваться все. Часто бывает, что кто-то создал хороший пайплайн, но все делают по старинке, как привыкли. Обязательно объясняйте коллегам пользу от введения новых подходов. Ведь CI/CD — это постоянное взаимодействие со всеми членами команды.

Типичный сценарий применения пайплайна

Рассмотрим универсальную модель решения любой задачи. Начнем с получения разработчиком таска – в Jira или на митинге. Далее он создает отдельный бранч в системе контроля версий, пишет код или вносит исправления, локально тестирует, создает пул реквест и просит кого-нибудь отревьюить результат. Затем остается соединить эту ветку с основной, собрать и задеплоить на dev-окружение.

Це хороший спосіб розвитку вашої кар’єри в IT-індустрії. Після проходження курсу Mate гарантує вам офер мрії.

Допустим, на все это вы потратили неделю. 90-95% времени ушло на написание кода, а на сопутствующие действия и деплой понадобилось, скажем, 2 часа. Это логическое соотношение. Но если на исправление микробага нужно 10 минут, а на сборку и деплой ушел час, то в процессе есть проблемы. Если придется исправлять по 10 микробагов в день, тогда все время будет идти на сборку и деплой.

Ситуация имеет два решения:

• Подвинуть изменения во времени . Вы можете оттягивать момент слияния изменений в основной бранч. Так вы увеличите количество изменений в пул реквесте, который создадите впоследствии. Однако ревьюировать полотно кода вместо пары строк сложно и рискованно.
• Настройка CI/CD-пайплайн . Этот инструмент автоматически собирает проект, тестирует и деплоит на dev-окружении. Такой подход экономит время и сокращает вероятность сбоев из-за человеческого фактора.

А еще важно сделать локальную среду сборки приближенной к серверу непрерывной интеграции. Это также обезопасит от проблем в будущем. Уделяйте внимание стандартизации процессов. По нормам CI/CD, любая фича считается выпущенной глобально только тогда, когда пройдет все стадии пайплайна. Исключений быть не может. Иначе теряется суть CI/CD. В теме пайплайнов стоит хотя бы чуть-чуть затронуть чекеры. Если мы имеем в виду анализ исходного кода, то это статический анализ. Он касается качества кода, покрытия тестами, поиска уязвимых мест. А в случае тестирования программы, которая уже задеплоена в окружение, это динамический анализ.

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

Bad practices в пайплайнах

• Связанные с пайплайном ресурсы не версионируются.

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

Использование shell-скриптов.

Курс Проджект-менеджмент в IT.

Навчайся у найкращих, курс проводить Тарас Федорук, найкращий PM за версією Ukrainian IT Awards у 2019 році.

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

• Неверная последовательность пайплайн-стейджей.

Все должно происходить по плану. Нельзя, например, деплоить что-нибудь на продакшен, а затем запускать тестирование.

Цепочка действий должна выполняться от начала до конца. Иногда есть соблазн пропустить какой-то этап. Например, в шаге тестов предусмотрено 1000 проверок, но 1-2 из них проблемные, они разрушают весь пайплайн. Можно пропустить шаг, но не стоит. В таком случае лучше попросить QA-команду устранить сбои или удалить те проблемные тесты, а оставшиеся 998 пусть работают дальше.

• Запуск некоторых пайплайнов вручную.

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

Недопустимо в пайплайнах. Причины такие же, как в CI- и CD-частях.

Неиспользование параметризированных задач.

Курс Управління командою в бізнесі.

Онлайн-курс для ефективного управління командою, спрямований на створення проактивних та самостійних команд, де мікроменеджмент не потрібний.

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

• Отсутствие нейминга или неумение его делать.

Джоб- и пайплайнам следует подобрать наименование. Почему это важно? При неудачном нейминге на CI-сервере могут возникать дубликаты. Это особенно распространено на крупных проектах, где несколько команд занимаются одинаковыми задачами. Кроме этого, невнятные названия усложняют поиск нужных джобов. Вам придется тратить время, чтобы определить, что делает та или иная джоба, или это вам действительно нужно.

Недостаток тестов на продообразном stage-окружении.

Здесь все просто: вы должны убедиться в качестве продукта до его деплоя на продакшене.

Можно что-то протестовать уже на продакшене. Для этого существует особая техника: выбираете несколько тестов, запускаете их и креститесь… Если опустить иронию, как вы могли понять, так делать нельзя.

Версионирование как способ менеджмента изменений в коде

Жизненный цикл программы так или иначе связан с ее версиями. Без упоминания версии непонятно, о каком приложении идет речь, какой у него функционал, исправлены ли баги и т.д. Также без версионирования существует большой риск получить несовместимость между отдельными модулями или блоками, используемыми в приложении. К примеру, при переходе с версии 3.1 на 4.0 может перестать работать основной функционал. Стандартное версионирование подразумевает определенную совместимость продуктов.

Основная функция версий – навигация. Это можно сравнить с GPS-метками только для кода.

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

Это самый распространенный подход. Он предполагает несколько вариантов. Простейшие номера по порядку: 1, 2, 3… Также они могут иметь дробную часть: 1.1 или 2.5. Популярная троичная система: с мажорной версией, минорной и фикс-версией. Тогда последняя цифра изменяется при фиксации багов без кардинальных изменений в функционале. Средняя цифра обновляется с появлением новых фич и обратной совместимости программы. Первая мажорная цифра корректируется при большом апдейте или несовместимости с прошлым релизом.

Вариант обозначения только буквами латинского алфавита не очень распространен из-за ограниченности набора символов. Буквы могут использоваться в троичной системе для фикс-версии: 1.3.b, 4.2.c и т.п.

Обозначают этап процесса разработки продукта. Это могут быть альфа- и бета-версии, релиз-кандидаты, сервис-релизы и т.д.

Простая и понятная система — с универсальным порядковым элементом в виде даты, когда была запущена новая версия.

Этот подход удобен с точки зрения маркетинга, поскольку пользователю легче запоминать слова, а не набор цифр. В качестве примера — подход к версионированию в Ubuntu, где версия может называться вроде Focal Fossa. Если сомневаетесь, какую концепцию для наименования версий выбрать или вообще не хотите тратить на это время, советуем брать SemVer — семантическое версионирование. Этот стандарт создал соучредитель GitHub Том Престон Вернер. SemVer сочетает в себе последовательность чисел с троичной системой. Позволяет использовать этапы сборки или дополнительные метки типа частей, хешей и комитов. Попав в действующий проект, вам остается принять существующую систему версионирования. Единственное – убедитесь, что концепция подробно описана в Confluence или другой wiki-системе проекта. В документе должно быть описано, как проводится версионирование, как оно связано с процессом разработки, как команда с ним взаимодействует, какой этап релизов и т.д. Таким образом, все участники разработки будут понимать, что происходит на проекте.

Взаимодействие с командами

В любом крупном проекте далеко не один разработчик и даже не одна команда. Среди специалистов могут быть несколько разработчиков, тестировщиков, отдельно релиз- и security team. Однако не все из них могут знать о существовании смежных команд, не говоря уже об их задачах. Если не считать этого, то некоторые специалисты или команды начнут работать над одной задачей, но не будут знать всех нюансов. Получится два полуготовых решения. Для CI/CD такая ситуация неприемлема.

При внедрении CI/CD-процессов кому-то придется изменять обычное течение работы. Поэтому необходимо правильно доносить людям причины перемен. Не потому, что кому так захотелось, а потому, что так лучше для проекта. В конце концов, авторы покаскадной модели, поставившие планировку на первое место, в этом были правы. Строя пайплайны, нужно заранее обсудить все нюансы. А дальше остается держать руку на пульсе перемен и корректировать работу. Не зря же существует трактовка CI как Continuous Improvement – ​​регулярные улучшения. К внедрению CI/CD коллег следует готовить заранее. Иногда для постройки пайплайна достаточно нескольких минут и десяток кликов. Но обычно это более длительный процесс. Поинтересуйтесь ходом работ и планами каждой команды. В противном случае могут возникнуть серьезные трудности с интеграцией новых идей в уже созданный пайплайн.

Сопоставляйте усилия и результаты

Время – бесспорно самый ценный ресурс, и CI/CD экономит его.

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

В конце концов, IT — это не технологии ради технологий. Это, прежде всего, бизнес. Если использование CI/CD занимает больше, чем экономит, задумайтесь, что пошло не так.

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Курс UI/UX для геймдеву.

Під час навчання ви розробите проекти для портфоліо, що складається з 5 ключових аспектів UX/UI-дизайну, та отримаєш необхідні навички для професійного росту.

Главная > Блоги > DevOps > Пайплайн CI/CD: что это такое, как применяется в разработке и bad practices

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.