GitEtersoftPolicy

Материал из Etersoft wiki
Перейти к: навигация, поиск
Wackowiki-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была автоматически перемещена с old.wiki.etersoft.ru.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.


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



Введение

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


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

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


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

Lav: У нас уже несколько инструкций по пользователю
  1. Выбрать псевдоним (имя пользователя) разработчика. Стоит сделать его совпадающим с именем в почтовом адресе псевдоним@etersoft.ru;
  1. Создать новый OpenSSH ключ (DSA, 1024 бит) с паролем и высылать публичную часть ключа. Этот ключ будет необходим для доступа к 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. Каждая успешная сборка импортируется, с помощью gear-srpmimport, в отдельный репозиторий результирующих сборок - аналог http://git.altlinux.org/archive/
Lav: И где же этот архив?
— устарело


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

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

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


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

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


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

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

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

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


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

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

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

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

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

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


Ссылки