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

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

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

Хочу показать, как эти проекты связаны и где могут пригодиться.

Разберём, как настроить нагрузочное тестирование с нуля и встроить его в CI на примере xk6-sip — расширения нагрузочного инструмента k6 для VoIP/SIP-телефонии. На каждый push в GitHub Actions идут шесть функциональных звонковых сценариев и двухминутный нагрузочный прогон с порогами качества, а в артефактах сборки остаётся отчёт: JUnit, итоги k6 и скриншот дашборда Grafana за окно теста.

Это четвёртая статья серии. В первой мы разобрали, как описывать звонки как код и как устроен движок xk6-sip, во второй — настроили мониторинг нагрузки на Prometheus и Grafana. Здесь объединяем их в CI/CD-пайплайн на GitHub Actions, который проверяет АТС на каждый коммит.

Для VoIP/SIP-телефонии автоматизация тестирования в CI исторически давалась тяжело. Классический SIPp описывает сценарии в XML и не отдаёт ни метрики в Prometheus, ни JUnit-отчёт, поэтому в пайплайне его приходится обвязывать скриптами. В xk6-sip сценарий — обычный скрипт k6, а пороги, JUnit и экспорт метрик — стандартные возможности k6.

Нагрузочное тестирование часто живёт отдельно от разработки: раз в релиз инженер вручную запускает прогон, смотрит на графики и пишет отчёт. Деградация при этом обнаруживается через недели после коммита, который её принёс. Автоматизация нагрузочного тестирования в CI сокращает этот срок до минут: пороги производительности становятся quality gates, как юнит-тесты.

Всё ниже — из реального пайплайна репозитория xk6-sip: функциональные тесты занимают 40 секунд, нагрузка с мониторингом — 3,5 минуты, 401 звонок и 2 005 проверок за прогон.

В прошлом году я купила 3D-принтер, а примерно в июле решила напечатать органайзер для мелочей. Подходящую готовую модель найти не удалось, и я открыла Blender, чтобы сделать свою. На этом всё и остановилось: я растерялась среди панелей, кнопок и настроек и отложила моделирование.

Недавно я увидела в сообществе примеры работы с Blender через Codex и GPT-6 Astra и решила попробовать снова. Для первого упражнения выбрала настольную лампу: основание, стойка, кронштейн и плафон. После моделирования я настроила материалы и свет, затем сделала пятисекундный облёт камеры.

Переезд с include на GitLab CI Components: у модуля появляется объявленный spec: inputs с типами и дефолтами, а опечатка в имени input роняет пайплайн до старта…

Абсолютные импорты без расширений в ESM-монорепозитории.

Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”.

Разрешаем конфликты настроек без костылей.

Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”.

Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

Сегодня выдался какой-то безумный день. Сначала вышла финальная версия DeepSeek V4 Pro, а меньше чем через два часа появился Grok 4.6. Обе модели близки по масштабу: у одной около 1,6T параметров, у второй около 1,5T. И обе за одну ночь подобрались к уровню пользовательского опыта Claude Fable 5.

Stapler: текстовый «рецепт» сборки и управление пакетами в ОС «Альт»

Во время установки «Альт Рабочей станции» 11.2 можно загрузить инструмент, позволяющий использовать приложения из различных источников, включая сторонние репозитории. Его также можно установить в других ОС «Альт» на платформе p11. Речь идет о Stapler.

NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции.

Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.

Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11.

Открытый чекер архитектуры C++ для CI: циклы, копипаст, распухшие заголовки — в каждом PR. Плюс замер на 484 500 коммитов в поисках архитектурного дрейфа

У вас не 5 микросервисов — у вас десятки. Бэкенд, который рос три года: монолит, расколотый на куски, GPS-фид от автопарка, мобильное приложение водителя, веб-кабинет диспетчера, интеграции с SAP / 1С / регуляторами / маркетплейсами, отдельный SMTP-воркер, отдельный PDF-генератор, отдельный шедулер ночных пересчётов. Между ними — Kafka (несколько кластеров, по топику на домен), RabbitMQ (RPC + pub/sub + DLQ), Redis (кэш, last-known-state, pub/sub-каналы), пара HTTP-эндпоинтов наружу, SFTP с поставщиком, SQL-polling outbox-таблицы старого монолита, MQTT с трекеров, IBM MQ для одного древнего банковского контура, SignalR-хабы для real-time-дашбордов. На каждом стыке — свой ретрай, свой DLQ (или нет DLQ), своя сериализация, свои метрики (или нет метрик), своя бойлерплейт-обвязка из консьюмеров и try/catch.

Каждый из этих стыков живёт своей жизнью в Program.cs соответствующего сервиса. Каждый — это hand-rolled цикл:

Если у вас кроссплатформенный проект на C или C++, то, как правило, вы не завязываетесь на одну систему сборки, а используете генератор сценариев для сборочных систем. Самый распространённый из них, CMake, недавно получил официальную интеграцию со статическим анализатором PVS-Studio для этих языков.

В этом тексте я написал про то, как составить крохотный, но очень полезный загрузчик.

В программировании на STM32 бывает нужно сделать так, чтобы загрузчик оказался не в начале Flash памяти, а в конце.

Поэтому надо написать отдельную крохотную прошивку первичного загрузчика, которая при старте передает управление на другой адрес в физической памяти.

Написать на Си проект прошивки для микроконтроллера STM32F407VE. В качестве кросс компилятора выбрать GCC. В качестве системы сборки использовать CMake. В качестве HAL использовать фирменный HAL от STM и CMSIS от ARM. Собирать в Windows 10.

В данном тексте я покажу как можно организовать CMake скрипты сборки, чтобы собрать прошивку для микроконтроллера STM32.

В статье расскажу, как в Bercut реализовали интеграцию внутренней системы управления конфигурациями с популярной экосистемой Maven, что позволило обеспечить более удобное и стандартизированное распространение артефактов. Поделюсь проблемами, с которыми мы столкнулись при совмещении разных моделей идентификации артефактов и обеспечении корректности зависимостей, и расскажу о выбранном техническом решении на базе Jenkins, RabbitMQ и специального Consumer Service.

Кейс может быть полезен инженерам DevOps, а также разработчикам и архитекторам, которые решают похожие задачи интеграции нестандартных систем сборки и управления конфигурациями с системами на базе Maven.

В этом тексте я покажу как собрать прошивку при помощи компилятора IAR и GNU Make файлов.

Собрать прошивку компилятором IAR с помощью GNU Make — это не просто возможно, это стандартный подход для автоматизации сборки, например, на CI/CD серверах, где использование IDE неудобно. IAR поставляется с набором консольных утилит, которые делают этот процесс вполне прямолинейным.

Flutter & GitLab CI/CD. Доставка мобильного приложения в Significa, TestFlight и Google Play

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. После успешной настройки сборки и подписания Flutter-приложений во второй части, остался последний, но не менее важный этап — дистрибуция приложения.

В современных условиях автоматизация деплоя на такие платформы, как Google Play, TestFlight и Significa, становится необходимостью. В этой статье мы разберем, как с помощью GitLab CI/CD настроить автоматическую отправку ваших приложений в магазины, чтобы вы могли сосредоточиться на разработке, а не на рутинных задачах.

Сложно поддерживать CI/CD, когда граф пайплайна в GitLab превращается в бесконечную «простыню», параллельные запуски terraform apply приводят к блокировкам, а для игнорирования некритичных ошибок приходится писать || true. 

Может показаться, что для решения этих проблем нужны «костыли» или переход на enterprise-лицензию. На деле же с ними помогут встроенные возможности GitLab CE. В статье разбираем неочевидные ключевые слова .gitlab-ci.yml, которые сэкономят вам время и нервы.

Статья про то как контролировать загрузку статики у себя в продакшн сборке и предотвратить сайд-эффекты.

Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.

В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.