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

«Наши инструменты сборки веб-приложений от 10 до 100 раз медленнее, чем они могут быть» – считает Эван Уоллес, сооснователь Figma. По его мнению, прямо сейчас, а не в будущем, можно собирать фронтенд в 10–100 раз быстрее. Рассмотрим, как этого добиться, и причём тут webpack.

Поможет нам в этом Евгений Кувшинов, фронтендер и тренер по инженерным практикам с двенадцатилетним опытом в продуктовой разработке. Он расскажет про свой опыт работы с webpack и поможет поставить запятую в заголовке статьи.

В период с 199x по 201x развелось очень много программистов-микроконтроллеров, которые никогда не представляли свою работу без IDE (IAR, KEIL, Code Composer Studio, AtilocTrueStudio).

В этом тексте я написал про недостатки работы в IDE и альтернативный способ сборки и масштабирования кодовой базы. Про MakeFile(ы).

В Bazel есть любопытная фича, позволяющая добавить данные, которые не инвалидируют кэш сборки.

Например, это бывает полезно, чтобы добавить в исполняемый файл информацию о том, когда он был собран и из какой ревизии. Если для времени и номера ревизии использовать stamping, то, когда собранный файл уже есть в кэше, он пересобираться не будет.

Разберемся, как stamping использовать...

При поиске решений для сборки больших проектов на Go с завидной регулярностью попадались отсылки на статьи про Bazel.

К сожалению, понимания того, как должна выглядеть разработка после миграции на Bazel они не давали. Попробуем разобраться...

Это первый пост из цикла, посвященного миграции с go build на Bazel.

К процессу миграции мы подошли на этапе, когда запуск тестов на CI занимал примерно от 15 минут до часа. При этом мы уже успели реализовать некоторое распараллеливание и кэширование результатов тестов. Без этого тесты на одной машине должны были бы идти примерно часов восемь.

После внедрения Bazel запуск тестов на CI в основном укладывается в интервал от 1,5 до 25 минут (50 перцентиль в районе 12 минут), что гораздо комфортнее исходной ситуации.

Оговоримся, что сравнение этих цифр «в лоб» несколько некорректно: с одной стороны, за время пути кодовая база стала еще больше, а с другой – поменялась топология CI. Но в целом представление о полученном эффекте они дают.

Далее опишем, за счет какого механизма достигнуто ускорение.

Привет, Хабр! Меня зовут Андрей, я SDET-разработчик SimbirSoft. В практике CI/CD один из общепринятых стандартов — настройка автоматического запуска автотестов при деплое сервиса на стенды. То есть при запуске сборки мы сразу видим, как пройдут смоук-автотесты, и на основе отчета решаем, передавать сборку дальше QA-команде или дорабатывать. А скорость исправления ошибок критично важна для бизнеса.

Мы разберем автоматический запуск автотестов с использованием Downstream pipelines в GitLab CI на примере проекта с несколькими микросервисами.

Кеширование сборок — это экспериментальная функция, позволяющая сохранять результаты последней успешной сборки и использовать их в качестве основы для последующих сборок. Это значительно ускоряет процесс, поскольку не пересобираются проекты, которые не изменились с момента последней сборки. Давайте посмотрим, как это работает.

Привет! Меня зовут Даша, я Android-разработчик в команде онлайн-кинотеатра PREMIER и я хочу с вами поделиться историей как мы начали приводить в порядок Gitlab CI скрипты :)

В нашем проекте стало много вариантов сборок и чтобы не тратить кучу времени на ожидание и поиск необходимого билда нам нужно было хотя бы получить отбивку об окончании работы джобы. А затем - решить неудобства с копипастой, чтобы поддержка скриптов не вызывала выгорание:) Погнали!

Интегрируем Objective-C код из Apple SDK в C++ проект, без переписывания всего проекта на Objective-C++, с использованием PIMPL идиомы. Также, сборка всего проекта вместе с использованием Makefile и CMake (для генерации .xcodeproject).

За последние пару лет не раз можно было услышать про новые инструменты
сборки статики, такие как SWC, esbuild и Vite. Все они обещают нам next
gen-оптимизацию времени сборки, а SWC ещë и грозится оптимизировать
скорость выполнения тестов на Jest; более того, судя по документации,
сделать это очень просто. Я решил проверить, так ли это на самом деле и
каким будет результат. Если вам интересно, что из этого получилось и
какие были проблемы, то прошу под кат.

Много команд, много продуктов, каждый автоматизирует релизный цикл, у каждого свой набор скриптов. Дублирование, отсутствие обмена практиками и повторное изобретение колеса приводит к тому, что команды тратят много времени на построение своего CI/CD. И все это поддерживает микросервисную архитектуру, где автоматизации нужно уделить особое внимание.

Меня зовут Владимир Цыбров, я релиз-инженер Леруа Мерлен и сегодня расскажу, какие в компании были подходы к построению пайплайнов и улучшению качества их кода. Спойлер: мы использовали подход InnerSource и предоставили командам self-service-инструменты.

Всем привет! Меня зовут Иван Чечиков, я QA lead в МТС Digital, работаю над проектом стримингового сервиса WASD.TV. В этой статье я поделюсь опытом о том, как мы внедряли систему управления тестированием (TMS) Allure TestOps в наш проект и что из этого получилось. А еще отмечу подводные камни, с которыми столкнулись и обозначу пути их обхода. Статья может быть полезна тем, кто задумываются о переходе на данную TMS с других готовых решений, таких так Zephyr, TestRail, Test IT.

Подробности – под катом.

Приветствую! Меня зовут Алексей Денискин, я тимлид мобильной команды СберМаркета. В этой статье я на примере покажу, как организовать CI для мобильных приложений на Android и iOS. Я буду использовать GitLab CI, но описанный подход применим к большинству стандартных стеков.

Зачастую, приложение, у которого происходит существенный рост пользователей оказывается не готово к этому. Требования к быстродействию и доступности растут, а инфраструктура и архитектура приложения не позволяют их обеспечить.

Стоявшая передо мной задача: улучшить инфраструктуру и качество работы приложения, успевшего вырасти из MVP и стенда для одного клиента в популярный SaaS. Отсутствие отказоустойчивости и масштабируемости компонентов сервиса начало ощутимо мешать пользователям. Настала пора адаптировать приложение под кластерный режим.

Приложение работало в контейнерах, а оркестрация осуществлялась с помощью Docker Compose. Компоненты приложения не задумывались готовыми к запуску в кластерном режиме, что, разумеется, нормальная ситуация для раннего этапа многих проектов: бизнес требует быстрой доставки новых функций, и на преждевременную оптимизацию не всегда можно и нужно тратить время. Но в какой-то момент именно стабильность и быстродействие становятся самыми важными функциями. 

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

Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса. В данной части, обсудим как можно легко проверять размер в development ветке.

В публикации опишу подход к использованию контейнеров docker и make который я практиковал последние несколько лет в своих рабочих командах и личных pet-проектах. Подход сформировался в процессе поиска минималистичного и унифицированного способа запуска проектов на php. Чтобы любой разработчик мог в пару простейших команд получить рабочую копию для разработки, располагая только доступом к репозиторию, без бубнов, обновляемых инструкций и тимлида на соседнем стуле.

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

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

MSBuild – популярная сборочная платформа с открытым исходным кодом от Microsoft, которую используют разработчики по всему миру. В далёком 2016 году мы уже проверяли проект при помощи PVS-Studio и нашли несколько подозрительных мест. Давайте посмотрим, что удалось обнаружить в коде MSBuild при повторной проверке.

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

CI система GitHub Actions достаточно свежа по сравнению со своими конкурентами, но продолжает радовать сочетанием легкости использования и постепенным расширением функционала. На мой взгляд, шаблонизация используемых пайплайнов это безумно важная составляющая, и в конце 2021 года GitHub закрыли этот вопрос, представив на наш суд Reusable Workflows. В данной статье я попробую поделиться собственным опытом построения проекта полностью на основе шаблонов workflow и порассуждать о применимости этого подхода.