Re: Подскажите инструментарий для file release system.
> > У нас предприятие было маленькое, и в итоге всё свелось к тому, что от
> > разграничения прав один геморрой, поэтому всё свелось к ssh и одной группе
> > разработчиков. Маленькое - это полтора десятка человек, которым нужен этот
> > доступ, и примерно столько же проектов. Практика показала, что почти в каждый
> > проект может потребоваться коммит почти от любого разработчика. Поэтому
> > технические средства разграничения только мешали - в конце концов, не
> > трехлетние дети работали, интеллекта не коммититься куда не надо людям
> > хватало.
> >
> Сходная ситуация, "может потребоваться коммит почти от любого
> разработчика".
Тогда заморачиваться на разграничение прав не стоит.
> > В нынешнем предприятии, насколько я понимаю, ситуация примерно та же, хотя
> > народу существенно больше. Даже систем версионирования принципиально
> > различных используется больше двух. Но доступ не разграничивают, потому что
> > не нужно. Ошибочные коммиты встречаются, но их несложно откатить, а
> > разграничение прав предотвращает не больше половины ошибочных коммитов.
> >
> "Плохой" комит встречается часто и допустим в том смысле что не будет
> неожиданостью т.к. впереди тестирование и/или ревью.
>
> Но ситуация меняется когда продукт отдается вовне... ошибки досадны
> и болючи.
>
> Прихожу к тому что бы использовать файлы CHANGES (user visible changes)
> и VERSION (major.minor.fix). В момент релиза в CHANGES вноситься
> дата, версия ("новая") и ревизия из VCS (нужно ли?),
> доправляються описания изменений,
> в соответствии со степенью изменений обновляется
> VERSION и происходит комит, который говорит что некто считает
> (ручается) что состояние проекта отвечает перечисленым в
> CHANGES свойствам и готово работать.
>
> После комита делаем таг в соответствии с содержимым VERSION,
> собираем проект с релизом на FRS (file release system).
>
> Сборка предварительно поверяет нет ли локалыных изменений,
> в случае наличия прерываем сборку.
>
> В принципе по факту создания тага сервер сборок может делать релиз...
А вот тут расскажу, как это делали мы. Собственно, мы брали схему,
неоднократно описанную во всех книгах по использованию VCS, подробнее всего,
кажется, в SVN book.
Есть ствол, где идет основная разработка.
Есть feature branches - для экспериментов с отдельными идеями, иногда довольно
продвинутыми. Одна такая ветка жила два года. Но в норме идея в том, что ты
форкаешь ветку, реализуешь фичу, прогоняешь ее через тестовую ферму (была
система автоматической сборки и прогона тестов), и либо в конце концов
решаешь, что идея была дурацкая и просто убиваешь ветку, либо вливаешь
результат в основную (если точнее, то технологически ты сначала вливаешь
пропущенные изменения из ствола в свою ветку, снова тестируешь, и только потом
вливаешь результат в ствол).
Есть release branches - для подготовки релиза. По отмашке "готовим релиз" она
форкается от ствола, и далее в ней только правятся баги, найденные
тестировщиками.
Есть релизы - это, собственно, tag в тех VCS, которые поддерживают его
непосредственно, для svn это было конвенциональное svn copy . .../tags/v.1.0.0
Скрипт проверки на сервере не позволял менять ничего под tags, только
создавать, и не позволял создавать тег, у которого был external, ссылающийся
на изменяемое состояние репозитория (т.е. ссылаться можно было либо на
какую-то конкретную ревизию, либо на тег другого репозитория).
И есть support branches - для исправления багов, найденных в выпущенных
релизах. Она форкается от соответствующего релиза, и дальше примерно как с
release branch, только тестировщиком порой работает клиент, у которого
обнаружилась и воспроизводится проблема - ибо не всегда удается воспроизвести
проблему у себя.
Все это - вопрос регламента разработки, техническими средствами тут
поддерживается только вышеупомянутый минимум проверки на коммиты в теги и
рассылка сообщений о коммитах заинтересованным лицам, что позволяет
оперативно отслеживать неудачные коммиты.
--
на вопрос "как дела?" отвечать "304 Not Modified"
-- http://bash.org.ru/quote/20466
Reply to: