Федот, да не тот (2)

[zHz00]

Если в случае, когда тестирование программы происходит на одной машине, а разработка -- на другой, поведение КРАЙНЕ отличается от ожидаемого (особенно: изменения внесены, но их результат не виден), то в первую очередь следует проверить, что запускается именно та версия, что вы собирались запустить (и из той папки, что надо). Особенно надо проверить имя -- например, если по недосмотру существует две версии программы -- program1-dbg.exe и program1_dbg.exe, то риск запустить не ту -- ОЧЕНЬ велик.

Пожалуйста, ознакомьтесь с комментариями.

Comments

[korrshun]

Добавлять ревизию/тег из системы контроля версий в ресурсы и в имя бинарника не пробовали? ^^'
Ах да, еще помогает добавление даты-времени билда в имя.
Можно еще имя собирающего, чтоб знать, кого канделябром бить при случае.

[zHz00]

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

Добавлять билд -- выход. Но у нас нет выделенного сервера для сборки, поэтому сквозная нумерация билдов невозможна.

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

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

[korrshun]

На практике оказывается, что лишний коммит+тег на билд, который уходит в чужие руки - это очень дешево.
1. Сразу ясно, а чем он собственно говоря такой уникальный и нужный.
2. Точно знаешь, как потом этот билд повторить (почти). И не надо запоминать, что в этом билде сделал. blame не прощает.
3. Отдельный сервер для сборки довольно бесполезная вещь, если собирать для других файлики прямо с машины разработчика. Только контоль версий, только хардкор.
4. Если есть коммит и текст к нему, тестеры лучше знают, что стоит проверять, а на что можно забить.

Если билд-сервера нет, то достаточно обойтись простеньким скрыптом или makefile, который будет коммитить, просить комментарий и тег (это специфика git/hg, в svn придется использовать бранчи), и добавлять в имя/ресурсы получаемого бинарника, что нужно.

Для тестируемых билдов также не обязательно коммитить в транк/мастер, для этого есть фичебранчи. В git/hg они совсем копеечные. Для svn они дороже, но на практике оказывается слишком удобно вести разработку в множестве маленьких и простых бранчей, так что даже у нас перешли к бранчу на тикет.
Потом сливаем в транк. На каждый мерж - отдельный коммит. Потом фиксируем релиз бранчем.
Правда релиз надо еще раз тестировать на предмет того, что все влитые в него бранчи не сломали друг друга, да.
У нас есть против этого багор - мы очень часто релизим, т.е. не возникает большого количества конфликтов при мержах в релизный бранч.

[zHz00]

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

[korrshun]

>>перешли к бранчу на тикет.
Ф-фигасе.

ну я наверно не совсем правильно выразился.
Новый бранч заводится из транка каждый раз, когда заводится тикет на фичу в коде. На баги, которые вылезли на этапе тестирования фичи бранч не заводится - фиксится в этом же бранче, пока не влили в транк/мастер. На баги, которые вылезли в предрелизном тестировании (слили все фичи в транк, готовим релиз) тоже не заводятся отдельные бранчи, если фикс занимает строку-две и на пристальный взгляд не вызывает проблем.

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

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

У коллег с SVN есть отдельный софт для ревью и с фичебранчами тоже стало лучше - ты указываешь ветку и транк, вуаля - есть дифф для ревью.

Из транка можно смело собирать заготовку ченджлогов для релиза и план предрелизного тестирования, т.к. там только коммиты с номерами тикетов и описанием из них.

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

P.S. руками многое делать сложно, рекомендую начать с минимальной скриптовой обвязки для этого. (да хотя бы тот же git flow или аналоги).