Системы сборки *

Привет! Я Никита, сейчас разрабатываю мобильный банк под Android, много работаю с Gradle, и мне это нравится.

Сборка приложений для меня уже рутина — на пет-проектах и на работе. Но однажды я задумался, а можно ли ускорить сборку? Если да, то как и насколько: на доли секунд или это будет ощутимо? Как именно ускорять, ведь есть куча версий Gradle, плагины, бинарный интерфейс и всё такое?

А потом я просто взял и попробовал все известные мне варианты, замерил скорость сборок и сделал выводы. Заглядывайте под кат, расскажу, что именно сработало и надо ли вам подкручивать параметры своей сборки или срочно обновлять Gradle.

Завершаем приготовление Gitea со вкусом werf CI/CD. В финальной части серии создадим репозиторий с кодом приложения, подготовим простенький Helm-чарт и Gitea Actions-пайплайн, в котором опишем автоматический процесс сборки и деплоя приложения в кластер Deckhouse Kubernetes Platform.

Клиенты «Фланта» иногда ищут альтернативу GitLab или GitHub с удобным CI/CD и on-premise-размещением. Один из возможных вариантов — Open Source-решение Gitea. 

В сравнении с GitLab сервис Gitea прост и потребляет в два раза меньше ресурсов. При этом его функциональности достаточно, чтобы построить экосистему управления кодом и его развёртывания в Kubernetes. Эта статья — детальная инструкция по установке и настройке сервера Gitea, а также организации с его помощью авторизации через Dex в кластере Deckhouse Kubernetes Platform. 

В следующих частях серии настроим Gitea act_runner и подготовим Gitea Actions-пайплайн, в котором развернём приложение в кластере с помощью werf.

Привет, меня зовут Грант, я фронтенд-разработчик в KTS. В этой статье я хочу поделиться опытом заведения проектов от нашей команды.

Привет, Хабр! На связи Андрей Аврамчук (@Mimizavr). Недавно я побывал на онлайн-презентации GitVerse — платформы для совместной разработки и хостинга кода. Планируется, что она станет инструментом нового поколения, избавляющим разработчика от многих болей. Под катом вы узнаете:

— Чем GitVerse может помочь открытому ПО.

— Почему перенос своих проектов на платформу — это легко и приятно.

— Куда спрятаться от ИИ (спойлер: никуда).

— Умеет ли GitVerse в CI/CD.

— И наконец, какие есть причины смотреть в будущее с оптимизмом.

В этой статье мы рассмотрим, как настроить пайплайн CI/CD в GitHub: подготовим репозиторий, зальём туда приложение, создадим файлы конфигурации GitHub Actions, в которых опишем, как собирать наше приложение и деплоить его в кластер Kubernetes, развёрнутый под управлением Deckhouse Kubernetes Platform. Деплоить будем с помощью Open Source CLI-утилиты werf. Она помогает организовать полный цикл доставки приложений в Kubernetes и рассматривает Git как единый источник истины для состояния развёрнутого приложения. Статья рассчитана на тех, кто только начинает свой путь в мире облаков и кластеризации.

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер работает под управлением Deckhouse Kubernetes Platform, а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

Довелось мне обучать одного знакомого, желающего войти в ИТ (привет, Саша!). Человек он упорный, прошел разные курсы, стажировки, упорно продолжает идти вперед и уже вполне тянет на уровень джуна и решает прикладные задачи. Но иногда внезапно задает такие вопросы, из которых я понимаю, что у него огромные дыры в базовых знаниях и представлениях. На курсах этому, видимо, не учат.

Один из последних вопросов был про устройство сборки, непонимание того как исходный код собирается в исполняемый и запускается. Начинающим обычно говорят в духе «вот создаешь Gradle‑проект, в IDE жмешь кнопочку запуска и все работает». Но как только возникает необходимость что‑то в этом простом процессе усложнить, или понять — начинаются проблемы.

Gradle/Maven при этом представляются таким черным ящиком, в котором есть кнопка сборки и запуска, а внутри — магия, превращающая исходный код в запущенную программу.

В этой статье я пробегусь по основам того, как в Java работает компиляция, а также покажу, как по шагам прийти от компиляции отдельных файлов вручную к идее необходимости системы сборки, и как написать свою простенькую систему. Ведь лучший способ понять, как что‑то устроено внутри — сделать это самому.

Всем привет, меня зовут Фёдор — я руководитель фронтенд-разработки на проекте Smartbot Pro в компании KTS. 

Наш проект — конструктор ботов для социальных сетей, в котором алгоритм бота представлен в виде визуального графа. Конструктор включает большое количество интеграций. Недавно на проекте остро встал вопрос оптимизации наших ci/cd пайплайнов, потому что релиз мог занимать от 4 до 18 минут.

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

При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, нужно сначала запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию или миграции БД, а уже затем запустить само приложение. 

Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf.

Данное руководство позволит читателю составить полную картину того, как организовать сборку C++ библиотек с использованием современных возможностей CMake. Предполагается, что читатель имеет представление о базовых понятиях из мира CMake и динамических/статических C++ библиотек, так как в руководстве они могут не объясняться.

Использование того или иного продукта в проекте - это всегда попытка найти лучшее решение, балансируя между ограниченным бюджетом, возможностями роста практически по любому сценарию и высотой "порога входа". Существует много продуктов, которые связаны с контейнерами, что выбрать подходящий инструмент становится всё сложнее и сложенее, а community с "промытыми мозгами" и мышлением "ёжиков жрущих кактус" только добавляет сложности (хотя в противовес оным есть хейтеры, которые наоборот обгадят решение, просто потому что в своё время оно им не подошло).

В целом, чтобы выбрать нужное решение чаще всего приходится поднять лабу, которая покроет 90% задач, чтобы понять насколько решение подходящее, а это значит пройти какую-то боль, потратить время и деньги. Но ещё помогают статьи, в которых рассматриваются частные случаи внедрения и подбор инструментов, чтобы научиться на чужих ошибках через объективный взгляд со стороны. Надеюсь, эта статья о том, почему и как мы пришли к решению с werf, поможет кому-то подобрать инструмент для своих нужд.

В этой статье рассмотрен новый экспериментальный режим работы werf — Open Source-утилиты для сборки приложений и их деплоя в Kubernetes, — в котором не требуется наличие Docker-сервера. Мы покажем, как убедиться, что это режим будет работать на вашей машине, соберем первый образ и научимся использовать Kubernetes executor для автоматизации сборки в GitLab CI/CD.

Довольно частая ситуация, когда с ростом проекта растёт и сложность его сборки. Широкий зоопарк технологий, сторонние компоненты, библиотеки, линтеры, серверный рендеринг и нюансы, связанные с конкретным проектом, — всё это в итоге приводит к тому, что конфигурация сборки достигает более тысячи строк.

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

Но если говорить о конфигурации сборки, то такая декомпозиция скорее редкость, и в больших проектах часто можно встретить огромные webpack.config.js, модификация которых может доставить немало проблем и привести к ошибкам.

Если вам хочется сделать работу со сборкой проще и надёжнее при модификациях, то добро пожаловать под кат.

В этой статье мы рассмотрим, как с помощью Open Source-утилиты werf собрать Docker-образ простого приложения и развернуть его в кластере Kubernetes, а также с легкостью накатывать изменения в его коде и инфраструктуре.

Мы поговорим об общих принципах работы с werf при использовании ее разработчиками, поэтому в качестве примера приложения используем небольшой эхо-сервер на основе shell-скрипта, который будет возвращать в ответ на запрос по адресу /ping строку Hello, werfer!. В следующих материалах будет рассмотрена работа и с «настоящими» приложениями, основанными на распространенных фреймворках на разных языках, но для начала сфокусируемся на общем подходе к разработке с использованием утилиты werf.

werf — это CLI-утилита с открытым кодом для сборки приложений и их деплоя в Kubernetes. С версией v1.2 она получила множество изменений и улучшений, которые мы так тщательно тестировали и дорабатывали, что релиз долгое время — с января 2021-го — находился в статусе Early-Access. Наконец, мы рады объявить о его переводе в категорию Stable!

Эта статья представляет актуальную версию werf, рассказывая о её предназначении и основных принципах работы.

Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.

Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.

Продолжаем серию публикаций «werf vs...», которая вдохновлена часто задаваемыми вопросами. В первой статье мы объяснили, чем werf отличается от Helm. Теперь черед сравнения с еще более базовой утилитой — Docker.

Нас нередко спрашивают: зачем собирать образы с werf, если уже есть Docker с Dockerfile? Обычно мы отвечаем, что werf — не только про сборку. Утилита участвует в полном цикле CI/CD для доставки приложения в Kubernetes, а Docker при этом тоже используется, но как вспомогательный инструмент. Понятно, что такого объяснения недостаточно, нужны подробности.

Этот материал главным образом для тех, кто мало или совсем не знаком с werf, но знает Docker и хотя бы немного работал с ним. Для начала, как и в случае с Helm, попробуем разобраться, есть ли смысл в противопоставлении двух решений.

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

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