Поделитесь опытом, как работает ваш отдел качества.
Наш примерно так:
Группа разработчиков пишет код. По готовности заливает в кодохранилище.
В хранилище есть триггер на заливку. По триггеру в бд Oracle записыватся лог — кто, когда и какой файл правил.
По завершении кодирования, в почтовой программе разработчиком создается заявка на сборку проекта для QA.
По кнопке в заявке из оракловой бд подтягивается список файлов, которые менял разработчик.
По списку файлов из заявки группа QA выкачивает соответствующие версии файлов (не обязательно последние) и компилирует проект для выкладки.
Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что.
Разработчик не имеет права создать папку в кодохранилище. Это надо делать по согласованию.
Т.е. писать код проекта в одном файле проблем в QA нет.
Если на дай бог, создать в коде новый файл или папку. Например папку "Interfaces", то нужно писать расширенное обоснование, зачем была создана эта папка. Или зачем был создан файл "DatabaseManager.cs".
Пишешь письмо в QA:
"Interfaces" — папка с интерфейсами
"DatabaseManager.cs" — файл для работы с базой данных.
Только после такого описания, QA создает папку или файл в кодохранилище.
Или вот создал папку "ReportBuilder". QA пишет, что нет описания, для чего была создана эта папка.
Присылаешь им письмо: ReportBuilder" — это генератор отчетов.
Собственно описание папок и файлов это перевод их название на русский язык.
Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Здравствуйте, karkasch, Вы писали:
K>Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что.
Чет ничего не понял откуда такие проблемы. Есть директория в репозитории, которая содержит исходники, соответственно абсолютно все вытягивается при билде. И никаких проблем
А в более реальном случае сборки автоматом на CI сервере билдятся, соответвенно тестерам нужно просто проинсталлировать сборку и все. Что там внутри никого не должно волновать.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, karkasch, Вы писали:
K>>Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что. E>Чет ничего не понял откуда такие проблемы. Есть директория в репозитории, которая содержит исходники, соответственно абсолютно все вытягивается при билде. И никаких проблем E>А в более реальном случае сборки автоматом на CI сервере билдятся, соответвенно тестерам нужно просто проинсталлировать сборку и все. Что там внутри никого не должно волновать.
При фразе "Get latest version" у QA начианет идти пена изо рта.
Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче.
Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Это все правильно, хотя и неприятно.
Гораздо хуже, когда приходится разбираться в коде, к которому нет никакой документации за исключением редких комментариев в коде.
Здравствуйте, karkasch, Вы писали:
K>При фразе "Get latest version" у QA начианет идти пена изо рта. K>Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче. K>Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
Здравствуйте, Lloyd, Вы писали:
L>Может стоит рассказать им о ветках?
Заявки на сборку проекта оформляются в почтовой программе, которая настроена на главную ветку, а та в свою очередь смотрит в оракловую бд, где в таблицах хранится история изменения файлов.
Если создать ветку, то в заявке не подхватится список файлов и не попадет в бд. Нет файлов — нечего собирать.
В нашей программе кодохранилища нет возможности посмореть историю изменения файлов проекта. Поэтому добавили триггеры и отдельную базу данных прилепили.
Здравствуйте, karkasch, Вы писали:
L>>Может стоит рассказать им о ветках?
K>Заявки на сборку проекта оформляются в почтовой программе, которая настроена на главную ветку, а та в свою очередь смотрит в оракловую бд, где в таблицах хранится история изменения файлов. K>Если создать ветку, то в заявке не подхватится список файлов и не попадет в бд. Нет файлов — нечего собирать.
K>В нашей программе кодохранилища нет возможности посмореть историю изменения файлов проекта. Поэтому добавили триггеры и отдельную базу данных прилепили.
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
K>Наш примерно так: K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Здравствуйте, divergo, Вы писали:
D>Гораздо хуже, когда приходится разбираться в коде, к которому нет никакой документации за исключением редких комментариев в коде.
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества. K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
В этом процессе очень нехватает роли Release Engineer — человека, который как раз отвечает за сборки + налаженная CI система. Иначе, судя по вашему описанию, данный процесс однажды может "бабахнуть".
Здравствуйте, karkasch, Вы писали:
K>При фразе "Get latest version" у QA начианет идти пена изо рта. K>Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче. K>Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
Есть такое понятие как билд. Регулярный. То есть заканчивается спринт — делается билд, и он проверяется. Делается бранч, ставится тег. Также есть текущий билд, девелоперская версия — сразу после любого коммита он с небольшой задержкой обновляется, иногда забирают из него. Общее правило коммита — делай что хочешь, главное чтоб собиралось и лругие могли работать. Тестеры оттуда бурут редко.
Если надо что то пофиксить в билде — делается хотфикс в транк и ветку, билд пересобирается, и тег передвигается.
Я вообще не понимаю что значит все в одном файле? У вас что, файлы по 10 тысяч строк чтоль ? Меня уже 500 строк файлы уже напрягают, если что . Рефакторю частенько так, что 100 файлов изменяются, директории создаются и удаляются, а то и вообще из проекта в проект переносится все. Так вот, при таких изменениях надо только предупредить остальных разработчиков что делаешь что то страшное — потому пусть они не синкаются до тех пор, пока я не закончу, либо пусть сразу пообыстрее коммитят свои изменения, а то мержиться им придется. И все — никаких писем, все оперативно.
Здравствуйте, Marduk, Вы писали:
M>В этом процессе очень нехватает роли Release Engineer — человека, который как раз отвечает за сборки + налаженная CI система. Иначе, судя по вашему описанию, данный процесс однажды может "бабахнуть".
Релиз инженера завели. Его задача такая, он приходит и просит выкусить такую то функциональность из проекта, т.к. они решили его пока не включать.
"Бабахает" постоянно. То не то соберут, то не то установят на продакшен.
То их бд глючит. Файлы изменил, а в зявку на сборку они не попадают.
Здравствуйте, jazzer, Вы писали:
J>Это где такое чудо?
Говорить не буду.
Но есть простой способ сюда не попасть:
Приходите на собеседование и первым вопросом спрашивайте, какая у вас система контроля версий.
Если отвечают, что PVCS — просто встаете и уходите.
Здравствуйте, karkasch, Вы писали:
K>"Бабахает" постоянно. То не то соберут, то не то установят на продакшен. K>То их бд глючит. Файлы изменил, а в зявку на сборку они не попадают.
Ты одно скажи — менеджмент там в костюмах ходит, да ? А мож еще и дресскод требуют от сотрудников . Угадал ?
Здравствуйте, karkasch, Вы писали:
L>>Т.е. кодохранилище — это что-то самописное?
K>Нет, это платный продукт, и не дешевый. K>Но такое ощущение, что его писали на коленках.
K>А надстройка над кодохранилищем и хранением измененых файлов в отдельной бд это самопись
Тут сложно что-то по делу сказать. Может быть, что хранилище не поддерживает нормальных вариантов работы. И тогда тот воркфлоу, которы вы описали, для него является единственно возможным.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, karkasch, Вы писали:
E>Я вообще не понимаю что значит все в одном файле? У вас что, файлы по 10 тысяч строк чтоль ? Меня уже 500 строк файлы уже напрягают, если что . Рефакторю частенько так, что 100 файлов изменяются, директории создаются и удаляются, а то и вообще из проекта в проект переносится все. Так вот, при таких изменениях надо только предупредить остальных разработчиков что делаешь что то страшное — потому пусть они не синкаются до тех пор, пока я не закончу, либо пусть сразу пообыстрее коммитят свои изменения, а то мержиться им придется. И все — никаких писем, все оперативно.
Просто в одном файле проще кодить. Чтобы создать новый файл или папку (где красиво и структурировано разложить код), надо писать письмо в QA.
А права на создание тэгов выбивали больше месяца. Они долго упирались. Мол разработчикам не положено.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, karkasch, Вы писали:
K>>"Бабахает" постоянно. То не то соберут, то не то установят на продакшен. K>>То их бд глючит. Файлы изменил, а в зявку на сборку они не попадают. E>Ты одно скажи — менеджмент там в костюмах ходит, да ? А мож еще и дресскод требуют от сотрудников . Угадал ?
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
Я не понял, что делает ваш отдел QA? Какую цель преследует, кроме как создавать папки в репозитории?
По описанию больше похоже на недоразвитый Configuration Management. Или я что-то не так понял?
Попробую ответить на сабжевый вопрос.
Мое прежнее место работы — крупная компания, сертифицированная по CMM-5. Был искусственно созданный отдел QA. Он занимался сбором метрик и последующими ежемесячными попытками синтезировать величину качества разработки с помощью какой-то мощной формулы.
С позиции простого разработчика выглядело так:
1. Коммитишь решение баги в репозиторий
2. Этот коммит анализируется автоматическим ботом
3. Если боту покажется, что что-то не так, то приходит письмо с требованием написать объяснительную
4. Иногда заканчивалось телефонной руганью с девочками из QA, а в основном проблема закрывалась
Естественно, все результаты деятельности QA анализировались руководством и наверное принимались какие-то меры.
