Стратегия ветвления Git интегрирована с процессом тестирования / контроля качества

Мы делаем это следующим образом:

Мы тестируем ветки функций после того, как объединим с ними последний код ветки разработки. Основная причина в том, что мы не хотим «загрязнять» код ветки разработки до того, как функция будет принята. Если функция не будет принята после тестирования, но мы хотели бы выпустить другие функции, уже объединенные при разработке, это было бы адом. Разработка - это ветка, из которой создается релиз, и поэтому лучше быть в готовом к выпуску состоянии. Длинная версия состоит в том, что мы тестируем в несколько этапов. Более аналитически:

1. Разработчик создает ветку для каждой новой функции.
2. Ветка функций (автоматически) развертывается в нашей тестовой среде с каждой фиксацией для тестирования разработчиком.
3. Когда разработчик завершил развертывание и функция готова к тестированию, он объединяет ветвь разработки с ветвью функции и развертывает ветвь функции, которая содержит все последние изменения разработки в тесте.
4. Тестер тестирует на ТЕСТ. Когда он закончил, он «принимает» историю и объединяет функциональную ветку при разработке. Поскольку разработчик ранее объединил ветвь разработки для функции, мы обычно не ожидаем слишком большого количества конфликтов. Однако в этом случае разработчик может помочь. Это сложный шаг, я думаю, что лучший способ избежать этого - сделать функции как можно более мелкими / конкретными. В конечном итоге, так или иначе, необходимо объединить разные функции. Конечно, размер команды влияет на сложность этого шага.
5. Ветка разработки также (автоматически) развертывается на TEST. У нас есть политика, согласно которой, несмотря на то, что сборки ветки функций могут давать сбой, ветка разработки никогда не должна выходить из строя.
6. Как только мы достигли замораживания функций, мы создаем выпуск из develop. Это автоматически развертывается на ЭТАПЕ. Перед развертыванием в производственной среде там проводятся обширные сквозные тесты. (ладно, может быть, я немного преувеличиваю, они не очень обширны, но я думаю, что они должны быть). В идеале там должны тестировать бета-тестеры / коллеги, то есть реальные пользователи.

Что вы думаете об этом подходе?

Перед тестированием мы объединяем изменения из ветки разработки в ветку функций.

Нет. Не надо, особенно если «мы» - тестировщик качества. Слияние будет включать разрешение потенциальных конфликтов, что лучше всего делать разработчикам (они знают свой код), а не тестировщику QA (который должен приступить к тестированию как можно быстрее).

Заставьте разработчика выполнить перебазирование его / ее feature ветки поверх devel и подтолкнуть эту feature ветку (которая была подтверждена разработчиком как компилирующая и работающая поверх последнего состояния ветки devel).
Это позволяет:

• очень простая интеграция в функциональную ветку (тривиальное слияние с быстрой перемоткой вперед).
• или, как рекомендовано Aspasia ниже в комментариях запрос на вытягивание (GitHub) или запрос на слияние (GitLab): сопровождающий выполняет слияние между ветвью PR / MR функции и develop, но только если конфликт не обнаружен GitHub / GitLab.

Каждый раз, когда тестировщик обнаруживает ошибку, он / она сообщает об этом разработчику и удаляет текущую ветку функции.
Разработчик может:

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

Общая идея: убедитесь, что часть слияния / интеграции выполняется разработчиком, оставив тестирование QA.

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

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

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

Для получения дополнительной информации перейдите по этой ссылке.

Мы используем то, что мы называем «золотом», «серебром» и «бронзой». Это можно назвать prod, staging и qa.

Я назвал это моделью плавильного котла. Это хорошо работает для нас, потому что у нас есть огромная потребность в QA с точки зрения бизнеса, поскольку требования могут быть трудными для понимания по сравнению с техническими аспектами.

Когда ошибка или функция готовы к тестированию, они переходят в «бронзу». Это запускает сборку jenkins, которая помещает код в предварительно созданную среду. Наши тестировщики (кстати, не супертехнологи) просто нажимают на ссылку и не заботятся о системе контроля версий. Эта сборка также запускает тесты и т. Д. Мы ходили туда и сюда по этой сборке, фактически отправляя код в среду тестирования \ qa, если тесты (модульные, интеграционные, селеновые) терпят неудачу. Если вы тестируете отдельную систему (мы называем ее ведущей), вы можете предотвратить внесение изменений в среду qa.

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

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

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

Экстренные исправления добавляются прямо в золотое дерево. Если изменение является простым и сложным для QA, оно может перейти непосредственно в серебро, которое попадет в дерево тестирования.

После нашего выпуска мы переводим изменения с золота (prod) в бронзу (тестирование), чтобы все было синхронизировано.

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

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

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

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

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

Наш подход к работе с GIT таков;

Мы внедрили Git Flow в нашей компании. Мы используем JIRA, и в производство должны поступать только утвержденные билеты JIRA. Для утверждения Test мы расширили его, создав отдельную Test-Branch.

Шаги по обработке заявок JIRA:

1. Создайте новую ветку из Develop-Branch
2. Внесите изменения кода в Feature-Branch
3. Извлеките из Feature изменения в ветку Test / QA
4. После утверждения бизнеса мы переносим изменение из функциональной ветки в разработку.
5. Разработка часто идет в выпуске, а затем, наконец, в основной ветке

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

Полный процесс выглядит следующим образом:

Я бы не стал полагаться только на ручное тестирование. Я бы автоматизировал тестирование каждой функциональной ветки с помощью Jenkins. Я настраиваю лабораторию VMWare для запуска тестов Jenkins в Linux и Windows для всех браузеров. Это действительно отличное решение для кроссбраузерного тестирования и кросс-платформенного тестирования. Тестирую функционал / интеграцию с Selenium Webdriver. Мои тесты на селен выполняются под Rspec. И я написал их специально для загрузки jRuby в Windows. Я запускаю традиционные модульные тесты под Rspec и тесты Javascript под Jasmine. Я настраиваю безголовое тестирование с помощью Phantom JS.