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

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

Привет, Хабр! Сегодня я хотел бы рассказать вам о моём переезде на Linux под управлением оконного менеджера I3-wm. Попробую немного раскрыть тему настройки оконного менеджера и поделюсь своим опытом. Надеюсь кому-то будет полезно получить такого рода информацию.

P.s если вы не новичок, то вред ли узнаете много нового, но благодарю за внимание!

И так! Данная программа была разработана в целях бэкапа конфигурации системы, которую я использую каждый день - Manjaro I3. Я приготовил 3 конфигурации оконного менеджера I3-wm для систем: Manjaro, Solus и Fedora, так как они наиболее популярны на мой взгляд. Я использовал каждый из представленных дистрибутивов и временами меняю совой основной дистрибутив на один из них.

Я пользуюсь Linux с 18 февраля 2019 года, но летом 2020 я начал использовать Linux как основную систему (на тот момент ещё Ubuntu 20.04 LTS).

Эта статья открывает серию публикаций по обучению фреймворку $mol. Сегодня мы разберемся в модульной системе MAM. Речь пойдет об организации кода, отделении его от инфраструктуры, сборке, версионировании, нейминге, минимизации размера бандла, автоматическом выкачивании зависимостей, фрактальных моно-поли-репозиториях, разделении кода на платформы, альтернативе импортам/экспортам, автоматическом разруливании циклических зависимостей.

Всем привет! Сегодня хочу поделиться нашими мыслями относительно того, как защититься от санкций палок в колёсах в современных условиях. Собственно, что мы имеем ввиду? Речь идёт о том, что в крупных проектах часто есть единые точки отказа в процессах CI/CD, это может быть как простой репозиторий кодом, так и различные конвеерные системы сборки кода и доставки его в рабочие окружения. Если мы говорим про системный софт, то его можно просто перестать обновлять, запретить ему ходить "наружу", но в данной статье мы поговорим про внешние репозитории с кодом.

Мы рады сообщить о выходе релиза GitLab 14.8 с новыми типами ключей SSH, новым механизмом правил для подтверждения безопасности, автодополнением в редакторе конвейеров (в русской локализации GitLab «сборочные линии»), событиями аудита для действий администратора от имени пользователя и многим другим!

Начиная с первых версий .NET Core для сборки приложений, компания Microsoft предоставляет простой и удобный интерфейс командной строки (.NET CLI). Его возможности покрывают большинство потребностей по сборке, упаковке и тестированию приложений. Несмотря на это, по мере роста приложения, увеличения количества его составных частей/сборок/пакетов, усложнения процессов тестирования и развертывания, рядом с проектом часто появляются такие файлы сценариев как build.ps1, build.sh, build.cmd или даже полноценные инфраструктуры автоматизации построения приложений. В статье TeamCity C# script runner была предложена еще одна альтернатива - сценарии C#, которые особенно полезны, когда необходимо эффективно автоматизировать какой либо аспект сборки силами .NET разработчиков или  DevOps, знакомыми с синтаксисом C#. Тогда же была упомянута идея расширить встроенный API сценариев для более глубокой интеграции с TeamCity и для поддержки наиболее частых вариантов использования. Предполагая, что API сценариев чаще всего будет задействован при сборке приложений, мы в первую очередь решили расширить именно его. В этой статье будут приведены примеры использования этого API.

Мы рады представить релиз GitLab 14.7 с трансляцией событий аудита, соответствием GitLab Runner стандарту FIPS 140-2, групповыми токенами доступа и многим другим!

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

Здесь мы посмотрим, как получить доступ к кластеру Kubernetes с помощью GitLab CI/CD и зачем это нужно, если вы взяли курс на GitOps.

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

Мы рады рассказать вам о выходе релиза GitLab 14.6, последнего релиза 2021-го года. В этом релизе появились: упрощённая конфигурация Geo, которая помогает распределённым командам ускорить выполнение git clone или git pull за счёт автоматического использования ближайшего к ним сервера; список действий агента GitLab, который регистрирует в реальном времени такие события, как состояние соединения и токена; различные улучшения для SAST, включая правила выполнения SAST-сканирований и поддержку .NET 6.

Всем привет, сегодня поговорим о внедрении Dependency Injection (далее - DI) в Nuke и рассмотрим моё видение. Кто не знаком с Nuke вы можете ознакомиться или на официальном сайте или посмотреть вот эту презентацию, если коротко - то это очень удобная система автоматизации сборок, которая по факту консольное приложение на C#.

Разберемся с кросс-компиляцией при помощи Clang на пальцах, попутно посмотрим на CMake, не оставим без внимания Conan, соберем самый настоящий .deb пакет и конечно же - максимально контейнеризируем и автоматизируем весь процесс. Посмотрим зачем нам тут Clang, и почему иногда не обойтись без него.

Многие ли из вас используют всевозможные вспомогательные shell-скрипты в своих проектах? Это также могут быть Python или Perl скрипты. Обычно такие скрипты используются на этапе сборки или для других задач автоматизации проекта.

Примерами таких задач могут служить:

• вспомогательные скрипты для Git,
• запуск тестов/линтеров,
• запуск необходимых докер контейнеров,
• запуск БД-миграций,
• собственно, сборка проекта,
• генерация документации,
• автоматизация публикации релизов,
• развертывание и т.д.

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

Make — пожалуй, наиболее известный из подобных инструментов.

Похожий функционал известен разработчикам nodejs и любим ими в виде скриптов в package.json (npm run-scripts). Ветераны Java вспомнят Ant.

Но nodejs/Ant требуют установки, make хоть и способен выполнять функции task runner довольно неудобен в этой роли, будучи на самом деле очень олдскульным build tool со многими вытекающими "особенностями".

А shell-скрипты требуют некоторой системы и неизбежной рутины в написании (обработка аргументов, help-сообщения и т.д.).

Хотя, например, Taskfile представляет прекрасный шаблон для подобных скриптов.

Так и родился makesure.

Всем привет! Вот уже почти 3 года я занимаюсь разработкой и поддержкой программ для такой платформы как IBM i (краткое описание что это такое есть, например, тут и здесь). Как вы понимаете, данный вид деятельности неразрывно связан с тем, что тексты исходного кода надо преобразовывать в исполняемые файлы или, как будет правильнее для IBM i, в объекты системы. И вот тут начинается самое интересное...

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

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

Заголовок: Вышел GitLab 14.5 с SAST-сканированием инфраструктуры как кода и групповыми настройками подтверждений мерж-реквестов
Автор оригинала: Jackie Porter, GitLab
Ссылка на оригинал

Мы рады объявить о выходе нового релиза GitLab 14.5, включающего сканирование безопасности инфраструктуры как кода, групповые настройки подтверждения мерж-реквестов (в русской локализации GitLab «запросы на слияние»), GitLab Kubernetes Agent для бесплатных планов, темы проектов и многое другое!

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

Первое время мы строили решения на собственной «железной» инфраструктуре с LXC-контейнерами. Но мы довольно быстро обнаружили, что она перестала справляться с нагрузкой и только тормозила развитие. Чтобы исправить ситуацию, мы перешли в облако SberCloud.Advanced. Сегодня покажу, как выглядит наша инфраструктура, и как мы ей управляем. Также расскажу об инструменте для сontinuous deployment (CD) в Kubernetes — Helmwave.

Всех заинтересовавшихся приглашаю под кат.

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

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

Marlin – корпоративный архитектурный репозиторий и система автоматизации процессов жизненного цикла программного обеспечения, которая может сэкономить сотни часов менеджерам проектов и команде разработчиков. Под катом подробное описание процесса сборки, развертывания и тестирования приложения, а также создания зависимостей между другими корпоративными системами.