Представьте ситуацию: вы нашли критический баг в проекте, исправили его в feature-ветке, но до полного слияния ещё далеко. Или вам срочно нужно перенести одно конкретное изменение из текущей ветки в другую. В таких случаях git cherry-pick становится вашим секретным оружием.
Когда возникла необходимость в VPN я решил арендовать под это дело отдельный VPS сервер. Мощности были взяты с небольшим запасом для разных экспериментов и личных мини проектов. Обычно для небольших веб приложений я использовал github pages, но у него есть очевидные минусы: некоторые вещи не хочется светить в паблике, иногда нужен полноценный сервер, а не простая статичная html страница. Для сервера были попытки использовать яндекс облако (есть бесплатные лимиты), но разбираться с инфраструктурой лямбд, апи гэтвэев, s3 хранилищ и прочим оказалось довольно накладно, особенно когда что то надо поправить раз в месяц, а то и раз в год.
Привет, Хабр! Меня зовут Антон, я DevOps-инженер в YADRO, работаю с платформой машинного обучения. Недавно столкнулся с интересным случаем, над которым мне пришлось поломать голову. Одной из задач нашей команды стало развертывание helm-чарта для Airflow с использованием ArgoCD. Это потребовалось для реализации DAG-пайплайнов, необходимых для обработки данных и автоматизации процессов в проектах машинного обучения.
В статье расскажу о сложностях при расшифровке секретов с использованием плагина ArgoCD Vault, о паттерне App of Apps для обхода этих сложностей и небольшом погружении в детали установки плагина в кластер, из-за которых возможно неочевидное поведение ArgoCD Applications.
Преимущества использования системы контроля версий Git трудно переоценить. Данная система позволяет нескольким разработчикам одновременно работать над одним проектом, разделять проект на отдельные ветви и затем снова объединять код в одну ветку.
В рамках данной статьи мы будем полагать, что читатель уже знаком с основными принципами работы данного решения и, в частности, с механизмами ветвления. В этой статье мы поговорим о такой полезной функции, как стешинг (Git Stash).
Развитие методологий CI и CD не стоит на месте. Тем не менее, проверенные практики, вероятно, останутся актуальными и в 2025 году. В этой статье покажем некоторые из таких в действии.
Всем привет! Эта статья продолжение первой, опубликованной раннее Домашний NAS сервер, где была разработана электроника и проведено первоначальное тестирование.
Но, без корпуса использовать данный NAS сервер крайне не удобно и есть риск повредить и сломать его, а также нет должного охлаждения, что тоже негативно сказывается на работе сервера.
В данной статье будут описаны разработка и сборка корпуса, надеюсь будет интересно!
Сегодня мы с радостью объявляем о новом релизе GitLab 17.7 с новой пользовательской ролью Planner, правилами автоматического разрешения уязвимостей, списками разрешённых интеграций инстанса, пользовательским интерфейсом для ротации токенов доступа и многими другими фичами!
В первой части материала мы разобрали случай сборки простого rpm-пакета в ALT Linux. За пример брали набор файлов изображений и собирали стандартной утилитой rpmbuild.
В этом материале поговорим про сборку python-проекта специальным инструментом — GEAR. Этот инструмент разработала команда сообщества Альт для автоматизации процесса сборки.
Общими словами, GEAR — это удобная обвязка вокруг Git и rpmbuild. Достаточно в дополнение к spec-инструкции написать GEAR-правила формирования архива, полученного из git-репозитория.
Материал статьи может быть полезен при изучении темы сборки rpm-пакета инструментом gear-rpm в ОС «Альт».
Использование Git в командной строке (CLI) может повысить вашу скорость разработки и эффективность. В этой статье рассмотрим восемь полезных команд для работы с GitHub через терминал.
Эта шпаргалка поможет вам быстро и просто составлять сообщения для коммитов, которые соответствуют стандарту Conventional Commits. Она не для обучения или дискуссий о том, нужны ли такие схемы, а служит удобным инструментом🪄, чтобы подсмотреть и сразу написать коммит.
Если интересно, листайте ниже и пользуйтесь!👀
Автоматическая сборка snap-пакетов с помощью GitLab CI/CD и Docker
Статья посвящена автоматизации сборки snap-пакетов с использованием GitLab CI/CD и Docker. Рассматриваются шаги настройки пайплайнов для создания и публикации пакетов, а также примеры конфигурации файлов .gitlab-ci.yml и Dockerfile.
Наступает конец года. Впереди последний релиз, код-фриз, корпоратив и подведение итогов. Я накидал пару командных HTML игр (например, квиз), основанных на логах вашего репозитория (для git). Наливаем чай или пиво. Собираем команду. Играем, смотрим ачивки. Исходники тут
Сегодня мы рады объявить о релизе GitLab 17.6 с бета-версией Duo Chat с самостоятельным управлением, проверками соответствия для сканеров безопасности SAST и DAST, группированием отчётов об уязвимостях, общедоступным реестром моделей и многим другим!
Недавно со мной произошла довольно забавная ситуация : коллега попросил помощи со своим пэт-проектом. Перейдя по ссылке, меня встретила светлая тема (ну серьёзно, чьей задумкой было сделать её дефолтной), и интерфейс, который очень пытался быть похожим на GitHub, но у него не совсем получалось.
Привет, Хабр! Я – Мария Скрипачева, тестировщик в АйТи-Балансе. Сегодня почти все компании применяют тестирование, и мы не исключение: наши проекты проходят несколько стадий проверок до развёртывания. На нынешнем месте работы я иногда встречаю вопрос, с которым не раз сталкивалась на предыдущих: «а нужен ли GitHub тестировщику?». Эта дискуссия не нова. Я решила внести свою лепту в обсуждение, опираясь на мой опыт и опыт моих коллег, и заодно рассказать о фундаментальных вещах. Поехали🚀
Привет, Хабр! Меня зовут Ольга Лукьянова, я работаю в Yandex Infrastructure, в команде, которая делает системы, сервисы и инструменты для разработчиков. Недавно Яндекс анонсировал новый продукт SourceCraft, который уже собирает вокруг себя сообщество. Последний год я руковожу группой навигации по коду этого проекта.
Мои коллеги на конференциях уже рассказывали про планы развития SourceCraft — платформы от Яндекса для создания исходного кода, управления версиями, тестирования, сборки, развёртывания и сопровождения программных продуктов. А также показывали первый доступный компонент — интеллектуальный помощник для работы с кодом Yandex Code Assistant.
Я открою чуть больше деталей про возможности навигации в нашей платформе, которые появятся в публичном доступе в следующем году и помогут разработчикам не переключаться в IDE, а решать наиболее типовые задачи в одном интерфейсе. В статье — рассказ о том, как мы искали способы добавить функциональность навигации по коду при ревью пул-реквестов и каких результатов уже достигли.
Привет, Хабр! На связи команда разработки App.Farm — продукта, созданного в РСХБ‑Интех. Хотели бы представить вам цикл статей о нем.
App.Farm — продукт по типу PaaS, необходимый для стандартизации процесса разработки бизнес‑приложений: от хранения исходного кода до запуска сервисов. Основные подсистемы платформы включают хранилище исходного кода и CI, хранилище артефактов, среду исполнения приложений, SSO, интеграционную подсистему, observability и т. д..
Подробнее ознакомиться с компонентами можно в обзорной статье, ранее опубликованной на Хабре: Как мы создавали PaaS‑платформу App.Farm. Сейчас мы бы хотели углубиться в детали реализации и поделиться с вами проблемами, которые мы решали, и как пришли к текущей архитектуре. Первый цикл статей мы решили посвятить одной из подсистем нашей платформы — App.Farm CI.
Не кажется ли вам, что декларативная конфигурация и программирование инфраструктуры не так уж хороши, как их расхваливают?
Я достаточно долго занимался декларативной конфигурацией в Kubernetes: размышлял о ней, работал с kubectl apply, KRM, kustomize, Google Cloud Config Sync, kpt, porch, ... В то же время параллельно развивалась декларативная автоматизация — эта работа велась в Google, где на протяжении многих лет широко использовалась декларативная конфигурация. При этом вне Google появился Terraform, и на этом лоскутном одеяле также возникло множество других инструментов.
Что же такое декларативная конфигурация, в каких случаях она хороша, и как к ней подступиться?
Как и многие, я храню свой код на GitHub. Пару лет назад я сделал простой пайплайн для сборки, анализа и тестирования моих веб‑приложений и сервисов. Он выполнял свою задачу, и так как это был мой первый опыт по настройке пайплайна CI/CD на GitHub, он сводился к одному шагу.
build (and deploy)
Со временем я стал замечать, что я стараюсь избегать вносить изменения в код. Будучи счастливым обладателем ADHD, я часто замечаю за собой сложность в решении задач с большим количеством препятствий и одним из них стало то, что выполнение пайплайна занимало больше 5 минут. Я коммитил изменения и шел делать кофе, пока пайплайн тестировал и деплоил код. И не всегда возвращался, отвлекаясь на другие вещи.
Я решил для себя, что максимальное количество времени, которое я готов ждать - 1 минута.
Привет Хабр! Меня зовут Александр Карпов, я работаю в команде защиты приложений ИБ VK. Сегодня я хочу рассказать про наш процесс поиска секретов в каждом коммите в GitLab. У нас, как и у большинства компаний, был классический процесс борьбы с секретами – различные инструменты сканировали кодовую базу, и при обнаружении паролей, токенов и т.д. нам приходилось их ротировать. Главная проблема такого подхода в том, что проверить, действительно ли секрет был инвалидирован, не всегда возможно. По этой причине мы решили, что оптимально будет вычищать кодовую базу от любых секретов.
