Процесс развертывания гибкой разработки. Где тестирование QA и владельцев бизнеса?

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

Как и во многих вариантах Agile, предполагается, что все, что предназначено для мастера или магистрали, готово к производству. И GitHub, и Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/, говорят, что они работают на этой основе (хотя Etsy на самом деле имеет промежуточную среду).

Этот процесс предполагает, что все юнит-тесты и тесты CI были выполнены. Вы запускаете тесты локально и на CI, а затем фиксируете транк. Итак, на данный момент ваш код технически исправен.

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

У меня вопрос такой. Где владельцы QA и Business тестируют внесенные вами изменения в функции? На вашей локальной машине для разработки, прежде чем выполнять коммит на транк, или на машине QA / staging?

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

Мне было бы интересно услышать, как другие подошли к этому?

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

Я видел, что это было сделано как с разработкой на "main" с отдельной "развернутой" веткой, так и с веткой "feature" разработки с main как "развернутая".

рабочий процесс выглядит примерно так:

• код что-то
• запустить локальные тесты
• зарегистрируйтесь в рабочую ветку
• (необязательно) сервер сборки строит тесты муравья
• QA / Бизнес тестирование
• исправления ошибок (возврат к началу)
• объединить для развертывания филиала
• развернуть

Некоторые люди работают из одной ветки, но если вам нужно пройти ручное тестирование, это будет сложно. Большинство людей, с которыми мне приходилось сталкиваться, работают в предположении, что при коммите можно развернуть что-либо, что также работает из одного транка, что-то делают мало или имеют ОГРОМНОЕ количество автоматизированного тестирования, ИЛИ считают, что «развертывание» в этом разговоре быть сборкой для тестирующего сервера, и процесс обеспечения качества, который происходит между тестирующим сервером и производством, обрабатывается отдельно.

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

Подробнее об этом процессе здесь:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Проверьте комментарии также.

Надеюсь это поможет,

Адам

Как правило, ожидание коммита до того, как код станет идеальным, наполовину уменьшает преимущества системы контроля версий. (Не вдаваясь в подробности, я бы сказал, что, если не разрешить многократную регистрацию в VCS, никто не сможет отменить мою собственную работу!) Поэтому в качестве практики мы всегда просим людей сохранять регистрацию (в пределах своей ветки для SVN). или это могут быть локальные коммиты в случае GIT) столько, сколько они хотят. На самом деле, чем больше, тем лучше.

Однако, когда наступает момент, когда кажется, что все сделано и проверено - мы называем это релизом, а затем оно объединяется с транком. По сути, QA может сертифицировать RC, выполнив новую проверку HEADветки, и если он / она согласен, то же самое произойдет слияние со стволом.

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