Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?

Новая процедура сдачи-приемки работ

Проблемы

На 14.11.2008 система сдачи исходных кодов неприемлема по следующим причинам:
— Очень сложно отслеживать изменения и находить полный вариант исходного кода, соответствующего исправлению данной ошибки (приходится просматривать логи);
— Изменения, произведенные компанией «Компания1», приходится интегрировать вручную;
— Десинхронизация между исходным кодом «Компания1» и эталонными исходными кодами «Компания2».



Возможные решения

Принять более жесткую методику, которая будет позволять:
— Быстро получать общие сведения об этапах развития eServices при помощи умелого использования менеджера исходных кодов (SVN);
— Упразднить всякую необходимость ручного вмешательства с целью отследить изменения исходных кодов;
— Обеспечить соответствие между исходным кодом «Компания1» и эталонными исходными кодами «Компания2».



Сегодняшняя процедура сдачи-приемки работ

1- На каждое исправление ошибки или запрос об обновлении Компания2 направляет в Компания1 файл спецификации.
2- Компания1 исправляет ошибки / производит обновления, затем тестирует сценарии, описанные в запросе.
3- Компания1 обновляет («commit» на языке SVN) измененные файлы, размещая их в своей ветке менеджера исходных кодов (SVN).
4- Компания1 по почте извещает Компания2, что задание выполнено и прилагает список измененных файлов по каждому запросу об исправлении ошибки.
5- Компания2 вручную забирает файлы, перечисленные в списке, и интегрирует их в свой исходный код.
6- Компания2 тестирует сценарии, указанные в запросе.
7- Компания2 загружает обновления на серверы.



Желаемая процедура сдачи-приемки работ

1- На каждое исправление ошибки или запрос об обновлении Компания2 направляет в Компания1 файл спецификации.
2- Компания1 создает по одной ветви на каждую группу ошибок / обновлений путем копирования ветви под названием «integration». Создаваемые ветви должны называться следующим образом: « bugX », где X – это номер ошибки / обновления, который фигурирует в спецификации.
3- Чтобы работать с ошибкой / обновлением, нужно заново сконфигурировать исходную папку, чтобы она переключилась на соответствующую ветку («switch» на языке SVN), затем обновить проект в Eclipse («refresh» на языке Eclipse), чтобы включить в него произведенные обновления.
4- Компания1 исправляет ошибки / производит обновления, затем тестирует сценарии, описанные в запросе.
5- На каждую исправленную ошибку:
a. Компания1 обновляет (« merge » на языке SVN) ветку «integration», интегрируя в нее все изменения из исправленной ветки;
b. Компания1 по почте извещает Компания2, что исправлена ошибка / произведено обновление;
c. Компания1 ожидает ответа Компания2 прежде, чем проинтегрировать следующую ветку в ветку «integration».
6- Компания2 тестирует сценарии, описанные в запросе, непосредственно в верви «integration».
7- Компания2 утверждает произведенные изменения и применяет их к эталонной версии («trunk» на языке SVN).
8- Компания2 загружает обновления на серверы.

Вот мой ответ на это:

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

Данное предложение было сформировано после отправки мною следующего текста: ««now, for each bug, we do a copy branch of our head revision» — предположим, одновременно поставлено 6 заданий. То есть мы одновременно должны работать с 6 ветками. Как вы себе это представяете? Предположим что мы это сделали (пока не представляю как), затем надо все эти 6 веток объединить в одну рабочею. Например, в 3 заданиях менялись одни и теже файлы, вы никогда их автоматически не смигрируете. Это ужастная ручная работа. Вы готовы подписаться на нее?» Суть же нисколько не изменилось грубо говоря вместо 6 веток будет 3 ветки и история описанная выше повториться. Тогда смысл вообще использовать SVN? Также процедура отправки кода усложняется в разы. На дворе 21 век, так давайте использовать современные технологии, а то работа превратиться в отправку писем туда сюда =(
«Очень сложно отслеживать изменения и находить полный вариант исходного кода, соответствующего исправлению данной ошибки (приходится просматривать логи)» — именно для этих целей в свое время и были придуманы такие системы как SVN (и другие). Не понимаю в чем сложность: после того как мы в ветку baltatsoft закомитили свои изменения, все что вам необходимо это средствами SVN сделать операцию «megre» с нашей веткой. И вуаля: получите рабочею версию объединения с нашей веткой. Если случиться так, что мы и Вы затронули один и тот же файл, тогда SVN откроет окно для Ручной миграции, в котором достаточно просто все мигруется. Это намного проще и быстрее чем заниматься объединением 2+ веток. В чем тут сложность объясните пожалуйста. Обычно этим занимается один человек, в нашем отделении это Я (Кузьмик Максим – как руководитель проектов) в вашем случае это может быть Сандра или Кристофер. За это мы получаем деньги
Вношу встречное предложение по автоматизации взаимодействия:
1. Accleya присылаем нам задание по почте buxNN (хотя для этого тоже есть свои системы учета ошибка, которые кстати могут интегрироваться с SVN – например Jira. Там при коммите указывается номер ошибки в системе JIRA и вы при просмотре уже в JIRA увидите какие файлы были затронуты, но это так обсуждение на будущее. Внутри нашего офиса мы используем именно ее).
2. Мы производим мигрирование своей ветки с вашей последней.
3. Мы (Компания1) вносим необходимые изменения для ошибки
4. Мы (Компания1) занимаемся тестированием и отладкой.
5. Мы (Компания1) комитим одним махом для одной ошибки, при этом указывая в комментариях номер ошибки.
6. Отправляем вам номер получившейся ревизии, с котором вам необходимо провести мигрирование.
7. Accleya производит мигрирование средствами SVN со своей рабочей веткой.
8. Компания2 тестирует сценарии, описанные в запросе, непосредственно в верви «integration».
9. Компания2 утверждает произведенные изменения и применяет их к эталонной версии («trunk» на языке SVN).
10. Компания2 загружает обновления на серверы.

Скажите кто прав кто виноват?

Здравствуйте, EyfelFenk, Вы писали:

EF>Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?
[skipped]
EF>Скажите кто прав кто виноват?

По мне так — бред. Предложенная система — не что иное, как эмуляция допотопного этапа технологий работы с исходниками (сырцы + собрание патчей) новыми (СВН), которые позволяют работать гораздо эффективнее. Результат — паровой двигатель с электронным управлением, но требующий кочегара. А для каждого рефакторинга тоже по ветке создавать? А если надо подправить очепятку в комментарии? Упомянутые проблемы вполе решаемы при помощи release notes + чёткой commit policy (установить формат описаний комитов, включающий номер исправленного бага, обязать девелоперов при закрытии багов указывать ревизии, в которых они исправлены — надеюсь, хоть issue tracker нормальный есть, или тоже какое-нибудь чудо, вроде таблицы Excel в расшаренной папке?)

MS>По мне так — бред. Предложенная система — не что иное, как эмуляция допотопного этапа технологий работы с исходниками (сырцы + собрание патчей) новыми (СВН), которые позволяют работать гораздо эффективнее. Результат — паровой двигатель с электронным управлением, но требующий кочегара. А для каждого рефакторинга тоже по ветке создавать? А если надо подправить очепятку в комментарии? Упомянутые проблемы вполе решаемы при помощи release notes + чёткой commit policy (установить формат описаний комитов, включающий номер исправленного бага, обязать девелоперов при закрытии багов указывать ревизии, в которых они исправлены — надеюсь, хоть issue tracker нормальный есть, или тоже какое-нибудь чудо, вроде таблицы Excel в расшаренной папке?)

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

EF>Предположим что мы это сделали (пока не представляю как), затем надо все эти 6 веток объединить в одну рабочею. Например, в 3 заданиях менялись одни и теже файлы, вы никогда их автоматически не смигрируете. Это ужастная ручная работа. Вы готовы подписаться на нее?»

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

Здравствуйте, VGn, Вы писали:

VGn>По хоршему, не должно быть такой архитектуры, чтобы в разных заданиях менялись одни и те же файлы (по крайней мере это должно быть минимизировано).
VGn>А мержить, извините, говнокод — это всегда то ещё удовольствие.

Согласен с тобой. И это все ложиться на мои руки =(

Здравствуйте, MaxSem, Вы писали:

MS>хоть issue tracker нормальный есть, или тоже какое-нибудь чудо, вроде таблицы Excel в расшаренной папке?)

у нас в команду мы использует Jira. А что у них на стороене не знаю, но все задания приходят в виде word-документа =) Который они делают Ctrl+C Ctrl+V — меняя тока задание и скрины =(

Когда "Желаемая процедура..." по количеству пунктов больше, чем "Сегодняшняя ...", лично у меня возникает некоторое недоумение в целесообразности предлагаемых изменений.

И еще такой момент, раз, как я понял, нужна видимость происходящего в репозитории. Сам с svn пока не работал, используем cvs, но тем не менее для обоих доступна такя штука как Atlassian Crusible/FishEye. Не сочтите за рекламу, но реально удобно и уже не представляем как раньше работали без этого тула — http://www.atlassian.com/software/fisheye/

Здравствуйте, EyfelFenk, Вы писали:

EF>Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?

Руководство не читал. Скажу лишь, что создание для каждой issue отдельной ветки в системе контроля версий — это вполне нормальная и распространенная политика. Ветка естественно должна отращиваться от интеграционной, куда потом все изменения будут мержиться. Одно из преимуществ такой политики — возможность точно восстановить какие изменения по какой issue проводились. И вообще это упорядочивает и структурирует процесс.

Здравствуйте, EyfelFenk, Вы писали:

EF>Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?

А насколько вообще реалистично это соблюдать?

Вот, допустим, были найдены десять проблем (issue), казалось бы, не связанных между собой.
Лезем в код и видим, что отнюдь, три проблемы порождены одним и тем же багом.
Уже здесь непонятно, как разбросать исправление по трём веткам. В одной исправить, в двух забить, или размазать исправление на три части, симулировав бурную деятельность?

Ладно. Предположим, что каждая ветка — не на проблему заводится, а на одно исправление.

Далее. Во время отладки обнаруживаем ещё несколько проблемных мест, до которых тестеры не успели дотянуться. Устраиваем задел на будущее (вставляем //TODO или даже что-то наполовину, а то и полностью исправляем). Что с этим делать? Избирательный коммит, или самостоятельно вносим в спецификацию эти ошибки?
Или программист с железной дисциплиной записывает все свои мысли a propos на бумажку, делает коммит исключительно по ранее открытым багам, а затем начинает в рабочей ветке трудиться в своё удовольствие?

В общем, что-то мне кажется, что беда живёт где-то этажом выше, на уровне организации рабочего процесса, а её пытаются решить техническими изысками.



P.S. Я не знаю "как должно", а спрашиваю. Может быть, есть такая методика, когда one shot one body и это работает?

Здравствуйте, Кодт, Вы писали:

К>Вот, допустим, были найдены десять проблем (issue), казалось бы, не связанных между собой.
К>Лезем в код и видим, что отнюдь, три проблемы порождены одним и тем же багом.
К>Уже здесь непонятно, как разбросать исправление по трём веткам. В одной исправить, в двух забить, или размазать исправление на три части, симулировав бурную деятельность?

Исправить баг по одной issue, две оставшиеся закрыть, указав (в системе баг-трэкинга), что они являются дупликатами первой.

К>Ладно. Предположим, что каждая ветка — не на проблему заводится, а на одно исправление.

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

Заводим в системе баг-трэкинга issues для каждой проблемы, и фиксим каждую на отдельной ветке. В принципе можно завести и одну issue на все найденные проблемные места, особенно если они связаныю

Здравствуйте, dwebster, Вы писали:

D>Исправить баг по одной issue, две оставшиеся закрыть, указав (в системе баг-трэкинга), что они являются дупликатами первой.

Хорошая мысль! (Хотя и заплаточная).

А вот подумалось: что в багтрекере нужно вводить две сущности
— issue как видимую часть проблемы; то, что тестер наблюдает и может воспроизвести
— bug как внутреннюю причину; то, что устраняет программист
В том случае, когда связь — не 1:1, нельзя вот так взять да и объявить несколько разных симптомов дубликатами друг друга. Сценарии воспроизведения-то разные.
(Например: "программа иногда валится при старте" и "программа всё время утверждает, что 2*2=5" — если не повалилась при старте; из-за единственного расстрела памяти; фига се дубликаты).
Поскольку процедура закрытия состоит из 2 этапов (придание статуса resolved и затем closed), все issue нужно перепроверить. А то вдруг баг недоисправлен.

Либо завести параллельно два багтрекера, в одном тестеры будут говорить на своём языке (то, что наблюдают они: интерфейс пользователя), а во втором — программисты на своём (то, что является внутренней реальностью: код, API, архитектура...)
И в комментариях в обоих багтрекерах упоминать, что чему соответствует.

На самом деле, багтрекеров должно быть больше: есть ещё поток жалоб и предложений со стороны пользователей (хотя бы и привилегированных — бета-тестеров).
В SpbSoft для этого используется обычный форум phpBB, доработанный напильником (чтобы разработчики могли отслеживать статус по каждой ветке: кто ответственный, что закрыто).
Нельзя сказать, что очень удобно. Скорее, принцип наименьшего удивления пользователя: одно дело оставаться на форуме, и другое — осваивать багтрекер.


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

D>Заводим в системе баг-трэкинга issues для каждой проблемы, и фиксим каждую на отдельной ветке. В принципе можно завести и одну issue на все найденные проблемные места, особенно если они связаныю

1) При условии, что разработчик имеет право открывать и закрывать issues.
А главное, что тестер будет делать с записью "ошибка: такая-то переменная принимает мусорное значение"? Запускать под дебаггером, что ли?
2) И всё-таки, что делать с шаловливыми руками? Когда исправляешь не одно, а сразу несколько мест. Только очень частые коммиты и бранчи спасут тяжело раненого кота?

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, dwebster, Вы писали:

D>>Исправить баг по одной issue, две оставшиеся закрыть, указав (в системе баг-трэкинга), что они являются дупликатами первой.

К>Хорошая мысль! (Хотя и заплаточная).

Это не моя мысль, это стандартный способ разруливания таких ситуаций, который применяется повсеместно

К>А вот подумалось: что в багтрекере нужно вводить две сущности
К>- issue как видимую часть проблемы; то, что тестер наблюдает и может воспроизвести
К>- bug как внутреннюю причину; то, что устраняет программист
К>В том случае, когда связь — не 1:1, нельзя вот так взять да и объявить несколько разных симптомов дубликатами друг друга. Сценарии воспроизведения-то разные.

Не во всех баг-трекерах есть такое явное разделение... Есть понятие CR (change request). Сиары могут заводить как тестеры, которые наблюдают поведение программы, или разработчики, которые заметили ошибку в коде, тестерами еще не выявленную. Информация о том, что конкретно требуется исправить пишется в записи самого сиара. Также может иметься поле, для определения типа сиара, например — bug, feature, improvement, etc. И если тестерами заведено несколько сиаров, которые воспроизводятся по-разному, но являются следствием одного бага в коде — обычно поступают так, как я описал — фиксят один сиар, остальные закрывают, указывая что это дубликат, по тем-то и тем-то причинам. Придумать что-то лучшее тут сложно Разносить изменение по 3м веткам — это вообще извращение

К>(Например: "программа иногда валится при старте" и "программа всё время утверждает, что 2*2=5" — если не повалилась при старте; из-за единственного расстрела памяти; фига се дубликаты).

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

К>Поскольку процедура закрытия состоит из 2 этапов (придание статуса resolved и затем closed), все issue нужно перепроверить. А то вдруг баг недоисправлен.

Resolved -> (Inspected) -> Integrated -> Tested -> Closed — для пофикшенного сиара
Duplicated -> Tested -> Closed — для сдуплицированного

К>Либо завести параллельно два багтрекера, в одном тестеры будут говорить на своём языке (то, что наблюдают они: интерфейс пользователя), а во втором — программисты на своём (то, что является внутренней реальностью: код, API, архитектура...)
К>И в комментариях в обоих багтрекерах упоминать, что чему соответствует.

Можно и так, только путиницы больше.. Но это дело вкуса и привычки.

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

D>>Заводим в системе баг-трэкинга issues для каждой проблемы, и фиксим каждую на отдельной ветке. В принципе можно завести и одну issue на все найденные проблемные места, особенно если они связаныю

К>1) При условии, что разработчик имеет право открывать и закрывать issues.

Обычно имеет...

К>А главное, что тестер будет делать с записью "ошибка: такая-то переменная принимает мусорное значение"? Запускать под дебаггером, что ли?

Тогда проверять исправление может не тестер, а другой девеловер, или инженер по интеграции, если таковой имеется.
Если же найденный девелопером баг имеет сценарий как его воспроизвести на уровне UI, то девелопер может явно описать этой сценарий, как hint тестеру.

К>2) И всё-таки, что делать с шаловливыми руками? Когда исправляешь не одно, а сразу несколько мест. Только очень частые коммиты и бранчи спасут тяжело раненого кота?

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

Здравствуйте, dwebster, Вы писали:

<>

Спасибо, очень познавательно.
Два махоньких замечания

1) Право разработчику закрывать баг — это (в тех багтрекерах, которыми я пользовался — багзилла, мантис и фогбагз) дыра в юзабилити. Чуть проскроллил по комбобоксу, и опаньки. И тут нас выручает, что есть право открыть баг обратно

2) Действительно, два разных режима работы — стартовый и финальный (вылизывание, техподдержка). Соответственно, получаются разные способы применения и багтрекера, и контроля версий.
А вот интересно, код-ревью насколько удобно на багтрекере вести? И вообще использовать багтрекер как записную книжку для самого себя?

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, dwebster, Вы писали:

К><>

К>Спасибо, очень познавательно.
К>Два махоньких замечания

К>1) Право разработчику закрывать баг — это (в тех багтрекерах, которыми я пользовался — багзилла, мантис и фогбагз) дыра в юзабилити. Чуть проскроллил по комбобоксу, и опаньки. И тут нас выручает, что есть право открыть баг обратно

Ну право закрывать можно и не давать разработчикам.. Давать только тестерам и менеджерам... Если конечно система позволяет так назначать права.

К>2) Действительно, два разных режима работы — стартовый и финальный (вылизывание, техподдержка). Соответственно, получаются разные способы применения и багтрекера, и контроля версий.
К>А вот интересно, код-ревью насколько удобно на багтрекере вести? И вообще использовать багтрекер как записную книжку для самого себя?

Насчет ревью — для этого может применяться отдельная система, интегрированная с баг-трекером.. Или отдельные документы (excel-формочки например), которые потом аттачатся с сиару в баг-трекере.
А насчет записной книжки — бывает удобно заносить в сиар информацию по ходу анализа или разработки.. Это и менеджменту помогает отслеживать прогресс..

Здравствуйте, Кодт, Вы писали:

К>Хорошая мысль! (Хотя и заплаточная).

К>Либо завести параллельно два багтрекера, в одном тестеры будут говорить на своём языке (то, что наблюдают они: интерфейс пользователя), а во втором — программисты на своём (то, что является внутренней реальностью: код, API, архитектура...)

ну вообще то что у тебя называется issue это требование. на основании этих требований пишуться тест-кейсы для тестеров.
а то что у тебя bug — это issue для программиста, либо bug либо change request.
ну по крайней мере я сталкивался именно с такой терминологией.
и все нормально. получается действительно две системы — issue tracking и система управления требованиями. по одной разработчик пишет, по другой тестер тестит.

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

Здравствуйте, EyfelFenk, Вы писали:

EF>Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?

Впринципе если мыслить здраво то, каждый разрабочик в определенный момент времени занимается одной задачей, например реализацией новой фичи или устранение бага #nnnnn

Соотвественно под каждого разработчика можно выделить ветку для того чтобы :
— он мог коммитить промежуточные версии
— в последствии фичу которую делал разработчик выкинуть из релиза и перенести на следующий , если она не стабильна.

А SVN впринципе засорять особо не нужно. Все отработанные ветки, которые ушли в общий интеграционный ствол можно просто удалить.

Здравствуйте, EyfelFenk, Вы писали:

EF>Вот начальство прислало следующее руководство, Правильно ли это создвать на одну ошибку одну ветку в SVN?

На одну ошибку правильно создавать одну задачу. Не сочтите за рекламу http://www.telelogic.com/corp/products/synergy