Рубрика «системы сборки»

Настраиваем Continuous Integration для Jenkins и Bitbucket с werf - 1

Утилита werf создана так, чтобы её было легко интегрировать с любыми CI/CD-системами. Подробнее об этом процессе в общем случае читайте в эпилоге этой статьи, но основное её содержимое — практический пример по организации CI в Jenkins и Bitbucket.

Подразумевается, что в результате наших действий мы ожидаем получить следующее:

  1. Shared Library для Jenkins, чтобы все сценарии CI хранились в одном месте и их можно было править единым коммитом.
  2. Интеграцию Jenkins с Bitbucket, чтобы запускать CI по коммиту в определенные ветки или по созданию тега.

Поехали!Читать полностью »

Сборка Hello World с помощью Bake
Сборка Hello World с помощью Bake

Наверное, большинство из вас согласится, что на сегодняшний день наибольшую популярность среди систем сборки для проектов на C/C++ имеет CMake. Каково же было мое удивление увидеть в проекте на новой работе собственную систему сборки - Bake.

Читать полностью »

Как привести проект в чувство - 1

Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.

Так звучит один из популярных вопросов на собеседовании для фронтенд-разработчиков. Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед.
Читать полностью »

Проблема «умной» очистки образов контейнеров и её решение в werf - 1

В статье рассмотрена проблематика очистки образов, которые накапливаются в реестрах контейнеров (Docker Registry и его аналогах) в реалиях современных CI/CD-пайплайнов для cloud native-приложений, доставляемых в Kubernetes. Приведены основные критерии актуальности образов и вытекающие из них сложности при автоматизации очистки, сохранения места и удовлетворения потребностям команд. Наконец, на примере конкретного Open Source-проекта мы расскажем, как эти сложности можно преодолеть.

Введение

Количество образов в реестре контейнеров может стремительно расти, занимая больше места в хранилище и, соответственно, значительно увеличивая его стоимость. Для контроля, ограничения либо поддержания приемлемого роста места, занимаемого в registry, принято:

  1. использовать фиксированное количество тегов для образов;
  2. каким-либо образом очищать образы.

Читать полностью »

Этот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.

Пример отчета, получающийся в allure

Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.

Читать полностью »

«Восстание машин» часть 1: continuous delivery для базовых Docker образов - 1

Всем привет! Меня зовут Леонид Талалаев, я работаю в Одноклассниках в команде Платформы. Более 3-х лет назад мы запустили внутреннее облако one-cloud. Сейчас под его управлением находятся тысячи серверов в 4 дата-центрах, сотни сервисов и более десятка тысяч контейнеров.

Наше облако – это технология, проверенная временем и инцидентами — вплоть до пожара в одном из наших дата-центров. По мере роста числа сервисов росла и сложность управления. Задачи, которые раньше выполнялись вручную, начинали отнимать слишком много времени и сил.

В серии статей «Восстание машин» я расскажу, как автоматизация в one-cloud помогает экономить не только время, но и деньги. Сегодня пойдет речь о том, как мы реализовали процесс непрерывной доставки изменений базовых Docker образов.

Читать полностью »

Организация распределенного CI-CD с помощью werf - 1

werf — наша Open Source-утилита для сборки и деплоя приложений. Сегодня мы с радостью сообщаем, что werf научилась работать в распределенном режиме, начиная с версии v1.1.10 (доступна в каналах v1.1 alpha, beta, ea и stable). Для его подключения требуется минимум усилий.

Вот некоторые из примечательных особенностей нового режима:Читать полностью »

image

Все популярные реализации реестров для образов контейнеров поддерживают Docker Registry HTTP API и позволяют использовать одни и те же инструменты для работы с ними. Тем не менее, часть реализаций имеет свои особенности и ограничения, а значит — если вам нужно их поддерживать в своем инструментарии для CI/CD, — с этой спецификой необходимо считаться. Так у нас и случилось в процессе работы над GitOps-утилитой werf, когда мы захотели улучшить в ней то, как обеспечивается жизненный цикл образов.

В статье рассказывается об основных особенностях поддерживаемых имплементаций Docker Registry, а также о соответствующих нововведениях в werf.Читать полностью »

Content-based tagging в сборщике werf: зачем и как это работает? - 1

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. В релизе v1.1 была представлена новая возможность в сборщике образов: тегирование образов по содержимому или content-based tagging. До сих пор типичная схема тегирования в werf предполагала тегирование Docker-образов по Git-тегу, Git-ветке или Git-коммиту. Но у всех этих схем есть недостатки, которые полностью решаются новой стратегией тегирования. Подробности о ней и чем она так хороша — под катом.Читать полностью »

Релиз werf 1.1: улучшения в сборщике сегодня и планы на будущее - 1

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea.

Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js