> > У нас предприятие было маленькое, и в итоге всё свелось к тому, что от > > разграничения прав один геморрой, поэтому всё свелось к 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 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5wsklfe.wl%...@ran.pp.ru