Использование веток тестирования в Git

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

Мы используем Git и GitHub . masterдолжен быть / всегда доступен для развертывания и developmentгде мы фиксируем / объединяем новые функции или исправления ошибок, но только после того, как они были проверены Тедом.

Проект на PHP.

Я бы хотел, чтобы процесс тестирования проходил так:

1. Разработчик хочет работать на новую функции (скажем , в особенности / ошибке # 123 , как Тед задокументированной в системе отслеживания проблем), так что он тянет origin/developmentк developmentего локальному хранилищу , и создает новую ветвь (скажем issue-123) оттуда.
2. Как только он доволен своей работой, он берет на себя обязательства и продвигает свою новую ветку origin.
3. Тед подключается test.ourproject.com/choose-branchи видит список ветвей originи выбирает для включения issue-123(это должно быть сделано через веб-страницу). Затем он продолжает test.ourproject.com, тестирует адское веб-приложение (он действительно безжалостен), и после некоторой перемотки с разработчиком он доволен этой функцией.
4. Тед говорит разработчик , что он может сливаться issue-123на developmentна origin.
5. Промыть и повторить.

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

Итак, мой вопрос: это хороший / устойчивый / поддерживаемый рабочий процесс для ветвления? Можете ли вы подтвердить свой ответ, приведя несколько примеров других проектов после этого рабочего процесса?

Рабочий процесс ветки очень похож на gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow, и вокруг него есть инструменты поддержки. Настоятельно рекомендуется.

Если есть только один тестер, ваш рабочий процесс тестирования звучит нормально, но если есть несколько человек, то разработка может перейти от начала до конца, и, конечно, в идеале тестирование должно быть полностью выполнено после любого слияния. Вот где может помочь автоматизированное тестирование, иначе медленный (тщательный) тестер может никогда не закончить!

Другая проблема состоит в том, что со многими функциями и ветвями становится заманчивым смешивать и сопоставлять функции в выпуске (или выбирать, чтобы исключить их после принятия и слияния) или, возможно, если функции зависят друг от друга. Проблема заключается в том, что вы начинаете испытывать желание переписать историю (перебазировать / удалить коммит или объединить) на ОПУБЛИКОВАННУЮ ветвь, означающую ветку, которая была перенесена в репозиторий multidev. Это переписывание публичной истории. Это может быть сделано во благо или во зло, и даже если оно сделано во благо, это может вызвать проблемы у неосторожных, и лучшая практика - избегать этого, чтобы этот вопрос никогда не возникал. Однако некоторые рабочие процессы веток интеграции делают это очень заманчивым, поэтому, если у вас есть надежная защита в таких ветвях (например, gitolite для ограничений веток пользователей), и люди ожидают такой активности, поэтому всегда перебазируйте свой код в такой ветке, действуйте - осторожно!

Я также хотел бы рекомендовать прочитать http://sethrobertson.github.com/GitBestPractices/, где обсуждаются все эти вопросы и есть много хороших ссылок.

Я не уверен, что страница переключения сама по себе является общим шаблоном. Большинство проектов, вероятно, просто проверяют тестером команду git.

Общий подход определенно звучит разумно.

Google даже написал Gerrit для поддержки подобного стиля; это больше о проверке кода, но утверждение интеграции обычно включает в себя как проверку, так и тестирование. Обычно он также связан с сервером непрерывной интеграции, который сначала строит все представления (я не уверен, используют ли они Дженкинса в Google, но я думаю, что где-то видел подходящие коннекторы).

Сам Git использует небольшую вариацию темы. Его сопровождающий имеет скрипт, который объединяет все ожидающие представления в вызываемую ветвь pu(вероятно, для «предлагаемых обновлений»; ветвь удаляется и воссоздается каждый раз, поскольку ожидающие представления часто перебазируются). Это проверено разными людьми. Если это нормально, то заявки, которые считаются завершенными, объединяются next(это то же самое, что и ваша development). Если нет, то кто-то проверяет отдельные представления, чтобы увидеть, какая из них нарушена. Это немного облегчает работу тестировщика, так как большую часть времени ему не нужно переключать ветви; они просто сообщают, работает ли тестовая интеграция.

Если ваше тестирование выполняется автоматически, а не вручную, я думаю, что Travis (система CI для GitHub) в значительной степени будет делать то, что вы хотите - он автоматически запускает тесты для всех запросов на извлечение. ( Подробнее об этом процессе, включая скриншоты. )

Обратите внимание, что тесты запускаются не в ветви, а в ветви после ее слияния с master. (то есть то, что вы получите после слияния ветки с master - вы гарантированно будете успешно выполнять тесты после слияния.)

Если коммиты добавляются в ветку, тесты перезапускаются. (Хотя по какой-то причине добавление коммитов к мастеру, похоже, не запускает тесты заново.)