[Git, Тестирование веб-сервисов, Системы сборки, DevOps] Идеальный пайплайн в вакууме
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Даже не зовите меня, если ваш pipeline не похож на это.На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):
Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc
Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.Почему это важно?
- Вопрос об идеальном пайплайне хорош тем, что он не содержит точного ответа.
- Кандидат начинает рассуждать, а в крутых специалистах ценится именно умение думать.
- Когда в вопрос добавляется такое абсолютное прилагательное, как "идеальный", то мы сразу развязываем кандидатам руки в просторе для творчества и фантазий. У соискателей появляется возможность показать, какие улучшения они видят (или не видят) в текущей работе, и что хотели бы добавить сами. Также мы можем узнать, есть ли у нашего предполагаемого будущего коллеги мотивация к улучшениям процессов, ведь концепция "работает — не трогай" не про динамичный мир DevOps.
- Организационная проверка. Позволяет узнать, насколько широка картина мира у соискателя. Условно: от создания задачи в Jira до настроек ноды в production. Сюда же можно добавить понимание стратегий gitflow, gitlabFlow, githubFlow.
Итак, прежде чем перейти к построению какого-либо процесса CI, необходимо определится, а какие шаги нам доступны?Что можно делать в CI?
- сканить код;
- билдить код;
- тестить код;
- деплоить приложение;
- тестить приложение;
- делать Merge;
- просить других людей подтверждать MR через code review.
Рассмотрим подробнее каждый пункт.Code scanningНа этой стадии основная мысль — никому нельзя верить.
Даже если, Вася — Senior/Lead Backend Developer. Несмотря на то, что Вася хороший человек/друг/товарищ и кум. Человеческий фактор, это все еще человеческий фактор.
Необходимо просканировать код на:
- соотвествие общему гайдлайну;
- уязвимости;
- качество.
Мне нужны твои уязвимости, сапоги и мотоцикл
Задачи на этой стадии следует выполнять параллельно. И триггерить только если меняются исходные файлы, или только если было событие git push.Пример для gitlab-ci
stages:
- code-scanning
.code-scanning:
only: [pushes]
stage: code-scanning
LintersЛинтеры – это прекрасная вещь! Про них уже написано много статей. Подробнее можно почитать в материале "Холиварный рассказ про линтеры".
Самая важная задача линтеров — приводить код к единообразию.
После внедрения этой штучки разработчики начнут вас любить. Потому что они наконец-то начнут понимать друг друга. Или ненавидеть, решив, что вы вставляете им палки в колеса линтеры в CI. Это уже зависит от ваших soft skills, культуры и обмена знаниями.ИнструментыИнструментОсобенностиeslintJavaScriptpylintPythongolintGolanghadolintDockerfilekubevalKubernetes manifestshellcheckBashgixynginx configetcCode Qualitycode quality — этими инструментами могут быть как продвинутые линтеры, так и совмещающие в себе всякие ML-модели на поиск слабых мест в коде: утечек памяти, небезопасных методов, уязвимостей зависимостей и т.д, перетягивая на себя еще code security компетенции.ИнструментыИнструментОсобенностиPriceSonarQubeПоиск ошибок и слабых мест в кодеОт €120CodeQLGithub native, поиск CVE уязвимостейOpenSource – freeetcCode SecurityНо существуют также и отдельные инструменты, заточенные только для code security. Они призваны:
- Бороться с утечкой паролей/ключей/сертификатов.
- Cканировать на известные уязвимости.
Неважно, насколько большая компания, люди в ней работают одинаковые. Если разработчик "ходит" в production через сертификат, то для своего удобства разработчик добавит его в git. Поэтому придется потратить время, чтобы объяснить, что сертификат должен храниться в vault, а не в git
ИнструментыИнструментОсобенностиPricegitleaksИспользуется в Gitlab Security, может сканить промежуток от коммита "А" до коммита "Б".FreeshhgitЗапустили недавно Enterpise Edition.От $336etcСканер уязвимостей необходимо запускать регулярно, так как новые уязвимости имеют свойство со временем ВНЕЗАПНО обнаруживаться.
Да-да, прямо как Испанская Инквизиция!Code CoverageНу и конечно, после тестирования, нужно узнать code coverage.
Процент исходного кода программы, который был выполнен в процессе тестирования.
ИнструментыИнструментОсобенностиPricego coverДля Golang. Уже встроен в Golang.FreecoberturaРаботает на основе jcoverage. Java мирFreecodecovСтарая добрая классикаFree до 5 пользователейetcUnit testМодульные тесты имеют тенденцию перетекать в инструменты code quality, которые умеют в юнит тесты.ИнструментыИнструментОсобенностиphpunitPHP (My mom says I am special)junitJava (многие инстурменты поддерживают вывод в формате junit)etcBuildЭтап для сборки artifacts/packages/images и т.д. Здесь уже можно задуматься о том, каким будет стратегия версионирования всего приложения.За модель версионирования вы можете выбрать:
- semVer (пример с gitflow);
- romVer;
- номер cборки;
- datetime, timestamp;
- etc
Во времена контейнеризации, в первую очередь интересуют образы для контейнеров и способы их версионирования.Инструменты для сборки образовИнструментОсобенностиdocker buildПочти все знают только это.buildx / buildkitПроект Moby предоставил свою реализацию. Поставляется вместе с докером, включается опцией DOCKER_BUILDKIT=1.kanikoИнструмент от Google, позволяет собирать в юзерспейсе, то есть без докер-демона.werfРазработка коллег из Флант'а. Внутри stapel. All-in-one: умеет не только билдить, но и деплоить.buildahOpen Container Initiative, Podman.etc Итак, сборка прошла успешно – идем дальше. Scan packageПакет/образ собрали. Теперь нужно просканировать его на уязвимости. Современные registry уже содержат инструментарий для этого. ИнструментыИнструментОсобенностиЦенаharborDocker Registry, ChartMuseum, Robot-users.FreenexusЕсть все в том числе и Docker.Free и proartifactoryКомбайн, чего в нем только нет.Free и proetcDeployСтадия для развертывания приложения в различных окружениях. 
Деплоим контейнер в прод, как можем.Не все окружения хорошо сочетаются со стратегиями развертывания.
- rolling – классика;
- recreate – все что угодно, но не production;
- blue/green – в 90% процентов случаев этот способ применим только к production окружениям;
- canary – в 99% процентов случаев этот способ применим только к production окружениям.
StatefulНужно еще помнить, что даже имея одинаковый код в stage и production, production может развалиться именно из-за того, что stateful у них разный. Миграции могут отлично пройти на пустой базе, но появившись на проде, сломать зеленые кружочки/галочки в пайплайне. Поэтому для stage/pre-production следует предоставлять обезличенный бэкап основной базы.И не забудьте придумать способ откатывания ваших релизов на последний/конкретный релиз.ИнструментыИнструментОсобенностиhelmwaveDocker-compose для helm. Наша разработка.helmСобираем ямлики в одном месте.argoCD"Клуб любителей пощекотать GitOps".werf.ioБыло выше.kubectl / kustomizeДля тех, кто любит сам придумывать шаблонизацию.etcНа правах рекламы скажу что helmwav'у очень не хватает ваших звезд на GitHub. Первая публикация про helmwave.Integration testingПриложение задеплоили. Оно где-то живет в отдельном контуре.Наступает этап интеграционного тестирования. Тестирование может быть как ручным, так и автоматизированным. Автоматизированные тесты можно встроить в пайплайн.ИнструментыИнструментОсобенностиSeleniumМожно запустить в кубере.SelenoidБеды с образами. Требует Docker-in-Docker.etcPerformance testing (load/stress testing)Данный вид тестирования имеет смысл проводить на stage/pre-production окружениях. С тем условием, что ресурсные мощности на нем такие же, как в production.Инструменты, чтобы дать нагрузкуИнструментОсобенностиwrkОтличный молоток. Но не пытайтесь прибить им все подряд.k6.ioCтильно-модно-JavaScript! Используется в AutoDevOps.Artillery.ioСнова JS. Сравнение с k6jmeterOldSchool.yandex-tankПерестаньте дудосить конурентов.etcИнструменты, чтобы оценить работу сервисаИнструментОсобенностиsitespeed.ioВнутри: coach, browserTime, compare, PageXray.LighthouseТулза от Google. Красиво, можешь показать это своему менеджеру. Он будет в восторге. Жаль, только собаки не пляшут.etcCode Review / ApprovedОдним из важнейших этапов являются Merge Request. Именно в них могут производиться отдельные действия в pipeline перед слиянием, а также назначаться группы лиц, требующих одобрения перед cлиянием.Список команд/ролей:
- QA;
- Security;
- Tech leads;
- Release managers;
- Maintainers;
- DevOps;
- etc.
Очевидно, что созывать весь консилиум перед каждым MR не нужно, каждая команда должна появится в свой определённый момент MR:
- вызывать безопасников имеет смысл только перед сливанием в production;
- QA перед release ветками;
- DevOps'ов беспокоить, только если затрагиваются их компетенции: изменения в helm-charts / pipeline / конфигурации сервера / etc.
Developing flowЧаще всего каждая компания, а то и каждый проект в компании, решает изобрести свой велосипед-флоу. Что после нескольких итераций приходит к чему-то, что может напоминать gitflow, gitlabFlow, githubFlow или все сразу. Это и не хорошо, и не плохо – это специфика проекта. Есть мнения, что gitflow не торт. GithubFlow для относительно маленьких команд. А про gitlabFlow мне нечего добавить, но есть наблюдение, что его не очень любят продакты - за то, что нельзя отслеживать feature-ветки.Если вкратце, то:
- Gitflow: feature -> develop -> release-vX.X.X -> master (aka main) -> tag;
- GitHubFlow: branch -> master (aka main);
- GitLabFlow: environmental branches.
TL;DRОбщий концепт
_Feature-ветка
Pre-Production -> Production
P.S.Если я где-то опечатался, упустил важную деталь или, по вашему мнению, пайплайн недостаточно идеальный, напишите об этом мне – сделаю update.
Разработчик создал ветку и запушил в нее код. Что дальше?
Оставляйте варианты ваших сценариев в комментариях.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Go, Микросервисы] Как писать кодогенераторы в Go
- [DevOps, Kubernetes] Рациональное использование ресурсов в Kubernetes (перевод)
- [Тестирование IT-систем, Системное администрирование, IT-инфраструктура, Тестирование веб-сервисов, Service Desk] Application performance monitoring and health metrics without APM (перевод)
- [Тестирование веб-сервисов, Управление продуктом, Статистика в IT] How to choose the appropriate level of statistical significance for an AB-test
- [Карьера в IT-индустрии, DevOps] Собеседование в DevOps Engineering, как оценить свой опыт и сколько нужно знать?
- [Настройка Linux, Сетевые технологии, Big Data, DevOps] Сеть в bitly: Linux tc для минимизации издержек и забавы ради (перевод)
- [Open source, GitHub, Разработка под Windows, Софт, IT-компании] В репозитории пакетного менеджера winget много дубликатов, плохо сформированных пакетов и искаженных манифестов
- [Системное администрирование, Облачные вычисления, DevOps, Kubernetes] Self-Hosted, или Kubernetes для богатых: почему самостоятельное развертывание кластера — не всегда способ сэкономить
- [Java, Тестирование веб-сервисов] Как найти все битые ссылки на странице с помощью Selenium (перевод)
- [Системное администрирование, Программирование, Облачные вычисления, DevOps] Видкаст Хабр ПРО: битва при DevOps
Теги для поиска: #_git, #_testirovanie_vebservisov (Тестирование веб-сервисов), #_sistemy_sborki (Системы сборки), #_devops, #_ci/cd, #_pipeline, #_devops, #_continious_integration, #_linter, #_automatization, #_continious_delivery, #_continious_testing, #_continious_inspection, #_blog_kompanii_rabota.ru (
Блог компании Работа.ру
), #_git, #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_sistemy_sborki (
Системы сборки
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 17-Май 00:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
 Даже не зовите меня, если ваш pipeline не похож на это.На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне): Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc
Даже если, Вася — Senior/Lead Backend Developer. Несмотря на то, что Вася хороший человек/друг/товарищ и кум. Человеческий фактор, это все еще человеческий фактор.
 Мне нужны твои уязвимости, сапоги и мотоцикл  Задачи на этой стадии следует выполнять параллельно. И триггерить только если меняются исходные файлы, или только если было событие git push.Пример для gitlab-ci stages:
- code-scanning .code-scanning: only: [pushes] stage: code-scanning Самая важная задача линтеров — приводить код к единообразию.
Неважно, насколько большая компания, люди в ней работают одинаковые. Если разработчик "ходит" в production через сертификат, то для своего удобства разработчик добавит его в git. Поэтому придется потратить время, чтобы объяснить, что сертификат должен храниться в vault, а не в git
 Да-да, прямо как Испанская Инквизиция!Code CoverageНу и конечно, после тестирования, нужно узнать code coverage. Процент исходного кода программы, который был выполнен в процессе тестирования.
 Деплоим контейнер в прод, как можем.Не все окружения хорошо сочетаются со стратегиями развертывания.
 _Feature-ветка  Pre-Production -> Production  P.S.Если я где-то опечатался, упустил важную деталь или, по вашему мнению, пайплайн недостаточно идеальный, напишите об этом мне – сделаю update. Разработчик создал ветку и запушил в нее код. Что дальше?
=========== Источник: habr.com =========== Похожие новости:
Блог компании Работа.ру ), #_git, #_testirovanie_vebservisov ( Тестирование веб-сервисов ), #_sistemy_sborki ( Системы сборки ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 17-Май 00:25
Часовой пояс: UTC + 5