Преимущества использования системы контроля версий 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. У нас, как и у большинства компаний, был классический процесс борьбы с секретами – различные инструменты сканировали кодовую базу, и при обнаружении паролей, токенов и т.д. нам приходилось их ротировать. Главная проблема такого подхода в том, что проверить, действительно ли секрет был инвалидирован, не всегда возможно. По этой причине мы решили, что оптимально будет вычищать кодовую базу от любых секретов.
Разработка программного обеспечения становится все более коллективным процессом. В этом контексте все бóльшую значимость обретают открытые проекты, что в совокупности задает тренд на сотрудничество и совместное использование знаний.
Open Source — это не просто способ создания программного обеспечения, а целая культура инноваций, сотрудничества и обмена знаниями. Каждый, кто хочет внести свой вклад в эту динамичную среду, может сделать это вне зависимости от своего опыта или уровня технических навыков.
Как мобильный разработчик TAGES, я не раз сталкивался с миром Open Source, активно поддерживая и участвуя в различных проектах. Открытые инициативы становятся все более важными в современном процессе разработки программного обеспечения, создавая культуру инноваций, сотрудничества и обмена знаниями.
В этой статье мы рассмотрим, как можно стать частью сообщества Open Source, какие шаги необходимо для вступления в него и как ваш вклад может оказать значительное влияние на развитие проектов.
Привет, Хаброжители!
Это не кликбейт. Мы и правда сделали это! В Microsoft мы работаем с очень большим монорепозиторием, который между собой называем 1JS. Недавно мы достигли 1000 активных пользователей в месяц, около 2500 пакетов и ~20 млн строк кода! Последнее клонирование репозитория вернуло невероятные 178 ГБ.
По множестве причин, это попросту слишком большой размер, некоторые ребята из европы попросту не могут успешно клонировать репозиторий из-за его размера.
Вопрос в том, как это вообще произошло?!
