Комментарии 32
А возможности для разработчика задеплоить куда-то из своей feature-ветки вы не предусматриваете?
А как насчет большего кол-ва сред для деплоя? Например в моих текущих продуктах помимо stage'а есть еще dev, который крушат разработчики в процессе своих тестов чтобы не ломать stage
dev/stage/prod — самая частая композиция с которой я сталкивался. Бывали еще случаи с нескольким кол-вом тестовых сред (например с добавлением regression), но это единичные
Это если смотреть лишь со стороны инфраструктуры. Не менее важная функция докеризации — это деливери продукта от разработчика в целостном неизменяемом виде. 2 сервера под сайтик за 2 года зарастают таким мхом, что потом проще переставлять всё с нуля.
- делается на каком-нибудь web-фреймворке или генераторе статических сайтов;
- хранит исходники в системе контроля версий;
- кодится и тестируется хипстером (вариант — хардкор-девелопером-отцом) на своем макбуке с макосью (вариант — леново со слакой) с докер-контейнерами для тестовой базы и тестовым redis, потому что их проще всего поднять и погасить.
Из этого состояния, как мне кажется, идея настроить авто-деплой в кубернетис-кластер посредством конфиг-файла, который помещается вместе с исходниками, выглядит достаточно привлекательно и почти совсем не оверхед.
Какие есть альтернативы для сайта с котиком? Делать руками git pull на виртуалке с сайтиком при изменениях сорца и настроить там хуки, чтобы переподнимать сервис при обновлении? Сделать ansible-плейбук и запускать его вручную? Написать скрипт для тревиса, который подключится к github-у (вариант — описать bitbucket-pipeline), который scp-скопирует файлы в целевую виртуалку и перезапустит service по ssh?
К альтернативным способам тоже есть вопросы. Как бы это делали вы?
- провайдеры сетей — резервируются
- облачные провайдеры, если их возможно использовать до определённого уровня абстракции, не понижая его до уровня vendor lock-in — взаимозаменяемы
- софт, библиотеки, пакеты — эти зависимости продукта и среды замораживаются на уровне конкретных версий, и с ними продукт тестируется вдоль и поперёк
- Производители железа — без комментариев
"Мерж dev в release" →
"Заведение таска на обнаружение уязвимостей" →
"Обнаружение уязвимостей" →
"Уязвимости не обнаружены" →
"Информировании о получении неудовлетворительного результата" →
"Заведение таска на исправление"
:)
Подробнее может alexey-lustin рассказать. И да, как выразился Xandrmoro, основной вопрос был в опасении передачи своих исходников куда-то.
У DevOps полно задач помимо контроля площадок: настройка конфигурации с которой запускается проект на разных площадках, управление всяческими ключами/паролями, масштабирование, оптимизация CI по скорости сборки, подготовка и обновление базовых образов докера используемых приложением, etc.
Что до Security Engineer, то на схеме отсутствует основная точка, где необходимо контролировать наличие уязвимостей — ревью кода на pull/merge request. Плюс есть такая штука как архитектурные уязвимости, поэтому крайне желательно дополнительное ревью ТЗ между этапами его написания и декомпозиции задач разработчикам. Причём, по моему опыту, зачастую в проектах нет ресурсов на отдельный этап "Обнаружение уязвимостей" перед релизом, но есть возможность контролировать их на ревью в описанном мной стиле.
"commit кода в репозиторий" →
"Запуск автотестов" →
"Информировании о получении неудовлетворительного результата" →
"Заведение task'а на исправление"
Никто так не делает при запуске тестов после коммита, это совершенно жуткая излишняя бюрократизация, все необходимые исправления кода чтобы тесты прошли делаются в рамках изначальной задачи.
"code-review (ручное)" →
"Получение положительного результата"
А что, отрицательного на ваших ревью не бывает? Это вообще основная проблема схемы — в каких-то местах она избыточно (и некорректно) детальна, а в других местах отсутствует масса негативных веток (скорее всего потому, что они бы дико усложнили схему — вроде отмены фичи или переделки ТЗ в связи с фактами проявившимися в процессе реализации). Но Вы ведь вроде бы сервис хотите сделать, так вот сервис как раз такие ситуации учитывать обязан.
"merge кода из feature в dev" →
"запуск автотестов"
Пустая трата времени, тесты этого коммита уже выполнились перед ревью.
"merge кода из release в master" →
"Заведение task'а на создание документации"
Плохая привычка, документацию нужно писать одновременно с кодом, и, в идеале, мержить в том же PR что и фичу.
Ещё одна плохая привычка — наделять ветку master конкретным смыслом. В таких схемах лучше использовать названия веток по их сути (feature, dev, staging, pre-prod, prod), потому что в разных проектах ветка master может быть синонимом любой из них (кроме feature).
Из важных этапов пропущена одна нетривиальная тема: миграции БД. Ещё пропущены сложные задачи постепенного (с обновлением только части узлов) выката новой версии на prod и откат prod при проблемах (что может потребовать отката и миграции БД).
Постановка задач, хранение кода и артефактов, task-tracker — Gitlab, Redmine, S3
Redmine это кошмар, лучше посмотрите на Youtrack — я с ним работал мало, но по первому впечатлению это самый юзабельный трекер из имеющихся в данный момент (если не считать гитхабовского, но он не очень подходит если в проекте несколько репо и с трекером должны активно работать менеджеры и бизнес).
Кстати, а как вы смотрите на то, если в рамках платформы будет
возможность выбора — захотел, выбрал Jenkins, не захотел — GitLab Runner?
Очень положительно. А ещё лучше, чтобы из коробки был именно GitLab Runner, а не Jenkins.
Или же не важно, что внутри, главное, чтобы всё как надо билдилось, тестилось и деплоилось?
Может, когда-нибудь, в далёком будущем, когда оно будет работать как часы. А пока всё это продолжает создавать проблемы лучше понимать, что под капотом и иметь возможность это фиксить.
«commit кода в репозиторий» →
«Запуск автотестов» →
«Информировании о получении неудовлетворительного результата» →
«Заведение task'а на исправление»
Никто так не делает при запуске тестов после коммита, это совершенно жуткая излишняя бюрократизация, все необходимые исправления кода чтобы тесты прошли делаются в рамках изначальной задачи.
Я думал все так делают. Если конечно речь о пуше в удаленный репозиторий, а не коммите в локальную ветку.
В схеме в этом месте речь об открытом pull/merge-request. Т.е. создали фиче-бранч под таску, написали кода и тестов, сделали git push на гитхаб, CI по этому пушу запустил тесты, которые провалились. Кто-то действительно в этот момент будет создавать отдельную таску "пофиксить проваливающиеся автотесты"?
1) сделали фича бранч и написали код, прогнали тесты
2) сделали пул-реквест в мастер (девелоп)
3) после создания пул-реквеста автоматичски запускаются тесты
4) если тесты прошли успешно, то можем мержить (т.е. по хорошему кнопка мерж должна быть физически заблокированна до успешной сборки и прогона тестов)
5) если тесты провалились, то делаем тикет на фикс кода или теста(смотря что сломалось) и фиксим его
В маленьких командах можно, конечно, так не делать, а просто локально прогнать тесты и сделать пул-реквест или запушить в девелоп (мастер) сразу. Но это на начальных этапах разработки и (или) на проектах где можно себе позволить сломать мастер (дев) энв.
Когда команда большая, лучше подстраховаться и прогнать тесты перед мержем. Из 50 человек за год обязательно кто-то забудет запустить тесты локально, или специально не запустит т.к. будет уверен что он не может ошибиться, или из-за спешки сознательно не запустить тесты чтобы быстрее фикс на прод доставить.
Подход именно такой, но я писал о том, что в пункте 5 нет никакого смысла создавать отдельный тикет, фиксить это надо в рамках исходной задачи — собственно, пока ветка этой задачи не смержена (а мерж автоматом блокируется если не проходят тесты) — задача не считается закрытой, так что все работы до мержа продолжаются в её рамках.
Главный вопрос который повис «Зачем?». Я не против того чтобы рос уровень компетенции на российском рынке. Я только за! Ребята вы молодцы! Так держать!
Если бы мне пришлось отвечать за выбор, то я бы не стал бы выносить в аутсорс или компетенцию критически важных компонентов производственного процесса. Чем и является то самый pipeline который вы хотите предложить как услугу.
Эту задачу обзовём как AutoDevops решает и MS с его слиянием TFS + github.
И Gitlab у которого есть и CI и СD. недавно прикрутили разваривание нодов для Kubernetes одним кликом. Gitlab отлично интегрируется со множеством инструментов и сервисов. Если будет ещё одни сервис, который решает похожую задачу отлично я только за.
Для меня devops это философия, набор лучших практик. Но всё это нужно применять аккуратно и с учётом со спецификой бизнеса и команды. По мне, devops это не только технологии, но и коммуникации между участниками процесса. Последние вы не затронули, её в схеме нет. В тоже время вы предлагаете devops как готовое решение, что крайне амбициозно.
Так же очень странно сам посыл заменить devops. Опять же я из хожу, что devops-инженера нету. Это просто инженер-программист. Поэтому что вы хотите заменить? Как вы хотите помочь бизнесу? Какие задачи хотите на себя взять? Почему вы считаете, что знаете как строить pipeline лучше чем сам разработчик? Как вы хотите предугадывать потребности разработчиков и бизнеса?
Вы позиционируете свой инструмент как универсальный devops решение. Но в вашей схеме нет работу с моделями и зависимостями, нету chatops. Да и ваше решение вряд ли справиться с проектами, который разрабатываются под embedded и desktop.
Пару слов про потенциальный рынок. Моё мнение такое, что вы ориентируется на маленькие команды, или начинающие проекты. Это значит, что в плане потока денег от них будет не очень. Раз не очень, то развивать свой продукт будет крайне сложно.
Я думаю, что средний и крупный бизнес вряд ли вашим продуктом заинтересуются.
— С точки зрения безопасности, плохая идея выносить важный процессы на аутсорс.
— Сами могу себе позволить создать и настроить под себя свой pipeline.
— Удобнее из компонентов собрать свой pipeline, нежели купить супер-пупер комбайн и с ним долго разбираться.
Подытожим. У меня два основных вопроса:
1. Зачем? Если есть куча инструментов из них можно построить свой pipeline.
2. Почему вы считаете что ваша компетенция в данном вопросе лучше чем у всех остальных?
Спасибо!
1. Мы хотим сделать не просто набор инструментов из которых можно собрать pipeline, а интегрировать их, связать предварительными настройками и сделать единый фронт.
Особое внимание мы хотим уделить фичам по мониторингу реализации задач исполнителями — быстрый срез основных метрик, начало этапов сборки/тестирование/деплоя, процент выполнения ревью кода, процент документирования, соответствия стандартам кода и т.д.
А также удобным механизмам для сбора KPI и отображение в виде наглядных дашбородов, которые позволят бизнесу видеть оперативные показатели качества работы команд — скорость, качество кода, делать бенчмаркинг по показателям между командами, проверять результативность изменений в работе команд (как меняются показатели по результатам изменений. Примеры изменений — длина спринта, методы тестирования), а также выявлять тенденции деградации показателей для принятия мер по диагностике и устранению причин.
2. Мы не утверждаем, что у нас больше компетенций, например по Kubernetes, чем у специалистов Google. Мы опираемся на опыт нашей внутренней разработки, а также на ряд уже реализованных on-premise проектов (достаточно кастомизированных) для наших заказчиков.
Ещё один момент — совершенно не обязательно ограничиваться бесплатными продуктами при сборке pipeline. Многие могут захотеть держать код в приватных репо на гитхабе, или собирать в CircleCI.
Мы хотим заменить девопсов скриптом (на самом деле нет): разработчики, нужно ваше мнение