Управление релизами.

Доброго времени суток.
Хочу поинтересоваться как устроена схема выхода новых релизов проектов (в частности WEB) в мир в других компаниях?

Опишу в чем проблема в нашей компании....
Есть штат разработчиков, порядка 20 php девелоперов + 4 верстальщика, дизайнер и т.д..
Приходит время выпускать новый релиз сайта. Что делаем:
- пишем письмо всем dev о том что близится релиз проекта и надо приостановить комиты по новым таскам. (работаем с SVN, блокировать на уровне svn не хочется);
- тестируем таски которые еще не протестированы но закомичены;
- собственно выкладываем проект в мир;
- период дебага.

Что не нравится - оповещение всем девелоперам происходит в режиме имейл разсылки, это достаточно не удобно (забыл, провтыкал .... сделал новый комит, как результат все ждут пока отдел тестирования дотестирует закомиченный таск). Как похожие процессы происходят в других компаниях? Возможно позаимствуем более ефективную схему.

Спасибо.

Интересует именно веб?

Могу рассказать как это делал в свое время для десктопных приложений.
Разработка ведется в транке, затем при достижении заданного набора функционала создается бранч. Далее из бранча собирается продукт и тестируется. Фикс багов идет и в транке и в бранче. После пофикса всех серьезных вещей всем вовлеченным лицам направляется письмо о замораживании бранча. Любые изменения в коде запрещены, либо разрещаются после согласования с менеджером продукта. На уровне CVS не запрещали, но могли поставить алерт с почтовым извещением, мол такой-то что-то записал в этот бранч.
Дальше продукт "полировали" - переводы, справка, картинки и выпускали в релиз.

Что не нравится - оповещение всем девелоперам происходит в режиме имейл разсылки, это достаточно не удобно (забыл, провтыкал .... сделал новый комит, как результат все ждут пока отдел тестирования дотестирует закомиченный таск). Как похожие процессы происходят в других компаниях? Возможно позаимствуем более ефективную схему.

Забыл, провтыкал... Это культура разработки, имхо.
Команда распределенная? То есть нельзя после письма зайти в кабинет к разработчикам и продублировать все в разговоре?

Рекомендую сделать, как написано:
http://habrahabr.ru/post/40462/

Если не сложно и можно, то опубликуйте потом, что получилось.

Что не нравится - оповещение всем девелоперам происходит в режиме имейл разсылки, это достаточно не удобно (забыл, провтыкал .... сделал новый комит, как результат все ждут пока отдел тестирования дотестирует закомиченный таск). Как похожие процессы происходят в других компаниях? Возможно позаимствуем более ефективную схему.

Забыл, провтыкал... Это культура разработки, имхо.
Команда распределенная? То есть нельзя после письма зайти в кабинет к разработчикам и продублировать все в разговоре?

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

Рекомендую сделать, как написано:
http://habrahabr.ru/post/40462/

Если не сложно и можно, то опубликуйте потом, что получилось.

Тут все не плохо описано. Однако работа построена через ветвление проекта. В моем случае (на премере данной группы проектов) это больше не обсуждается. Надо альтернативный путь решения проблемы. Неужели во всех других компаниях все построено через ветки?

2. зайти в комнату и прокричать можно - но, я делаю порядка 2-3 релизов в неделю (разные проекты), каждый раз заходить в 3 комнаты и кричать "проект такой то заблокирован для комитов" а потом "разблокирован" .. девелоперы и по письмам иногда забывают...устно не вариант (да и как то не по взрослому что ли ..).

Ну если и письма забывают и говорить не получается, то блокируйте на уровне хранилища. Это решение почему не хотите попробовать?

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

2. зайти в комнату и прокричать можно - но, я делаю порядка 2-3 релизов в неделю (разные проекты), каждый раз заходить в 3 комнаты и кричать "проект такой то заблокирован для комитов" а потом "разблокирован" .. девелоперы и по письмам иногда забывают...устно не вариант (да и как то не по взрослому что ли ..).

Ну если и письма забывают и говорить не получается, то блокируйте на уровне хранилища. Это решение почему не хотите попробовать?

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

Блокировать на уровне хранилища не совсем корректно, хранилище для того и создано что бы комитить ...слишком уж жестко. + не совсем клево когда из-за тестировщиков (QA) делают плохо разработчикам.

Один из вариантов просто создать веб страничку с расписанием и заставлять перед комитами всех смотреть туда.

У меня нет опыта работы в больших IT компаниях, по этому и обратился на форму. Думаю подобная ситуация уже имеет четкое решение (схему работы) вот только нет у меня знакомых ITшников у кого бы спросить. Возможно ошибаюсь и схема должна быть специфической для каждой команды.

Блокировать на уровне хранилища не совсем корректно, хранилище для того и создано что бы комитить ...слишком уж жестко. + не совсем клево когда из-за тестировщиков (QA) делают плохо разработчикам.

Один из вариантов просто создать веб страничку с расписанием и заставлять перед комитами всех смотреть туда.

Хранилище создано, чтобы хранить, имхо:)

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

То есть вы считаете, что про почту ваши разработчики забывают, но каждый раз перед коммитом будут смотреть на отдельную страницу где-то на сайте?? Странная точка зрения))

Рекомендую сделать, как написано:
http://habrahabr.ru/post/40462/

Если не сложно и можно, то опубликуйте потом, что получилось.

Тут все не плохо описано. Однако работа построена через ветвление проекта. В моем случае (на премере данной группы проектов) это больше не обсуждается. Надо альтернативный путь решения проблемы. Неужели во всех других компаниях все построено через ветки?

Смотрите не пример, смотрите шаблон описания. Сначала опишите как есть сейчас. Потом напишите, что вызывает проблемы и какие. И только потом...

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

Это один из вариантов который я еще буду согласовывать с админами и разработчиками. (тут негатив - к примеру разработчик работает над функционалом который вовсе не виден для юзера и ни на что не влияет пока - ему надо закомитить что бы посмотреть реакцию в другом проекте (у нас связанно порядка 5 проектов - постоянно идет передача между ними), а тут лок от тестировщиков....я бы не обрадовался - работа стоит. Таких примеров можно насобирать достаточно много).

То есть вы считаете, что про почту ваши разработчики забывают, но каждый раз перед коммитом будут смотреть на отдельную страницу где-то на сайте?? Странная точка зрения))

Дак в том то и дело что не считаю. По этому и не внедряю. Просто тут все будет достаточно прозрачно. Есть схема - если завтыкал то будь добр исправляй по быстрей...в дальнейшем скорее всего не повторится. Отличие от писем - все в одном месте. Нет спама по каждому проекту - и не надо помнить статус, заблокирован\разблокирован. Зашел посмотрел и все понятно.

А вопрос бранчей обсудили со всеми участниками и точно не хотите использовать?

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

Забыл, провтыкал... Это культура разработки, имхо.

это пять!

Не хочу что бы у всех сложилось негативное впечатление об девелоперах в моей компании.

Сейчас все работает не так уж и плохо. "Забыл, провтыкал" бывает достаточно редко. Не нравится сама организация. Думаю придумаем что то индивидуальное для себя, или будем так и работать.

Спасибо за обсуждение тем кто принимал участие.

Негативного впечатления нет. Случается с каждым, но хочется минимизировать конечно же:)
Если придумаете что-то свое, то напишите, пожалуйста, об этом потом. Чтобы опыт был увековечен, а не просто все знали, что есть еще какой-то способ