Re: Подскажите инструментарий для file release system.
10.10.2011 22:32, Artem Chuprina пишет:
В принципе, идея с Subversion достаточно грамотная. Мне, однако, все время
лень настраивать HTTP-вариант, и я предпочитаю ssh. Ну и кроме того, я сейчас
предпочитаю распределенные VCS, из которых, если хочется попроще, лучше брать
mercurial. Из централизованных - да, я бы брал Subversion.
Действительно, почему не Mercurial (в качестве файлового хранилища)?
Вспомнились команды hg convert/strip, если что - можно легко поправить
оплошности.
У нас предприятие было маленькое, и в итоге всё свелось к тому, что от
разграничения прав один геморрой, поэтому всё свелось к ssh и одной группе
разработчиков. Маленькое - это полтора десятка человек, которым нужен этот
доступ, и примерно столько же проектов. Практика показала, что почти в каждый
проект может потребоваться коммит почти от любого разработчика. Поэтому
технические средства разграничения только мешали - в конце концов, не
трехлетние дети работали, интеллекта не коммититься куда не надо людям
хватало.
Сходная ситуация, "может потребоваться коммит почти от любого
разработчика".
В нынешнем предприятии, насколько я понимаю, ситуация примерно та же, хотя
народу существенно больше. Даже систем версионирования принципиально
различных используется больше двух. Но доступ не разграничивают, потому что
не нужно. Ошибочные коммиты встречаются, но их несложно откатить, а
разграничение прав предотвращает не больше половины ошибочных коммитов.
"Плохой" комит встречается часто и допустим в том смысле что не будет
неожиданостью т.к. впереди тестирование и/или ревью.
Но ситуация меняется когда продукт отдается вовне... ошибки досадны
и болючи.
Прихожу к тому что бы использовать файлы CHANGES (user visible changes)
и VERSION (major.minor.fix). В момент релиза в CHANGES вноситься
дата, версия ("новая") и ревизия из VCS (нужно ли?),
доправляються описания изменений,
в соответствии со степенью изменений обновляется
VERSION и происходит комит, который говорит что некто считает
(ручается) что состояние проекта отвечает перечисленым в
CHANGES свойствам и готово работать.
После комита делаем таг в соответствии с содержимым VERSION,
собираем проект с релизом на FRS (file release system).
Сборка предварительно поверяет нет ли локалыных изменений,
в случае наличия прерываем сборку.
В принципе по факту создания тага сервер сборок может делать релиз...
Еще как нибудь приплести степень качества продукта (alpha, beta, rc
или прошел тестирование) и мир станет идеальным.
Reply to: