GitEtersoftPolicy

Порядок работы с GitEtersoft

Введение

Основной целью этого документа является подробное описание регламента работы с GitEtersoft. Регламент прежде всего направлен на указание типичной схемы распределения прав, которую позволяет организовать схема взаимодействия с UsesGit git-репозиториями по протоколу ssh.

Минимальные необходимые требования

Для полноценной работы с GitEtersoft необходимо получить доступ по протоколу ssh к серверу git.etersoft.ru. Правила по созданию и управлению ключами для работы с git.etersoft.ru составлены на основе правил вступления в команду ALT Linux.

Необходимые действия для создания ключей:

Lav: У нас уже несколько инструкций по пользователю

1. Выбрать псевдоним (имя пользователя) разработчика. Стоит сделать его совпадающим с именем в почтовом адресе псевдоним@etersoft.ru;

1. Создать новый SSH ключ с паролем и высылать публичную часть ключа. Этот ключ будет необходим для доступа к Girar.

Ключ создаётся следующей командой:

$ ssh-keygen -t dsa

Публичная часть ключа — файл /.ssh/id_dsa.pub

1. Создать GPG/PGP ключ (DSA and ElGamal, 2048 бит. В ключе должен быть uid вида псевдоним@etersoft.ru) и выслать его публичную часть

Ключ высылается в ASCII виде. Экспортирование выполняется следующей командой:

$ gpg --export --armor [имя ключа] >[файл с экспортированным в ASCII ключом]

Регламент работы GitEtersoft

Порядок работы разработчиков

1. У каждого разработчика и мейнтейнера есть свой набор репозиториев, аналогично тому, как это организовано в git.altlinux.ru/people (
   лишнее сравнение
   ). Этот набор репозиториев — сфера ответственности одного человека, его промежуточные и конечные результаты.

1. Результат деятельности по отдельному пакету фиксируется по заданной ветке репозитория того, кто является ведущим этого проекта (в данном случае я несколько вольно употребляю слова пакет и проект как синонимы, обычно проект может в себя вкпючать более одного пакета).

1. При необходимости совместно вести работу разработчики синхронизируются по репозитарию ведущего, но могут самостоятельно вести работу в своём репозитории.

Автоматическая сборка централизованного репозитория

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

1. Робот регулярно (например ежедневно), проверяет наличие новых пакетов сравнением текущей версии пакета с самой старшей версией тега (вида пакета-версия-релиз) в репозиории.

1. 1. После получения списка пакетов на пересборку производится процесс пересборки с учётом зависимостей

1. 1. Для принудительной сборки пакета существует скрипт, которым пользуется Робот. Скрипт позволяет по имени пакета и соответствию пакетов разработчикам, найти и выбрать нужный репозитарий и собрать пакет последней или заданной версии.

1. После сборки пакета робот отправляет лог сборки разработчику - с успехом или ошибкой.

1. Каждая успешная сборка импортируется, с помощью gear-srpmimport, в отдельный репозиторий результирующих сборок - аналог http://git.altlinux.org/archive/

Lav: И где же этот архив?

— устарело

Ключевые особенности регламента

Что позволяет делать такая схема?

1. Отдельные задачи можно легко передавать от одного разработчику, не задаваясь вопросом о правах. Каждый вновь получающий пакет, выписывает его у последнего. Например, я веду пакет Package1. Потом его передают Диме, затем над ним продолжает работу Сергей.

1. Можно проводить аудит и коррекцию работы, а также помогать, не мешая работе основного разработчика. Например, Сергей ведёт пакет Pаckage2. Я выписываю его текущий результат, обнаруживаю недочёт и сообщаю ему об этом. Он выписывает мои исправления к себе в основной код или отдельную ветку. Последнее тоже важно. Мои изменения могут показаться Сергею недостаточными, но он сможет посмотреть их, не внося изменения в свой основной код.

1. Можно качественно проводить совместную работу удалёнными друг от друга разработчиками. Ответственным за сбор конечного пакета является один человек - ведущий. Именно из его репозитория собирается результат в репозиториях доступных обновлений. Например, Я веду пакет Package3, со мной вместе его ведут ещё два человека. При необходимости они всегда могут получить мои изменения, но могут вести свои работы отдельно. Моя ответственность состоит в том, чтобы согласовать ветку, в которой я получаю результаты их работ. Между тем они сами могут брать изменения друг у друга, а могут доверять мне и регулярно сообщая мне о своих результатах, могут обмениваться изменениями через меня.

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

У этого подхода есть недостатки:

вписать

Базар в разработке

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

Вот ситуации, когда это может требоваться:

• если работа нам проектом организована коллективным образом, и при этом нет ответственного за проект.

• если требуется постоянное место для репозитория, не зависящее от конкретного ведущего проекта (в случае публичного проекта).

В этом случае проект создаётся в git.eter:/projects или соответствующем подкаталоге projects. Администратором в группу доступа к проекту вносятся те, кому разрешена публикация.

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

При разработке в режиме "каждый коммит стабилен" (то есть риск, что внесённые изменения повлияют на стабильность работы) может использоваться только общий репозиторий,

без публикации в свои репозитории.

Частным случаем может быть публикация изменений (патчей) в общий репозиторий посредством отправки патчей в список рассылки. В этом случае патчи в общий репозиторий

прикладывает модератор.