Системы управления версиями *

Недавно перешел с Nixpkgs на Nix Flakes. После третьего флейка начал задумываться над их публикациями и обнаружил, что репозитория для флейков по сути нет. Поиск проектов на гитхабе не различает nix репозитории по типам. Есть NUR (Nix User Repository), но он появился до флейков и просто так добавить в него чистый флейк репозиторий без дополнительных приседаний нельзя. Плюс процесс публикации требует прохождения ревью, что весьма неинклюзивно и мешает развитию экосистемы.

Flakes стали относительно зрелыми и решают проблему центрального репозитория. Однако в репозитории Nixpkgs на GitHub всё ещё остаётся более 5 тысяч открытых задач и сопоставимое количество пулреквестов, и он продолжает ежедневно получать множество коммитов. Добиться включения пулреквеста с новым инструментом в Nixpkgs может быть сложно — файл README репозитория Nixpkgs прямо не рекомендует пользователям добавлять свои «любительские» проекты. На nix форуме существует "вечная" тема посвященная пулреквестом оставшимся без внимамия.

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

Репозиторий Nixpkgs огромен. Он содержит более 120 тысяч пакетов, но большинство из них не являются нативными для Nix. Например, около 10% составляют импортированные пакеты Haskell. Поэтому такое большое число не может служить надёжным показателем того, насколько хорошо развит процесс публикации в Nix. К примеру, только в репозитории PyPy сейчас насчитывается почти 900 тысяч пакетов. Аналогичные подход можно встретить и в Java - Maven Nexus, и в NodeJS - npm, и в Perl - CPAN...

Также важно отметить, что Python — самый популярный язык программирования общего назначения, и его процесс публикации был разработан программистами для программистов. Однако в этом рабочем процессе нет этапа пулреквеста! По сути, интерфейс работает по принципу «загрузил и забыл», что положительно влияет на конверсию пакетов Python.

Flakes легко устанавливать, но процесс их публикации пока недостаточно отлажен. Текущий подход к распространению flakes, по-видимому, унаследовал многие черты рабочего процесса Nixpkgs.

Для Nixpkgs это был естественный путь развития, поскольку все деривации образуют большое и связанное Nix-выражение, разбитое на множество файлов внутри одного Git-репозитория.

Размышления выше мотивировали меня написать сайт для управления классическим репозиторием специально заточенным на флейки.

a-piece-of-flake-nix-repository

Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает

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

У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:

• Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.

• Обсудим, как сократить нагрузку на команды за счёт managed-подхода.

• Проведём живое демо от коммита в консоли до артефакта в registry.

Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.

Книга Pro Git.

Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.

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

Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.

Книга рассчитана на начинающих пользователей или тех, кто имеет конкретные вопросы по механикам Git и им нужен подручный справочник. Что немаловажно, сайт и книга переведены на русский язык.

Pro Git не раз мне пригодился в прошлом, рекомендую.

Страница Pro Git: https://git-scm.com/book/ru/v2

Lazygit.

При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.

И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.

И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.

Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.

Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.

Автоматическое добавление номера задачи в коммит

Привет, Хабр! 👋
Хочу поделиться небольшой, но полезной фичей, которая упростила мне жизнь при оформлении коммитов.

В своей работе я придерживаюсь структурированного подхода к именованию веток и сообщений коммитов. Подробнее об этом можно почитать здесь:
📎 https://habr.com/ru/articles/820547/

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

Почему это удобно?

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

Пример структуры ветки:

feat/dev-123_filter или fix/dev-432_filter

Сообщения коммитов я пишу в следующем формате:

dev-123 | настроил сортировку в фильтре

Чтобы не вставлять руками номер задачи каждый раз, я написал небольшой shell-скрипт, который делает это автоматически.

Скрипт prepare-commit-msg

#!/bin/sh

COMMIT_MSG_FILE=".git/COMMIT_EDITMSG"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)

if echo "$BRANCH_NAME" | grep -qE 'dev-[0-9]+'; then
  TASK_ID=$(echo "$BRANCH_NAME" | grep -oE 'dev-[0-9]+')

  if ! grep -q "$TASK_ID" "$COMMIT_MSG_FILE"; then
    sed -i.bak "1s/^/$TASK_ID | /" "$COMMIT_MSG_FILE"
    rm -f "$COMMIT_MSG_FILE.bak"
  fi
fi

Скрипт нужно сохранить как .git/hooks/prepare-commit-msg и сделать исполняемым:

chmod +x .git/hooks/prepare-commit-msg

Как это работает?

• COMMIT_MSG_FILE — путь до файла, в который Git записывает текст коммита.

• BRANCH_NAME — название текущей ветки.

• Сначала проверяется, есть ли в названии ветки номер задачи (dev-123).

• Если он найден и ещё не указан в коммите — скрипт добавляет его в начало первой строки сообщения.

Таким образом, ваш коммит автоматически будет выглядеть так:

dev-123 | добавил пагинацию в список товаров

Вроде мелочь, а приятно — экономит время и упрощает навигацию по истории коммитов.

Если будет интересно — это и другие полезные скрипты, на моём GitHub

https://github.com/prog-time

Спасибо за внимание! ✌️

Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков

Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.

Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.

Инструменты безопасности

На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.

По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.

Чат‑режим в SourceCraft Code Assistant

ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.

Зеркалирование и бесшовная миграция

Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.

Также появился федеративный доступ к платформе для компаний — авторизация через SSO.

Публичный API

Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.

Правила работы с ИТ‑проектами

В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.

Опенсорс

Появился анонимный доступ к публичным репозиториям платформы. Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.

Удобство работы с кодом

Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.

Автоматизация CI/CD‑процессов

Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.

Packages

Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.

Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.

«Первая Форма» представила новую админпанель для быстрой low-code настройки

В новой версии low-code BPM-системы «Первая Форма» представлена обновленная административная панель для настройки процессов. Её главное преимущество — редактор, который даёт администраторам системы возможность создавать автоматизации без глубоких технических знаний и привлечения IT-специалистов. Решение помогает быстрее настраивать и оптимизировать процессы.

В редакторе автоматизаций появилось три новых инструмента для работы с запросами:

• Визуализация плана запроса. Эта функция отображает процесс сбора данных из баз и позволяет определить этапы SQL-запроса, которые влияют на производительность. Инструмент помогает администратору понять, как работает его запрос, найти причину долгого выполнения и оптимизировать его.

• Встроенное версионирование скриптов с функцией отката. Если изменения привели к ошибке, администратор может вернуть предыдущую сохранённую версию без потери данных.

• Интеллектуальная система подсказок (IntelliSense). Эта функция помогает быстрее написать запрос к базе данных без указания названий таблиц или полей. Администратор может написать название процесса или параметра, а система сама заполнит нужные значения.

«Обновлённый редактор “Первой Формы” решает ключевые технические задачи при настройке BPM-системы. IntelliSense для создания автоматизаций, инструменты анализа производительности SQL-запросов и система версионирования формируют комплексное решение, которое сокращает технический барьер между бизнес-требованиями и их реализацией».

Евгения Бушуева, руководитель проекта по тестированию нового интерфейса администрирования «Первой Формы»

Другие функции новой версии можно изучить в материале на сайте.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.46.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 746 изменений,
подготовленных при участии 96 разработчиков, из которых 31 впервые
участвуют в разработке.

Основные изменения:

• добавлена экспериментальная поддержка нового вида битовых карт — «pseudo‑merge reachability bitmap», в которых в отличие от структуры «reachability bitmap» данные о наборах объектов, имеющих отношение к коммитам, хранятся в привязке сразу к нескольким коммитам.

• реализован интерфейс командной строки для команды «git config», в котором вместо разрозненных опций для просмотра, переименования и удаления настроек и секций, таких как «‑get», «‑get‑all», «‑unset» и «‑remove‑section», предложен набор отдельных субкоманд.

• В команду git добавлена опция «‑no‑advice», отключающая все сообщения с рекомендациями и подсказками, что может оказаться полезным для предотвращения забивания лога лишней информацией при автоматизированном вызове git.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.45.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию Git принято 540 изменений, подготовленных при участии 96 мейнтейнеров проекта, из которых 35 впервые приняли участие в разработке.

Основные изменения:

• добавлена предварительная поддержка бэкенда "reftable" для эффективного хранения в репозитории ссылок на ветки и теги;

• предоставлены средства для обеспечения переносимости между идентификаторами объектов на базе хэшей SHA-1 и SHA-256;

• добавлена новая команда "git reflog list" для показа известных reflog-ов и соответствующих им ссылок на теги и ветки;

• в команде "git checkout -p" разрешено использовать символ "@" в качестве синонима имени "HEAD";

• предоставлена возможность определения альтернативных префиксов для вывода "git diff", отображаемых перед файловым путём;

• добавлен параметр core.commentString для определения строки-разделителя вместо символа "#" для игнорирования комментариев в сообщении для коммита.

Описание и комменты к код ревью

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

Выложив Pull Request, напиши к нему описание и оставь комментарии.

Вспомните свои ощущения, когда нужно поделать ревью. Лично я зачастую испытываю лень. Нужно открыть код, разобраться, какую задачу и каким способом он решает, составить собственное мнение, оставить комментарии... Можно устать, просто прочитав это предложение.

Позаботьтесь о своих коллегах. Сделайте короткое описание к PR, расскажите в двух словах о решаемой задаче и способе её решения (что было сделано).

Не нужно растекаться словом по древу. Достаточно буквально 3-5 предложений. Читать огромную портянку текста тоже никто не захочет.

Сделав это, оставьте комментарии к самому коду. На что ревьюерам стоит обратить внимание? Где вы сомневаетесь в своём решении? Если есть доработки какого-то общего кода, то зачем они были сделаны?

Эти комментарии облегчат жизнь человеку, который будет смотреть ваш код. Помогите ему выделить главное из кода и заострить своё внимание именно на этом.

Больше интересного про жизнь в IT у меня в ТГ