Как сохранить устойчивость багажника при длительных испытаниях?

У нас есть три набора тестовых наборов:

• "Небольшой" номер люкс, на запуск которого уходит всего пара часов
• «Средний» номер, который занимает несколько часов, обычно запускается каждую ночь (ночью)
• «Большой» набор, который занимает неделю + для запуска

У нас также есть несколько более коротких тестовых наборов, но я не буду на них останавливаться.

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

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

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

И имеет ли значение, если это централизованная система контроля версий, такая как SVN, или распределенная, как git?

Кстати, я начинающий разработчик с ограниченной способностью что-то менять, я просто пытаюсь понять, есть ли способ справиться с этой болью, которую я испытываю.

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

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

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

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

Я знаю, что вы пытаетесь избежать этого, но реальное понимание здесь заключается в том, чтобы понять, что с вашей базой кодов что-то серьезно не так: вам нужно запустить полный набор тестов, который занимает неделю, чтобы убедиться, что ваш код стабилен!

Самый выгодный способ решить эту проблему - начать разделять вашу кодовую базу и тесты на (независимые) подразделения.
Есть огромные преимущества для этого:

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

С другой стороны, управление вашей структурой VCS станет более сложным, но, по всей видимости, через целую неделю для вашего полного теста, вы можете взять на себя боль!

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

Для SVN я не знаю о такой вещи, как «предварительная фиксация». Я думаю, что это может привести к коммитам и откатам, когда тест не пройден. Как говорит Док-Браун, единственный способ - зафиксировать временную ветку и позже объединить ее с транком.

Использование распределенного типа git или mercurial, я думаю, было бы возможно. Использование «тестирующего» хранилища и «стабильного» хранилища. Вы нажимаете на тестового представителя, тестируете его ночью, и, если все работает нормально, вы переходите от теста к стабильному. В противном случае вы откатываете тестовую репутацию. Я немного не уверен, как будет выглядеть история версий, когда вы переходите от тестирования к стабильной версии, но я думаю, что при этом можно исключить испорченные откатанные вещи. Сначала немного экспериментов будет самым безопасным.

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

ИМХО, это не имеет никакого отношения к VCS, который вы используете. Использование «тестируемой» ветви может быть решением, которое также может быть реализовано с помощью централизованных или распределенных VCS. Но, честно говоря, я думаю, что лучшая вещь в вашей ситуации - это попытка оптимизировать средний набор тестов (кажется, что он содержит самые важные тесты), чтобы он работал намного быстрее, и вы можете использовать его для pre-commit-to-trunk тесты, так же, как вы делаете это сейчас со своим "небольшим набором".

Неудачные средние тесты: правда ли, что в большинстве случаев одни и те же тесты не проходят?

Если есть сбой, всегда ли одни и те же связанные тесты, которые провалились?

Если true: возможно, вы можете выборочно выбрать некоторые средние тесты, которые часто не выполняются (один тест для каждого класса ошибок), и выполнить их в небольшом наборе.

Являются ли большинство тестов интеграционными тестами, которые используют реальную базу данных? Если это так, можно ли заменить их на unittest, у которого есть mocked-база данных?

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

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

Вот что я предлагаю:

1) Сделайте тесты настолько атомарными, насколько это возможно, и максимизируйте повторное использование среды.

2) Получите тестовую ферму для их запуска. Если вместо 8 больших модулей у вас получится 50, вы можете раскрутить кучу спотовых экземпляров Amazon EC2 и запустить весь комплект параллельно. Я уверен, что это будет стоить денег, но сэкономит огромное количество времени на разработку.

Главное, что вы считаете само собой разумеющимся в своем вопросе, это то, что все коммиты должны пройти тесты. Хотя это хорошее правило для подражания и кажется, что оно имеет смысл, иногда оно не практично. Ваш случай является примером (хотя MadKeithV действительно имеет смысл), и я могу представить себе, что держать ветку VCS так, чтобы она могла быть трудной, если нет достаточного сотрудничества между разработчиками.

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

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

Или вы могли бы быть до абсурда упрощенным и иметь скрипт, который перечисляет проходящие коммиты в текстовом файле (который сам может или не может быть управляемым версией).

Или иметь пакетную систему, которая принимает запросы на тестирование ветвей / ревизий (из любого места в дереве), тестирует их и передает их в транк (или другую ветвь), если они проходят.