Поделитесь опытом, как работает ваш отдел качества.
Наш примерно так:
Группа разработчиков пишет код. По готовности заливает в кодохранилище.
В хранилище есть триггер на заливку. По триггеру в бд Oracle записыватся лог — кто, когда и какой файл правил.
По завершении кодирования, в почтовой программе разработчиком создается заявка на сборку проекта для QA.
По кнопке в заявке из оракловой бд подтягивается список файлов, которые менял разработчик.
По списку файлов из заявки группа QA выкачивает соответствующие версии файлов (не обязательно последние) и компилирует проект для выкладки.
Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что.
Разработчик не имеет права создать папку в кодохранилище. Это надо делать по согласованию.
Т.е. писать код проекта в одном файле проблем в QA нет.
Если на дай бог, создать в коде новый файл или папку. Например папку "Interfaces", то нужно писать расширенное обоснование, зачем была создана эта папка. Или зачем был создан файл "DatabaseManager.cs".
Пишешь письмо в QA:
"Interfaces" — папка с интерфейсами
"DatabaseManager.cs" — файл для работы с базой данных.
Только после такого описания, QA создает папку или файл в кодохранилище.
Или вот создал папку "ReportBuilder". QA пишет, что нет описания, для чего была создана эта папка.
Присылаешь им письмо: ReportBuilder" — это генератор отчетов.
Собственно описание папок и файлов это перевод их название на русский язык.
Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Это все правильно, хотя и неприятно.
Гораздо хуже, когда приходится разбираться в коде, к которому нет никакой документации за исключением редких комментариев в коде.
Здравствуйте, divergo, Вы писали:
D>Гораздо хуже, когда приходится разбираться в коде, к которому нет никакой документации за исключением редких комментариев в коде.
Здравствуйте, jazzer, Вы писали:
J>Это где такое чудо?
Говорить не буду.
Но есть простой способ сюда не попасть:
Приходите на собеседование и первым вопросом спрашивайте, какая у вас система контроля версий.
Если отвечают, что PVCS — просто встаете и уходите.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, karkasch, Вы писали:
B>>>А тестированием у вас кто занимается? K>>Отдел тестирования. CC>Стоп. QA и отдел тестирования это у вас совсем разные отделы? CC>Тогда так: ваш "QA" надобно выгонять полным составом без выходного пособия.
Ну бывают, что QA занимаются больше контролем процессов и в том числе контролем того,
как тестеры работают. Но по описанию топикстартера, QA у них вообще какой странный...
Слишком много на себя берут и больше мешают, чем помогают
Пожалуйста, уважайте коллег и не допускайте излишнего цитирования. Для неуважающих напомню, что есть правила форума и ресурса + санкции за несоблюдение оных. Модератор
K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
какой ужас. Я бы уволилась нахрен в первый день.
Ну ладно, в первый же день начала искать новую работу.
Здравствуйте, karkasch, Вы писали:
K>Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что.
Чет ничего не понял откуда такие проблемы. Есть директория в репозитории, которая содержит исходники, соответственно абсолютно все вытягивается при билде. И никаких проблем
А в более реальном случае сборки автоматом на CI сервере билдятся, соответвенно тестерам нужно просто проинсталлировать сборку и все. Что там внутри никого не должно волновать.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, karkasch, Вы писали:
K>>Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что. E>Чет ничего не понял откуда такие проблемы. Есть директория в репозитории, которая содержит исходники, соответственно абсолютно все вытягивается при билде. И никаких проблем E>А в более реальном случае сборки автоматом на CI сервере билдятся, соответвенно тестерам нужно просто проинсталлировать сборку и все. Что там внутри никого не должно волновать.
При фразе "Get latest version" у QA начианет идти пена изо рта.
Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче.
Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
Здравствуйте, karkasch, Вы писали:
K>При фразе "Get latest version" у QA начианет идти пена изо рта. K>Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче. K>Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
Здравствуйте, Lloyd, Вы писали:
L>Может стоит рассказать им о ветках?
Заявки на сборку проекта оформляются в почтовой программе, которая настроена на главную ветку, а та в свою очередь смотрит в оракловую бд, где в таблицах хранится история изменения файлов.
Если создать ветку, то в заявке не подхватится список файлов и не попадет в бд. Нет файлов — нечего собирать.
В нашей программе кодохранилища нет возможности посмореть историю изменения файлов проекта. Поэтому добавили триггеры и отдельную базу данных прилепили.
Здравствуйте, karkasch, Вы писали:
L>>Может стоит рассказать им о ветках?
K>Заявки на сборку проекта оформляются в почтовой программе, которая настроена на главную ветку, а та в свою очередь смотрит в оракловую бд, где в таблицах хранится история изменения файлов. K>Если создать ветку, то в заявке не подхватится список файлов и не попадет в бд. Нет файлов — нечего собирать.
K>В нашей программе кодохранилища нет возможности посмореть историю изменения файлов проекта. Поэтому добавили триггеры и отдельную базу данных прилепили.
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
K>Наш примерно так: K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества. K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
В этом процессе очень нехватает роли Release Engineer — человека, который как раз отвечает за сборки + налаженная CI система. Иначе, судя по вашему описанию, данный процесс однажды может "бабахнуть".
Здравствуйте, karkasch, Вы писали:
K>При фразе "Get latest version" у QA начианет идти пена изо рта. K>Говорят, что брать все нельзя. А если другой разработчик тоже что то залил в хранилище, но по другой задаче. K>Если заливали разные файлы, то ничего. А если меняли один и тот же файл, фторому разработчику прийдется откатывать свои изменения руками. Т.е. всегда двойная работа. Вначале кодишь, а подом все выкусываешь назад.
Есть такое понятие как билд. Регулярный. То есть заканчивается спринт — делается билд, и он проверяется. Делается бранч, ставится тег. Также есть текущий билд, девелоперская версия — сразу после любого коммита он с небольшой задержкой обновляется, иногда забирают из него. Общее правило коммита — делай что хочешь, главное чтоб собиралось и лругие могли работать. Тестеры оттуда бурут редко.
Если надо что то пофиксить в билде — делается хотфикс в транк и ветку, билд пересобирается, и тег передвигается.
Я вообще не понимаю что значит все в одном файле? У вас что, файлы по 10 тысяч строк чтоль ? Меня уже 500 строк файлы уже напрягают, если что . Рефакторю частенько так, что 100 файлов изменяются, директории создаются и удаляются, а то и вообще из проекта в проект переносится все. Так вот, при таких изменениях надо только предупредить остальных разработчиков что делаешь что то страшное — потому пусть они не синкаются до тех пор, пока я не закончу, либо пусть сразу пообыстрее коммитят свои изменения, а то мержиться им придется. И все — никаких писем, все оперативно.
Здравствуйте, Marduk, Вы писали:
M>В этом процессе очень нехватает роли Release Engineer — человека, который как раз отвечает за сборки + налаженная CI система. Иначе, судя по вашему описанию, данный процесс однажды может "бабахнуть".
Релиз инженера завели. Его задача такая, он приходит и просит выкусить такую то функциональность из проекта, т.к. они решили его пока не включать.
"Бабахает" постоянно. То не то соберут, то не то установят на продакшен.
То их бд глючит. Файлы изменил, а в зявку на сборку они не попадают.
Здравствуйте, 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 анализировались руководством и наверное принимались какие-то меры.
Здравствуйте, karkasch, Вы писали:
K>Просто в одном файле проще кодить. Чтобы создать новый файл или папку (где красиво и структурировано разложить код), надо писать письмо в QA. K>А права на создание тэгов выбивали больше месяца. Они долго упирались. Мол разработчикам не положено.
Ну пусть мегаменеджер теги создает, если ему заняться больше нечем . Делов то.
K>А какая у вас система контроля версий?
SVN, как не странно. Бесплатней некуда . Проблем никаких. Было дело на CVS сидел, тож самое было абсолютно.
Здравствуйте, Mihas, Вы писали:
M>1. Коммитишь решение баги в репозиторий M>2. Этот коммит анализируется автоматическим ботом M>3. Если боту покажется, что что-то не так, то приходит письмо с требованием написать объяснительную
А как бот может понять, что что-то не так? И что именно может быть не так?
Здравствуйте, Панда, Вы писали:
П>Здравствуйте, Mihas, Вы писали:
M>>1. Коммитишь решение баги в репозиторий M>>2. Этот коммит анализируется автоматическим ботом M>>3. Если боту покажется, что что-то не так, то приходит письмо с требованием написать объяснительную
П>А как бот может понять, что что-то не так? И что именно может быть не так?
Из набора метрик вычисляется какая-то цифра. Ну и сравнивается с нормой.
Метрики вроде таких: количество строк кода, сложность бага, время, потраченное на решение и еще целый список неведомых мне критериев.
Если не ошибаюсь, за норму бралось усреднение этой же цифры за предыдущие несколько месяцев.
Естественно, имелась вилка допустимого отклонения от нормы.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Lloyd, Вы писали:
L>>Ты тоже посмотрел его сообщения? E>Не смотрел, честно! Вот именно сейчас посмотрел — угадал однако .
А можно я еще угадаю? (пока другие сообщения не читал)
Это госконтора.
Зарплата у программистов тысяч 20-25.
Работают программистами в основном студенты или люди с невысоким уровнем развития, которых больше никуда не берут.
На жизнь себе зарабатывает госзаказами, или вообще не программированием.
Здравствуйте, karkasch, Вы писали:
K>Группа разработчиков пишет код. По готовности заливает в кодохранилище. K>В хранилище есть триггер на заливку. По триггеру в бд Oracle записыватся лог — кто, когда и какой файл правил.
Нафига? Онож всё в SVN есть в любой момент.
Или у вас "кодохранилище" какое то особое.
K>По завершении кодирования, в почтовой программе разработчиком создается заявка на сборку проекта для QA. K>По кнопке в заявке из оракловой бд подтягивается список файлов, которые менял разработчик.
K>По списку файлов из заявки группа QA выкачивает соответствующие версии файлов (не обязательно последние) и компилирует проект для выкладки. K>Если над проектом работают несколько разработчиков, то создавать заявки надо всем. Что бы QA подхватили все файлы. Иначе они соберут непонятно что. Автоматизация просто капец. Нафига оно такое надо если самостоятельно собрать не может?
K>Разработчик не имеет права создать папку в кодохранилище. Это надо делать по согласованию. K>Т.е. писать код проекта в одном файле проблем в QA нет. K>Если на дай бог, создать в коде новый файл или папку. Например папку "Interfaces", то нужно писать расширенное обоснование, зачем была создана эта папка. Или зачем был создан файл "DatabaseManager.cs".
Дурдом!!!
K>Пишешь письмо в QA: K>"Interfaces" — папка с интерфейсами K>"DatabaseManager.cs" — файл для работы с базой данных.
Какое вообще дело QA какой и для чего файл в сурсах. Их дело заниматься скомпиленным продуктом.
K>Только после такого описания, QA создает папку или файл в кодохранилище. K>Или вот создал папку "ReportBuilder". QA пишет, что нет описания, для чего была создана эта папка. K>Присылаешь им письмо: ReportBuilder" — это генератор отчетов. K>Собственно описание папок и файлов это перевод их название на русский язык.
У автора этой системы в голове больки.
K>Надеюсь, не надо объяснять, как я офигеваю от такого процесса.
Объясни, что тебя там держит?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, karkasch, Вы писали:
K>>>"Бабахает" постоянно. То не то соберут, то не то установят на продакшен. K>>>То их бд глючит. Файлы изменил, а в зявку на сборку они не попадают. E>>Ты одно скажи — менеджмент там в костюмах ходит, да ? А мож еще и дресскод требуют от сотрудников . Угадал ? K>В точку! K>За волосатые ноги публично высмеивают.
Вали оттуда срочно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
K>Наш примерно так:
K>Группа разработчиков пишет код. По готовности заливает в кодохранилище.
_>А можно я еще угадаю? (пока другие сообщения не читал) _>Это госконтора. _>Зарплата у программистов тысяч 20-25. _>Работают программистами в основном студенты или люди с невысоким уровнем развития, которых больше никуда не берут. _>На жизнь себе зарабатывает госзаказами, или вообще не программированием.
а кто тогда этот бот, который коммитты проверяет? лично Путин??
Здравствуйте, karkasch, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>Это где такое чудо?
K>Говорить не буду. K>Но есть простой способ сюда не попасть: K>Приходите на собеседование и первым вопросом спрашивайте, какая у вас система контроля версий. K>Если отвечают, что PVCS — просто встаете и уходите.
Здравствуйте, antonio_banderas, Вы писали:
_>Здравствуйте, elmal, Вы писали:
E>>Здравствуйте, Lloyd, Вы писали:
L>>>Ты тоже посмотрел его сообщения? E>>Не смотрел, честно! Вот именно сейчас посмотрел — угадал однако .
_>А можно я еще угадаю? (пока другие сообщения не читал) _>Это госконтора. _>Зарплата у программистов тысяч 20-25. _>Работают программистами в основном студенты или люди с невысоким уровнем развития, которых больше никуда не берут. _>На жизнь себе зарабатывает госзаказами, или вообще не программированием.
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
Раз или два в неделю отправляется заявка на сборку очередной версии. Товарищ ответственный за сборку забирает исходники из нужной ветки, собирает, прогоняет автоматические тесты, передает собранную версию в QA. Там билд устанавливается, прогоняются в разных режимах автотесты связанные с GUI и еще что-нибудь. "Вручную и глазами" проверяются в основном исправления ошибок, новая функциональность и делается общий обзор — что все на месте и в порядке. Автотестами покрыта довольно большая часть продукта и постоянно добавляются новые, чтобы с одной стороны все было каждый раз проверено и перепроверено, но и чтобы у людей глаз не замыливался.
Исправленные ошибки закрываются в багтрекере, новые добавляются.
Также разработчик может при необходимости заказать отдельное тестирование своей ветки, например если добавляется что-то важное или потенциально стремное перед вливкой своих изменений в общий котел. Иногда практикуется предварительное тестирование по отделам, когда перед общей сборкой разработчики в каждой группе сливают плоды трудов и делают запрос на сборку и автотесты, живых инженеров из QA для предварительного тестирования редко дергают. Все это не отменяет самопроверки и хорошим тоном считается ревью (пользуемся code collaborator, удобная штука)
Такая 2-3 ступенчатая система позволяет отлавливать на ранней стадии большинство ошибок. Особенно связанных с компиляцией, когда у разработчика по каким-то причинам отличаются настройки компиляции/линковки от сборочных машин или нет времени/возможности самому собрать и погонять изменения на всех платформах. Благодаря этому ситуаций, когда из-за какой-нибудь фигни не собирается регулярный билд или не на нем проходят автотесты, практически нет.
Здравствуйте, CreatorCray, Вы писали:
CC>Нафига? Онож всё в SVN есть в любой момент. CC>Или у вас "кодохранилище" какое то особое.
Особое. Которому до SVN очень далеко.
CC> Автоматизация просто капец. Нафига оно такое надо если самостоятельно собрать не может?
На любой вопрос почему так, QA говорит, что так качественно.
CC>Какое вообще дело QA какой и для чего файл в сурсах. Их дело заниматься скомпиленным продуктом.
Они объясняют это тем, что они следян за качеством.
CC>У автора этой системы в голове больки.
CC>Объясни, что тебя там держит?
Ничего.
Здравствуйте, pon4ik, Вы писали:
P>Такая 2-3 ступенчатая система позволяет отлавливать на ранней стадии большинство ошибок. Особенно связанных с компиляцией, когда у разработчика по каким-то причинам отличаются настройки компиляции/линковки от сборочных машин или нет времени/возможности самому собрать и погонять изменения на всех платформах. Благодаря этому ситуаций, когда из-за какой-нибудь фигни не собирается регулярный билд или не на нем проходят автотесты, практически нет.
Спасибо!
А можете про инструменты сказать? На чем пишете, чем пользуетесь?
Багтрекер, репозиторий, автотесты, CI сервер?
Здравствуйте, karkasch, Вы писали:
CC>> Автоматизация просто капец. Нафига оно такое надо если самостоятельно собрать не может? K>На любой вопрос почему так, QA говорит, что так качественно.
Ну дык, ручная работа как никак. Бездушная железяка так не сможет.
Здравствуйте, karkasch, Вы писали:
CC>>Нафига? Онож всё в SVN есть в любой момент. CC>>Или у вас "кодохранилище" какое то особое. K>Особое. Которому до SVN очень далеко.
CC>> Автоматизация просто капец. Нафига оно такое надо если самостоятельно собрать не может? K>На любой вопрос почему так, QA говорит, что так качественно.
Разгонять эту мафию надо.
Их работа проверять качество конечного продукта.
Лезть в процесс разработки они вообще никакого права не имеют.
Как организованы исходники их вообще не касается и к их работе отношения не имеет.
CC>>Какое вообще дело QA какой и для чего файл в сурсах. Их дело заниматься скомпиленным продуктом. K>Они объясняют это тем, что они следян за качеством.
Это имитация бурной деятельности граничащая с вредительством а не QA.
CC>>Объясни, что тебя там держит? K>Ничего.
Тогда надо бы задуматься о смене работодателя.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, karkasch, Вы писали:
B>>А тестированием у вас кто занимается? K>Отдел тестирования.
Стоп. QA и отдел тестирования это у вас совсем разные отделы?
Тогда так: ваш "QA" надобно выгонять полным составом без выходного пособия.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Любой check-in вывывает автосборку изменяемого компонента, дальше по дереву зависимостей пересобираются вышестоящие компоненты... Каждой сборке компоненты проставляется версия. Тестлаб получает уже собранную версию (пакет), который точно так же собирается автоматом... и тестлаб к исходникам отношения не имеет. Собранные либы, приложения и пакеты сладывается в репозитарий, которые используются при разработке и автосборке в уже собранном виде. Есть специальный человек (хотя каждый разработчик должен со временем научистя), который занимается скриптами автосборки и правками под конкретный компилятор, архитектуру и платформу...
Зачем иметь специальных людей для сборки, а уж целый отдел — если все автоматизируется и участие людей в этом не требуется?
Здравствуйте, karkasch, Вы писали:
K>Поделитесь опытом, как работает ваш отдел качества.
Да очень просто. Делается проект, потом ручками выкладывается периодически на отдельные серваки для девелопмента и QA. Тестеры жмут кнопки и пишут багрепорты. Процесс итерируется.
K>Наш примерно так:
Офигел, если честно. QA собирает проект и лезет в код....
