Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLabЧитать полностью »
Рубрика «gitlab ci»
Review- или динамические окружения. Теория и практика в Kubernetes
2021-08-09 в 9:08, admin, рубрики: devops, gitlab ci, kubernetes, review environments, werf, Блог компании Флант, динамические окружения, системное администрированиеЗапускаем тесты на GitLab Runner с werf — на примере SonarQube
2020-11-09 в 7:13, admin, рубрики: continuous delivery, devops, gitlab, gitlab ci, sonarqube, werf, Блог компании Флант, Тестирование веб-сервисов
Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:
- непосредственно в кластере K8s — с помощью отдельных Job или Helm hooks;
- «снаружи» K8s — например, на сервере сборки/деплоя или локально у разработчиков.
Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье «Как мы выносили СУБД (и не только) из review-окружений в статическое». В этой статье рассмотрен более простой путь — запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.Читать полностью »
Тесты на pytest с генерацией отчетов в Allure с использованием Docker и Gitlab Pages и частично selenium
2020-08-01 в 19:51, admin, рубрики: allure, docker, gitlab ci, gitlab pages, python, qa automation, системы сборки, Тестирование веб-сервисовЭтот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.
Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.
Аутентификация и чтение секретов в HashiCorp’s Vault через GitLab CI
2020-07-28 в 11:28, admin, рубрики: devops, Git, gitlab ci, integration, jwt, security, Vault, Блог компании Nixys, информационная безопасностьДоброго времени суток, читатель!
22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).
Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:
GitLab CI: 6 фич из последних релизов, которых мы так ждали
2020-03-16 в 9:06, admin, рубрики: devops, Git, gitlab, gitlab ci, Блог компании Флант, системное администрирование
В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.
Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »
Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
2020-01-16 в 8:31, admin, рубрики: continuous delivery, devops, docker, gitlab ci, werf, Блог компании Флант, сборка проекта, системы сборкиМы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его русскоязычная версия — ru.werf.io). Это обычный статический сайт, однако его сборка интересна тем, что построена с использованием динамического количества артефактов.
Вдаваться в нюансы структуры сайта: генерацию общего меню для всех версий, страницы с информацией о релизах и т.п. — не будем. Вместо этого, сфокусируемся на вопросах и особенностях динамической сборки и немного на сопутствующих процессах CI/CD.Читать полностью »
Сборка и деплой однотипных микросервисов с werf и GitLab CI
2019-10-07 в 10:57, admin, рубрики: continuous delivery, devops, gitlab, gitlab ci, helm, kubernetes, werf, Блог компании Флант, микросервисы, системы сборки
Два года назад мы публиковали статью «Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений», а теперь расскажем о решении схожей задачи сегодня. Новый материал — о том, как можно построить CI/CD-процессы для большого количества однотипных приложений с появлением include в .gitlab-ci.yml и приходом werf на замену dapp.Читать полностью »
Docker + Laravel + RoadRunner = ❤
2019-07-30 в 14:52, admin, рубрики: devops, gitlab ci, laravel, php, roadrunner, системы сборки
Данный пост написан по заявкам трудящихся, которые с завидной периодичностью спрашивают о том "Как запустить Illuminate / Symfony / MyOwnPsr7 приложение в докере". Давать ссылку на ранее написанный пост уже не хочется, так как взгляды относительно того, как следует решать поставленную задачу, довольно сильно изменились.
Всё, что будет написано ниже, является субъективным опытом, который (как и всегда) не претендует на право считаться единственно верным решением, но некоторые подходы и решения, возможно, тебе покажутся интересными и полезными.
В качестве приложения так же буду использовать Laravel, так как он мне наиболее знаком и довольно широко распространен. Адаптировать под другие PSR-7-based фреймворки/компоненты возможно, но этот рассказ не про это.
JUnit в GitLab CI с Kubernetes
2019-07-26 в 6:37, admin, рубрики: continuous integration, devops, gitlab, gitlab ci, junit, kubernetes, werf, Блог компании Флант, системное администрирование, Тестирование IT-системНесмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!
Вводные
Для начала обозначу контекст:
- Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
- Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
- В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).
Consumer Driven Contracts или Gitlab CI глазами QA test automation
2019-05-09 в 13:16, admin, рубрики: Consumer Driven Contracts, gitlab ci, pact, python, микросервисы, Тестирование веб-сервисов, Тестирование мобильных приложенийЦели данной публикации:
- Краткое введение в Consumer Driven Contracts (CDC)
- Настройка CI pipeline на основе CDC
Consumer Driven Contracts
В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.
Для продолжения нам необходимо познакомиться с основными положениями CDC:
- Контактное тестирование находится на уровне Service/Integration Tests над Unit Tests согласно пирамиде автотестирования (Mike Cohn)
- Контрактное тестирование может применяться, когда есть 2 (или более) сервиса, которые взаимодействуют друг с другом
- Сonsumer driven подход означает, что первым шагом в реализации является написание теста на стороне потребителя. Результатом теста является пакт (контракт) в формате json, который описывает взаимодействие между потребителем (например, веб-интерфейс / мобильный интерфейс: сервис, который хочет получить некоторые данные) и поставщиком (например, серверный API: сервис, который предоставляет данные)
- Следующим шагом является проверка договора с провайдером. Это полностью осуществлено фреймворком Pact.Читать полностью »