что такое пайплайн проекта
Семь паттернов пайплайнов непрерывной поставки
Прямо сейчас у вас есть шанс успеть на курс по специальной цене. Узнать подробности.
В настоящее время гибкость бизнеса часто основана на гибкости кода. Возможность быстрых и безопасных релизов по требованию для современных цифровых продуктов и услуг является реальным конкурентным преимуществом.
С 2004 года мы разрабатываем, собираем и развертываем пайплайны кода для автоматизации приложений и инфраструктур. В этой статье мы делимся семью паттернами, которые улучшают скорость, гибкость и качество, при одновременном повышении автономности, прозрачности и удобства обслуживания.
Непрерывная поставка
Непрерывная поставка (Continuous Delivery) — это «возможность надежно и быстро поставлять изменения всех типов в руки пользователей». Если посмотреть на непрерывную поставку по матрице Agile vs Effort, то можно увидеть, что она находится прямо между непрерывной интеграцией и непрерывным развертыванием. Часто их вместе называют CI / CD.
В отчете о состоянии DevOps за 2019 год более 31 000 респондентов сообщили об эффективности своих процессов разработки и поставки. Но разница между лидерами и отстающими ошеломляет. У лидеров в 200 раз больше развертываний и в 100 раз выше скорость развертывания, а также в 2 600 раз быстрее восстановление после инцидентов и в 7 раз меньше вероятность отката релизов.
Это исследование показывает, что для лидеров скорость и стабильность не противоположны! Вы можете получить и то и другое (на самом деле вам нужно и то и другое), чтобы получить реальные конкурентные преимущества для ваших цифровых продуктов и услуг.
Пайплайны
Пайплайны (конвейеры) — это основные технические артефакты непрерывной поставки. Современные пайплайны преобразуют исходный код приложения и инфраструктуры в версионированные пакеты, которые можно разворачивать в любой среде. Автоматизируя все рутинные задачи по сборке и развертыванию систем, разработчики могут сосредоточиться на реализации действительно полезных фич.
Хотя пайплайны кода существуют уже почти 20 лет — CruiseControl, один из наших первых любимцев, был выпущен в 2001 году, — они значительно эволюционировали за последние годы.
Основываясь на нашем опыте и опыте наших клиентов, мы выделили семь паттернов пайплайнов, которые мы наблюдали во многих современных технологических компаниях.
Паттерны пайплайнов
Паттерн 1 — пайплайны как код
Логика пайплайна кодируется и хранится вместе с кодом приложения и инфраструктуры. Для выполнения пайплайнов используются контейнеры.
Никаких настроек через графический интерфейс! Вся логика пайплайна управляется, как и любой другой код приложения, и подчиняется тем же стратегиям ветвления и ревью.
Для образов контейнеров сред сборки используются проверенные Docker-образы.
Конфигурация CI runner автоматизированная, одинаковая и не требует ручной настройки. CI runner при необходимости могут масштабироваться и находиться в режиме ожидания для минимизации задержек.
Секреты хранятся вне пайплайнов, а их вывод маскируется, что повышает безопасность.
Паттерн 2 — перенос логики в повторно используемые библиотеки
Общая логика пайплайнов выносится в повторно используемые библиотеки, на которые можно ссылаться из кода пайплайнов, а также независимо их разрабатывать и тестировать.
Относитесь к пайплайн-библиотекам как к любому другому программному обеспечению. У них есть собственные репозитории, пайплайны, модульные тесты и релизы.
По возможности для запуска внешних задач пайплайны используют специфичные для языка инструменты, такие как Make, Rake, npm, Maven и т.п. Для того чтобы упростить пайплайн и сохранить идентичность процесса локальной сборки и CI.
Библиотеки легко найти и у них хорошая документацию.
Паттерн 3 — отдельные пайплайны для сборки и развертывания
Пайплайны сборки и развертывания должны быть логически разделены, управляться и запускаться независимо. Должна быть возможность как автоматического, так и ручного запуска.
Должна быть одна сборка и много развертываний. Сосредоточьтесь на сборке. В ее результате появляются артефакты, которые можно развернуть несколько раз.
Будьте независимы от окружения. При отсутствии пакетов, специфичных для окружения, и вынесения параметров в переменные окружения, одна и та же сборка может работать в любой среде.
Упакуйте всё вместе. Всё — весь исходный код, включая код инфраструктуры, должен храниться вместе, чтобы стать версионнированным пакетом.
Паттерн 4 — запуск правильного пайплайна
Коммиты в ветки, пул реквесты и слияние с основной веткой — всё это может инициировать различное поведение пайплайна, оптимизированное под конкретную команду.
Открытие pull request’а создает эфемерную среду для тестирования.
Слияния с основной веткой развертываются в не-продакшн или демо-среде, содержащей последний интегрированный код.
Создание новых тэгов приводит к выпуску релиза.
Паттерн 5 — быстрая обратная связь
Каждый коммит автоматически запускает определенный пайплайн. При этом пайплайны сборки специально оптимизированы для скорости и быстрого оповещения о возникающих проблемах.
Пайплайны сборки используют распараллеливание для независимых друг от друга заданий с целью повышения производительности.
Быстрые пайплайны сборки выполняют необходимые задания за несколько минут.
Каждый успешный запуск завершается созданием версии пакета и результатами статического анализа.
С помощью многоканальных уведомлений вы можете настроить оповещения о статусе пул реквестов на дашбордах, в чатах, по электронной почте и др.
Паттерн 6 — стабильные внутренние релизы
Развертываются только версионнированные пакеты, созданные пайплайном сборки. Эти развертывания запускаются вручную или автоматически по событиям.
Каждая ветка кода получает полное эфемерное окружение, названное в соответствии с именем ветки, которое можно легко создать или уничтожить.
Любой инженер может создать или удалить эфемерную среду.
CI runners используют возможности cloud-native IAM с временными разрешениями, чтобы получить необходимые роли и разрешения для выполнения своей работы.
Паттерн 7 — история релизов
Разверните тегированные релизы в продакшн, автоматизируйте отчетность и оставьте историю развертываний.
«Релизный шлюз» (release gate) в виде кода и стандартизированные процессы релиза позволяют выпускать релизы по требованию.
Автоматизированные релизы оставляют историю, которую можно проанализировать в дальнейшем.
Release gate может вызывать внешние API и использовать ответ, чтобы решить продолжать релиз или остановить его.
Проблемы
Мы все чаще встречаем эти семь паттернов пайплайнов и используем их при работе с клиентами. Но несмотря на то что они представляют собой огромный скачок вперед с точки зрения скорости и стабильности, они не лишены недостатков.
Безопасность — это самая большая проблема, которую мы видим. Она связана со сложностью автоматизации процессов, которые традиционно были ориентированы на человека. Сложность пайплайнов, принятие командой, изменение в культуре и автоматизация баз данных — другие серьезные проблемы, над которыми нужно работать. Но это все решаемо, и мы ежедневно работаем над этим.
Гибкость бизнеса основана на гибкости кода. Для современных цифровых продуктов и сервисов возможность быстрого и безопасного релиза по требованию является реальным конкурентным преимуществом бизнеса. Пайплайны кода и, в частности, описанные семь паттернов могут помочь вашей организации сделать гигантский шаг вперед в скорости и стабильности релизов, а ваши команды будут работать на уровне лидеров.
Советы стартаперам: как использовать воронки для продаж, поиска инвестиций и рекрутинга
управляющий портфелем фонда the Untitled ventures
Человек человеку волк? Сегодня пословицу стоит перефразировать: человек становится человеку карточкой в воронке контактов (pipeline). От самого поверхностного общения до близких связей, от статуса подписчика до статуса самого лояльного клиента. И пусть не смущает, эти воронки существуют не только в бизнес-рамках, но и в быту.
Иногда даже кажется, что этих всех «пайплайнов» упоминается столько, что начинаешь теряться. Именно поэтому решили разобраться и сделать полноценную инструкцию по тому, что такое «пайплайн» и как использовать возможности в разных функциях по максимуму.
Что такое воронка / пайплайн?
Воронка — это принцип построения процесса в несколько стадий: шаг 1, шаг 2, шаг 3 и так до результата (продажи / инвестиции / подходящего кандидата на должность). Каждый шаг снижает количество элементов внутри. Написали десяти людям, потом поговорили по телефону только с пятью, дали ответное предложение только трем, а заключили договор вообще с одним.
Как правило, воронку продаж разделяют на 4 основных этапа:
Как понять эффективность вашего подхода?
Только небольшое количество людей готовы принимать решения быстро и стремительно. Для многих это ступенчатая задача от лида до клиента / пользователя. И чтобы не потерять по дороге важные контакты, а также экономить время на решения по коммуникациям, появилось понятие pipeline management. Это управление воронкой, создание рамок и принципов.
Здесь есть два показателя успеха: количественный и качественный. Первый выражается в соотношении каждой стадии с последующей (или просто между стадиями) и отмечается понятием «конверсия». Конверсия от договора к первой письменной коммуникации в нашем предыдущем примере — 10%. Как работают с увеличением конверсии — в сценариях ниже.
Качественный — это выявление слабых мест в бизнес-процессах. Например, проблема в медленном ответе. С этим обычно справляются через установление 24-часового стандарта внутри команды («умри, но ответь менее чем за 24 часа»). Проверяется гипотеза — если это не сильно увеличивает «проходимость», то стандарт снимается или меняется.
Поиск инвестора онлайн стал намного проще. Узнай как
Какие еще преимущества дает управление воронкой?
Воронка vs. Платформа
Иногда я встречаю мнение о том, что стартап должен выбирать: воронка или платформа (Pipes or Platforms), отбирать или делать открытую витрину, прогонять по стадиям (и уменьшать) или давать всем возможность стать участником. И, мол, аргументы не в сторону воронок.
К счастью, это становится все менее актуально — можно делать и то, и другое! И в разных форматах. Собственно, мало кто разбирает конкретные функции и дает конкретные рекомендации. Вызов принят!
Воронка продаж
Возьмем самую распространенную функцию — продажи. Часто стадии прохождения воронки здесь подразделяются исходя из статуса попадающего в пайплайн:
Конверсия от каждого этапа зависит от сектора и индустрии: в самом «тяжелом» случае (В2В, промышленность или какие-то продукты по безопасности) — может быть 1 клиент на 100 MQL. А в В2С-секторе с, например, игровым продуктом становиться клиентом может каждый второй заходящий на страницу App Store.
Рекомендации для управления воронкой в продажах:
Какие технологические решения могут быть полезны?
CRM-системы (для ведения контактов/карточек в пайплайне) — Salesforce (14 дней — бесплатный пробный период), AgileCRM (до 10 пользователей — бесплатный тариф), «Битрикс24» (до 12 пользователей бесплатно)
Email and call tracking tools (приложения для отслеживания доставки и отслеживания писем и звонков) — Mailtrack (для Gmail, базовые функции бесплатно), для отслеживания звонков можно использовать комплексное решение для клиентского сервиса — например, Voximplant (бесплатно до 1000 активных пользователей в месяц).
Другое — Grammarly (для проверки грамматических ошибок на английском, базовые функции бесплатно)
Воронка фандрайзинга / привлечения инвестиций
Фандрайзинг иногда связывают с продажами, но с более долгим циклом и сложностями на пути (все-таки инвестиционное соглашение — это не оферта!). Мы же рассмотрим функцию отдельно — потому что гораздо больше нелинейных сценариев. И это нормально.
Посмотрим на статусы контактов в таком пайплайне (и на их конверсию — в скобках). Здесь все достаточно однородно для разных индустрий и стадий):
Рекомендации для управления воронкой в фандрайзинге:
Какие технологические решения могут быть полезны?
CRM-системы и task managers (удобно вести под именно фандрайзинг) — HubSpot (бесплатно до 1000 контактов/1000 имейлов), Pipedrive (14 дней — бесплатный пробный период).
Task managers — Trello (базовые функции бесплатно), Notion (базовые функции бесплатно).
Другое — VPN-приложения (TouchVPN / NordVPN) для того, чтобы без проблем использовать популярный LinkedIn.
Воронка HR / найма сотрудников
Рекрутинг — это немного отличающаяся от предыдущих функция, но с теми же принципами пайплайна внутри. Только теперь команда стартапа (а не внешний человек) принимает решение.
Какие статусы и конверсии находятся в воронке?
У стартапов часто сокращаются процессы, но все стадии схожи. Что рекомендуем конкретно для стартапов:
Какие технологические решения могут быть полезны?
Индустриальные решения для парсинга / выгрузки с сайтов по поиску работы — Talantix (1 месяц — бесплатная пробная версия), Skillaz.
Автоматизация онлайн-этапа отбора (интервью/ скрининг) — VCV (10 видео-резюме в месяц), Робот Вера.
Другое — Upwork (для работы с фрилансерами), Founders2Be (поиск кофаундеров).
Слово дня. Что такое пайплайн?
(кстати, внизу – мультик на английском языке)
В последнее время в нашу с вами жизнь мощным потоком хлынули новые слова и выражения – коворкинг, рекрутинг тьюторов, блокчейн, кванториум, форсайт-кэмп, визионерская лекция, акслератор, рибейт и многие другие.
Давайте не будем сейчас обсуждать, хорошо это или плохо, а попробуем разобраться, что эти слова означают. Чтобы не отстать от жизни, надо быть в курсе. Поэтому предлагаем начать со слова пайплайн, которое встретилось нам вчера и удивило нас не меньше, чем многих читателей. В пресс-релизе говорилось: « Пайплайн Агентства развития Новгородской области пополнился новыми инвестпроектами»
В английском языке слово pipeline имеет несколько значений – трубопровод, нефтепровод; канал (связи, коммуникации); процесс разработки, доработки; система распространения (товаров и информации). Нас в данном случае больше интересует значение – процесс разработки (подготовки, производства).
Часто слово пайплайн используют, обозначая прогноз продаж, контрактов, ожидаемых поступлений от существующих и перспективных клиентов.
Пайплайн инвестиционного фонда – входящая линия стартапов, которые присылают заявки на инвестиции. Это некий «портфель» инвестпроектов, о чем и говорилось в статье.
Пайплайн в маркетинге – важная концепция для всех маркетологов B2B; формирование качественного плана продаж по клиентам; ключевой показатель эффективности, который позволяет анализировать упешность инвестиций в маркетинг для определения ожидаемой выручки от них.
Также пайплайн в продажах – это инструмент, который помогает оценить движение по сделкам у конкретного сотрудника отдела продаж. Такой анализ и контроль позволяют прогнозировать результат и при необходимости корректировать работу менеджера.
Добавим, что в интернете можно встретить материалы, связанные с пайплайном в разных сферах. Например, в мультипликации и киноиндустрии.
«Пайплайн – последовательный план производства анимации, фильма или компьютерной графики – от сценария до монтажа и выпуска на экран. Пайплайн устанавливает порядок действий, обозначает инструменты и сроки для каждой задачи: в итоге, каждый знает, когда и как именно он взаимодействует с другими участниками процесса», — сообщает сайт mastera.academy.
Чтобы наглядно показать, что такое пайплайн, анимационная студия DreamWorks выпустила обучающий мультфильм с пингвинами из «Мадагаскара» в главных ролях (мультфильм на английском языке).
Идеальный пайплайн в вакууме
На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):
Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc
Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.
Почему это важно?
Вопрос об идеальном пайплайне хорош тем, что он не содержит точного ответа.
Кандидат начинает рассуждать, а в крутых специалистах ценится именно умение думать.
Когда в вопрос добавляется такое абсолютное прилагательное, как «идеальный», то мы сразу развязываем кандидатам руки в просторе для творчества и фантазий. У соискателей появляется возможность показать, какие улучшения они видят (или не видят) в текущей работе, и что хотели бы добавить сами. Также мы можем узнать, есть ли у нашего предполагаемого будущего коллеги мотивация к улучшениям процессов, ведь концепция «работает — не трогай» не про динамичный мир DevOps.
Организационная проверка. Позволяет узнать, насколько широка картина мира у соискателя. Условно: от создания задачи в Jira до настроек ноды в production. Сюда же можно добавить понимание стратегий gitflow, gitlabFlow, githubFlow.
Итак, прежде чем перейти к построению какого-либо процесса CI, необходимо определиться, а какие шаги нам доступны?
CI/CD-пайплайн на примере одного небольшого проекта Уральской Дирекции ИТ
Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.
Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.
Вступление
Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.
С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.
Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).
Так получилось в одном небольшом новом проекте в Уральской Дирекции ИТ, в которой удалось в весьма сжатые сроки реализовать полный пайплайн от публикации изменений исходников в системе контроля версии разработчиком до автоматического запуска новой версии приложения в тестовой среде.
Часть 0. Описание задачи
Архитектура системы
После некоторых обсуждений командой была выбрана следующая двухуровневая архитектура:
Чего хотелось команде
Как только новому проекту был дан зеленый свет, появилась первая техническая задача, а именно – подготовка «оборудования» для запуска нового проекта. Поскольку всем участникам было очевидно, что без максимальной оперативности выкатки новых версий на серверы развитие проекта будет весьма непростым, сразу же было решено идти по пути полного CI/CD, т.е. хотелось достичь следующего пайплайна:
Рамки
Кроме того, эта статья касается только веб-ориентированных приложений, а также рассказывает об идеальном случае stateless-архитектуры, когда данные наверняка где-то есть, но они далеко, и мы об их хранении не задумываемся.
Часть 1. Установка и базовая настройка ПО на хост-системе
С целью максимальной автоматизации и высокой воспроизводимости всей цепочки хост-систему (виртуальная машина на базe VMWare / qemu KVM / облако / что-то еще) было решено настраивать с использованием системы управления конфигурацией Ansible.
Стоит добавить, что в дополнение к легкой повторяемости и воспроизводимости, использование подобных систем (кроме Ansible, существуют также системы Puppet и Chef) обладает огромным преимуществом перед использованием разнообразных shell- или python- скриптов в виде наличия идемпотентности, т.е. свойства, при котором при повторных запусках итоговое состояние системы не изменяется.
Данное преимущество вытекает из того факта, что при использовании систем управления конфигурациями описывается не процесс достижения желаемого состояния, а само желаемое состояние в декларативной форме.
1.1 ssh HostKeyChecking
По умолчанию, Ansible уважает безопасность и проверяет ssh-отпечаток удаленного конфигурируемого хоста. Т.к. в данном режиме отключена возможность авторизации по паролю, то при первоначальной настройке сервера требуется либо отключить HostKeyChecking, либо предварительно добавить отпечаток в локальный кеш. Последнего можно достичь целыми двумя путями:
Определить специальную переменную окружения:
Добавить в локальный конфигурационный файл ansible.cfg параметр host_key_checking:
При первом способе проверка отключается только пока существует такая переменная окружения, а при втором – полностью для этого хоста.
1.2 Inventory
Inventory – это сущность в системе Ansible, с помощью которой описываются хосты и их группы, конфигурацией которых необходимо управлять.
Inventory можно описывать в формате ini или yaml. В данном проекте был выбран последний.
Пример файла hosts.yml:
Для впервые столкнувшихся с форматом yaml хотелось бы отметить, что все отступы в данном формате необходимо оформлять пробелами.
1.3 Playbook
Playbook – это еще одна сущность в Ansible, в которой непосредственно декларативно описывается желаемое конечное состояние хостов и групп из Inventory. Так же, как и почти все в Ansible, playbook описывается в файле(-ах) в yaml-формате.
Для того чтобы запустить на выполнение playbook-файл, необходимо выполнить команду вида:
В данном playbook-е описывалась полная настройка базовой системы с созданием необходимых пользователей и установкой Docker-а:
Часть 2. Сервисы проекта
2.1 CI-сервер и процесс
За процесс «непрерывной интеграции и деплоймента» в проекте отвечает хорошо многим известный сервер Jenkins CI.
Код Ansible playbook-и выше устроен так, что в конце его выполнения на сервере уже запущен свежеустановленный Jenkins (в Docker-контейнере), а его временный пароль сохранен на ЛОКАЛЬНОЙ машине в файле initialJenkinsAdminPassword.txt.
Поскольку всей команде хотелось максимально приблизиться к идеальному случаю Infrastructure as code (IaC), то в проекте таски были реализованы в виде декларативных и скриптованных пайплайнов Jenkins-а, когда задачи описываются на языке Groovy Script, а сам их код хранится рядом с исходниками проекте в системе контроля версий (git).
Пример пайплайна сборки backend-части приложения на Spring Boot показан ниже:
Отдельно хотелось бы отметить, что при сборке образов каждая версия получает свой тег (метку), что значительно облегчает процесс авторестарта приложения.
2.2 Portainer
Для облегчения взаимодействия всех членов команды с Docker в проекте нами был использован простой веб-интерфейс для него – Portainer. Данное приложение, так же, как и сам Docker, написано на языке Go, а поэтому отличается высокой производительностью при чрезвычайно легком развертывании.
Например, в простейшем случае следующая команда приведет к запуску Портейнера на порту 9000 хост-системы:
Однако, в текущем проекте было решено воспользоваться функциональностью средства «оркестрации» для одного хоста – Docker Compose.
2.3 Docker-контейнеры и сервисы
Все необходимые приложения и сервисы в данном проекте запускаются посредством простого файла docker-compose.yml.
Базовый набор «инфраструктурных» сервисов запускается посредством следующего описания:
2.4 Docker Swarm-кластер без кластера
Как можно видеть в файле docker-compose.yml выше, во-первых, отсутствуют упоминания бэкенд и фронтенд- частей приложения, а также присутствует ссылка на «внешнюю» (external: true) сеть по имени int. Внешними являются любые ресурсы (сети, тома и другие существующие сущности), не объявленные в одном файле.
Дело в том, что в проекте нам требовалась иметь возможность проводить рестарт «сервисов» при обновлении версии образа в Docker-репозитории Artifactory, а подобные функции присутствуют в сервисах Docker Swarm (встроенная в Docker multi-master система оркестрации Docker-контейнеров) что называется «из коробки». Данная возможность реализуется через возможность изменить требуемый образ у запущенного сервиса, и при наличии новой версии образа в репозитории перезапуск произойдет автоматически. В случае же, если версия не изменилась – сервисный контейнер продолжает штатно выполняться.
Что касается сети, запуская приложение в виде сервиса Docker Swarm (yaml-описание представлено ниже), нам требовалось сохранить сетевую связность его компонентов и сервера NGINX, объявленного выше. Это было достигнуто через создание на сервере кластерой Overlay-сети, в которую включались и базовые сервисы, описанные выше, и непосредственно компоненты приложения:
Описание компонентов приложения c двумя сервисами: