|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
Компания от 3 разработчиков выросла до 10 и частота коммитов в репозиторий возрастает соответственно, а значит тестировать становится сложнее, причем в предрелизный период (когда активно фиксятся баги) доходит до того что коммиты в репозиторий приходят быстрее чем успевает отрабатывать тесткомплит. Прошу поделиться опытом про перевод проекта на систему dev, beta, stable веток. Как организуется? Как управляется? Как с такой системой живется? Что используете? Какие выявлены + / - ? Мы используем SVN, с распределенными системами не работал, может стоит перейти на них для обеспечения системы нескольких веток и легкого перекидывания изменений из одной ветки в другую? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.10.2011, 21:59 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
Cheese)))Компания от 3 разработчиков выросла до 10 и частота коммитов в репозиторий возрастает соответственно, а значит тестировать становится сложнее, причем в предрелизный период (когда активно фиксятся баги) доходит до того что коммиты в репозиторий приходят быстрее чем успевает отрабатывать тесткомплит. Прошу поделиться опытом про перевод проекта на систему dev, beta, stable веток. Как организуется? Как управляется? Как с такой системой живется? Что используете? Какие выявлены + / - ? Мы используем SVN, с распределенными системами не работал, может стоит перейти на них для обеспечения системы нескольких веток и легкого перекидывания изменений из одной ветки в другую? Если бы вы сначала тестировали релиз целиком, потом фиксили все выявленные баги, и потом снова тестировали релиз целиком - такой каши у вас бы не было. SVN прекрасно справляется с большими проектами, с частотой релизов примерно раз в неделю (модель SaaS). Над проектом может работать параллельно шесть-семь проектных групп (разработчики и тестировщики), готовя последовательные релизы и при этом не мешая друг другу. Не в сабвершене ваша проблема. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2011, 15:04 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
The employerSVN прекрасно справляется с большими проектами, с частотой релизов примерно раз в неделю (модель SaaS). Над проектом может работать параллельно шесть-семь проектных групп (разработчики и тестировщики), готовя последовательные релизы и при этом не мешая друг другу. Не в сабвершене ваша проблема. +1 Скорее всего проблема именно на фазе передачи версии продукта из development`a в qa. достаточно удобным показался подход (правда тогда была значительно бОльшая команда), когда итерация "билась" на несколько параллельных критических путей в плане и под каждый путь создавался свой бранч и своя команда + стадия интергации и регрессии в конце. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2012, 16:26 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
Cheese)))...тестировать становится сложнее, причем в предрелизный период... тут проблемы не в механике. а в головах менагеров. правильно сказали выше - пытаться паралелить куски выполнения. но это одно из самых маленьких способов. нарисуйте се идеальное решение. а) процесс разработки итерационен и включает в себя не только программирование и тестирование. а может захватывать и аналитику и проектирование и т.д.. всё зависит от грамотности первичной декомпозиции задачи(ну это уже совсем другой склад инфы) б) тестировщики тестируют статичный код. в) программисты работают над фичами в следующий релиз г) пофикшенные баги с наименьшими проблемами для людей фиксились и в других необходимых для клиентов версиях продукта. д) тестирование автоматическое. е) люди на тестировании задействованны только на поиск новых проблем ж) и т.д... при таком подходе(конечно же не все пункты тут написал. опустил вектор по самому производству софта) возможно (сейчас внимание!) автоматическое получение прогноза по времени выхода версии! удачи вам (круглый) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2012, 17:50 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
kolobok0тут проблемы не в механике. а в головах менагеров. правильно сказали выше - пытаться паралелить куски выполнения. но это одно из самых маленьких способов. Совершенно верно. Соберитесь духом и наведите порядок в своём хозяйстве. 1) Постоянно делать билды проекта и передавать его тестерам. 2) Тестеры должны знать какие баги можно тестить в данном билде. И соответственно только их и тестят. Интеграция всяких bugtracking - ов и svn позволяет не напрягать мозг над тем что конкретно в отдельном билде можно тестить. С бранчами песня ещё та. Можно разделить проект на "основной" и "основной+новые фичи". В "основном+новые фичи" фиксить баги и добавлять фичи. Баги мержить в "основной". Если чтото добавить в "основном" напрямую то придёться полностью мержить с "основной+новые фичи". А так выпустили "основной" и заменили его на "основной+новые фичи". Как вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2013, 17:06 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2013, 17:07 |
|
Перевод одного потока проекта на dev, beta, stable ветки
|
|||
---|---|---|---|
#18+
черт, на дату топика не посмотрел ) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2013, 17:09 |
|
|
start [/forum/topic.php?fid=37&msg=38266805&tid=1555400]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 286ms |
total: | 428ms |
0 / 0 |