
Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLabЧитать полностью »
Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLabЧитать полностью »
Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:
Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье «Как мы выносили СУБД (и не только) из review-окружений в статическое». В этой статье рассмотрен более простой путь — запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.Читать полностью »
Этот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.
Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.
Доброго времени суток, читатель!
22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).
Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:
В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.
Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »
Мы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его русскоязычная версия — ru.werf.io). Это обычный статический сайт, однако его сборка интересна тем, что построена с использованием динамического количества артефактов.
Вдаваться в нюансы структуры сайта: генерацию общего меню для всех версий, страницы с информацией о релизах и т.п. — не будем. Вместо этого, сфокусируемся на вопросах и особенностях динамической сборки и немного на сопутствующих процессах CI/CD.Читать полностью »
Два года назад мы публиковали статью «Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений», а теперь расскажем о решении схожей задачи сегодня. Новый материал — о том, как можно построить CI/CD-процессы для большого количества однотипных приложений с появлением include
в .gitlab-ci.yml
и приходом werf на замену dapp.Читать полностью »
Данный пост написан по заявкам трудящихся, которые с завидной периодичностью спрашивают о том "Как запустить Illuminate / Symfony / MyOwnPsr7 приложение в докере". Давать ссылку на ранее написанный пост уже не хочется, так как взгляды относительно того, как следует решать поставленную задачу, довольно сильно изменились.
Всё, что будет написано ниже, является субъективным опытом, который (как и всегда) не претендует на право считаться единственно верным решением, но некоторые подходы и решения, возможно, тебе покажутся интересными и полезными.
В качестве приложения так же буду использовать Laravel, так как он мне наиболее знаком и довольно широко распространен. Адаптировать под другие PSR-7-based фреймворки/компоненты возможно, но этот рассказ не про это.
Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!
Для начала обозначу контекст:
Цели данной публикации:
Consumer Driven Contracts
В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.
Для продолжения нам необходимо познакомиться с основными положениями CDC: