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

Несколько внеочередная заметка... Со времён Короны я работаю дома на подстольной дорожке. Когда я искал что же купить, я наткнулся на небольшой местный магазинчик FitOffice, где выбор был TR1200 или TR5000. По отзывам обе хороши, но одна требует регулярного смазывания и предполагает использование на несколько часов в день -- а вторая не требует смазывания и подходит для ходьбы хоть весь день. Жена настояла на второй :)

Если вкратце, то за 4 года использования, я находил на ней всего около 10 тысяч км, но она начала шуметь до невозможности -- по замерам телефона более 60 дБ на 5км/ч, да еще с жуткой высокочастотной составляющей, которая делала шум еще хуже. Ну то есть я мог за ней работать (стол экранировал от прямого шума), но шум рядом с ней становился отвратительным.

Официальный суппорт по почте сказал мне "это нормально" -- а FitOffice сказали что это похоже на проблему мотора -- аналогично высказался кто-то на reddit, да и на мой слух звучало как проблема какого-то из подшипников. В качестве простой меры мне предложили поменять щётки мотора, эту инструкцию я нашел (осторожно: видео). Но щетки оказались почти не израсходованными (меньше 1мм съелось), и на звук замена не повлияла. Осталась опция только замены мотора.

Учитывая, что дорожка уже за гарантией, а замена сама выглядела как простое дело -- я решил поменять его сам, хоть и не нашел никакой инструкции. Так что теперь заполняю этот вакуум :)

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

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

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

Настроек для пайплайна Gitlab очень много. В этой статье, не вдаваясь в недра тюнинга, поговорим о том, как выглядит скрипт пайплайна, из каких блоков он состоит и что может содержать.

Привет, Хабр!

Хочется рассказать о нашем опыте внедрения CI/CD в компанию. О том, как в целом работать с ним и как это работает у нас.

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

Приятного прочтения, всем peace!

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

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

Привет! Меня зовут Александр, я работаю в VK в команде браузера Atom. В его основе лежит open source-движок Сhromium. Сегодня хочу поговорить о системе мета-сборки GN. Её используют в крупных проектах Google (Chrome, Fuchsia, а также связанных с ними), и, например, когда разрабатывают браузеры на основе Chromium (то есть почти все браузеры, кроме Mozilla, Safari и совсем какой-то экзотики). Система мета-сборки GN используется для генерации ninja-файлов, описывающих этапы сборки проекта.

Год назад я написал статью об отладке STM32 микроконтроллеров из под VSCode, с компиляцией в GCC и сборкой с помощью CMake. А в декабре мне в руки попали две тестовые единицы отечественных микроконтроллеров К1986ВЕ92FI (MDR1211FI1). Производитель имеет свою библиотеку SPL на C, а также неплохую базу примеров инициализации и применения различной периферии в Keil и IAR; однако я, average C++20+ enjoyer , решил попробовать перенести свой тулчейн на новое железо.

В статье мы расскажем о том, как переводили проект с рекурсивной сборочной подсистемы ЗОСРВ "Нейтрино", представляющей собой набор расширений инструмента GNU Make на сборочную систему CMake: с какими нюансами нам пришлось столкнуться, какие преимущества мы получили в результате перевода и как это повлияло на нашу команду разработчиков.

Периодически я пробую разные инструменты, и если они стабильно покрывают все необходимые сценарии - включаю в свою экосистему для коммерческих проектов. С третьего подхода за последние 3 года esbuild, наконец, приблизился по функционалу к Webpack. В статье привожу проблемы, с которыми я столкнулся при миграции, и пути их решения.

Как мы ежа и ужа собирали. Сказ об автосборке разномастных технологий под одну крышу.

Если серьёзно: у нас было много разнообразной ручной работы на пути от разработчика до релиза приложения для сети магазинов.

Мы научились хранить наши приложения в git и собирать их «одним кликом», перешли от подхода «один репозиторий – одна технология» к «один репозиторий – одно приложение». Реализовали установку всех частей приложения «одной командой»; собрали грабли, разложенные в самых неожиданных местах, и создали несколько инструментов, помогающих на разных этапах сборки и установки приложений.

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

В предыдущей статье рассматривался принцип, как можно прокинуть периферию микроконтроллера (UART, I2C, CAN bus etc) в обычную ПК программу, так как если бы она входила в состав нашего компьютера и висела на обшей шине с памятью. В той публикации рассматривается теория и инструменты, которые позволяют это сделать. В этой части мы рассмотрим, как на практике осуществляется подготовка кода драйверов к инструментизации ADIN LLVM pass и последующей сборке в отдельную динамическую библиотеку, которую вы можете использовать в своих проектах

Бывало ли у вас такое, что вы совершали одни и те же действия из раза в раз и наконец-то решили избавиться от всей этой рутины? Но вы решили отложить это решение на некоторое время, в частности из-за занятости или лени. Но вот вы решаете взять себя в руки и всё изменить! Также было и со мной - и вот в конце концов я решился пойти на оптимизацию развертывания сервисов в Kubernetes при помощи Helm и написать об этом статью!

Я уже успел развернуть несколько приложений в Kubernetes. Но в последнее время взаимодействовать с ресурсами через kubectl становится невыносимо больно. Поэтому я решил осуществить свою давнюю затею - написать свой Helm чарт. Сегодня мы вместе с тобой, Хабрюзер, создадим свой чарт, который можно будет использовать для деплоя собственных приложений!

Сегодня мы с радостью объявляем о релизе GitLab 16.4 с настраиваемыми ролями, списком зависимостей для групп и подгрупп, локальному доступу к кластерам при помощи учётных данных GitLab, рабочими пространствами для приватных проектов и многими другими фичами!

В программировании программы часто строятся иерархично. Один программный компонент вызывает функции из другого программного компонента. Как бы представить эту взаимосвязь в законченной программе?

Эту задачу можно решить прибегнув к языку Graphviz и утилитам cpp, dot, make, chrome.

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

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

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

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

Недавно передо мной встала задача — есть 250 тестов, каждый из которых занимает от 5 до 30 минут, а иногда и часы. Надо запустить их в параллель на одной машине, но не больше 16 одновременно. Ограничение связано с некоторым лимитированным ресурсом, а также количеством ядер CPU. Реальное число одновременно запущенных задач нужно вычислять динамически, то есть пойти простым путем и зарегистрировать имя или лэйбл ресурса заранее с помощью плагина Lockable Resource не получится.

По случаю выхода версии 0.11.0 языка Zig я решил написать ещё одну статью о языке Zig. В этот раз речь пойдет о системе сборки языка. А точнее, как пользоваться кодом написанным на языке C в проекте на языке Zig, с небольшими ответвлениями в стороны для описания некоторых возможностей системы сборки. Тем более, что она претерпела несколько изменений, о чём я так же коротко упомяну. Эксперименты проводились мной на Windows 11. Стоит сразу упомянуть, что указанные в статье команды будут работать и на других операционных системах. Это одна из особенностей языка Zig. Но пример кода линковки системных библиотек для сборки библиотеки raylib будет платформозависимый, так как для разных платформ набор библиотек отличается. Если интересно, то прошу...

Привет! Я Даша, Android-разработчик в команде онлайн кинотеатра PREMIER.

В прошлой статье я рассказывала, как мы настроили сборку проекта с помощью Gitlab CI. Дальше нужно отправить приложение в маркеты для внутреннего тестирования, а затем конечным пользователям.

Сегодня разберемся, как автоматически опубликовать приложение в Google Play, Huawei App Gallery и Firebase на примере нашего приложения онлайн-кинотеатра PREMIER. Также расскажу, как мы отправляем сборку в Nexus.

По мере того, как ваше приложение растёт и развивается, растут и затраты времени на его тестирование и сборку, достигая нескольких минут при пересборке в dev-режиме и, возможно, десятков минут при «холодной» production-сборке. Что, конечно, совершенно неприемлемо. И если поначалу увеличение временных затрат может казаться незначительным, то впоследствии это непременно ведёт к ухудшению процесса разработки и может негативно повлиять на скорость выкатки важных релизов или хотфиксов. Таким образом, в какой-то момент вопрос оптимизации и ускорения сборки приложения может стать критически важным для разработчика.