Стандарты на передачу дистрибутивов для установки

Нет уверенности идентичности тестируемых дистрибутивов и переданных на установку. Поэтому возникло желание упорядочить ситуацию.

Сейчас обстоит так:

1. Р(разработчик) кодит и выкладывает продукт в BorlandStarTeam
2. Т(тестировщик) чекаутит из стартима bat файл , который выкачивает из стартима файлы дистрибутива
3. Т тестирует и говорит что ОК продукт готов к выносу
4. Р выкачивает из стартима файлы дистрибутива и отдает их на установку

Но ведь нет никакой гарантии, что дистрибутивы были идентичны. (!!!) Билды инкрементяся в стартиме вручную.

Я хочу , опираясь на стандарты, навести порядок. Подскажите стандарты плиз.

Возможно это есть в CMMI.

Вам нужны именно стандарты или просто совет и опыт, чтобы упорядочить ситуацию?

1) Как происходит сборка? Руками, если версии инкрементятся вручную?
2) В дистрибутиве есть одна сквозная версия, по которой можно точно идентифицировать сборку?

А еще уберите разработчика из последнего шага. Тестеры все проверили? Вот пусть и отдают, зачем вам лишнее звено?

Опыт и совет тоже можно.

1) Сборка по производится антом. Но по сути билдов нет. Есть имплементации. Нумерация заведена так: Maj.Min.Impl.
Если найдена бага то Impl+1.
2) ответ в п.1

1) Сборка по производится антом. Но по сути билдов нет. Есть имплементации. Нумерация заведена так: Maj.Min.Impl.
Если найдена бага то Impl+1.

А если багов нет, но была еще одна сборка? Тогда будет две разные сборки с одним номером? Если так, то это не есть гуд.
Что мешает всегда ставить Impl++?
А что такое "имплементации" в данном контексте?

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

А чем грозит неимение билдов?
Хотелось бы конструктивно пообщаться с руководителем.

Impl - итерация в пределах небольших изменений.

PS мне объяснили, что гарантия идентичности заложена в процедуре работы Р. Т.е. после того как он зарезил версию, он больше не вносит изменения в данный лейбл или ветку, не знаю как там.

Под сборкой я понимаю процесс компиляции из исходного кода исполняемых файлов. Они же потом заворачиваются в дистрибутив.

А чем грозит неимение билдов?

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

Хотелось бы конструктивно пообщаться с руководителем.

С каким?

PS мне объяснили, что гарантия идентичности заложена в процедуре работы Р. Т.е. после того как он зарезил версию, он больше не вносит изменения в данный лейбл или ветку, не знаю как там.

Давайте я объясню, в каком процессе я сам работал в свое время.
Программисты пишут код, заливают его в репозиторий.
Код выкачивается из репозитария и собирается. В процессе успешной сборки берется номер предыдущей сборки, увеличивается на единицу и присваивается текущей сборке. После этого на все исходники ставится тег, чтобы можно было всегда найти и повторить данную конкретную сборку. Далее из полученных бинарников собираются дистрибутивы и выкладываются в отдельную папку.
В отдел тестирования передается необходимый дистрибутив. Про него известно, что это такая-то версия, такая-то программа, может еще локализация быть указана. За данную передачу ответственен ПМ. При этом дистрибутив со сборочного сервера перед отправкой в QA копируется в специально выделенный каталог и ссылка идет уже на этот каталог.
Тестировщики проверяют и если все ок, то дистрибутив известен. Далее идет команда в отдел разработки, чтобы по тегу сборки сделать бранч и заморозить его. Теперь он заблокирован для внесения изменений.
В общих чертах как-то так, кажется основные моменты описал.