в производстве обнаружены «тонкие» ошибки, которые не были идентифицированы в промежуточной среде - в одном из проектов с такими проблемами, которые я видел, это было довольно успешно решено с помощью тактики, которую я бы назвал двойной проблемой. Я имею в виду, что для таких ошибок парни создали два тикета в трекере: один был назначен разработчикам для исправления кода, другой - тестерам для разработки и создания регрессионного теста или изменения в промежуточной среде, что предотвратит повторение этого в будущем. Это помогло держаться достаточно близко, чтобы подталкивать.
проблемы в производственной среде требуют отката - если они частые, то ваши еженедельные выпуски на самом деле являются фальшивыми - рассмотрите возможность корректировки частоты до уровня, который действительно работает. Под фальшивкой я подразумеваю, что если произойдет откат одного из двух ваших еженедельных выпусков, это означает, что пользователи сталкиваются с новым (рабочим) выпуском раз в две недели - это все, что имеет значение, а не количество раз, которое вы развернули.
с энтузиазмом реализованные ветки функций - означает ли это, что некоторое время назад вы также пытались работать над одной веткой и обнаружили, что она уступает? Если да, то пропустите остальное. В противном случае, попробуйте поработать с одной веткой (если необходимо, обратитесь к Google для стратегии ветвления «ветка разработки» или стратегии ветвления «нестабильная ветка » для получения подробной информации). Или, если вы используете Perforce, поищите в Интернете рекомендации Microsoft по ветвлению и слиянию. Попробуй я это сказал? Извините, подходящее слово должно быть проверено : я имею в виду, 1) планировать, когда и как измерить, лучше ли одна ветвь, чем та, что у вас есть сейчас, и 2) планировать, когда и как вы переключитесь обратно на функциональные ветки в случае, если это тестирование не проходит .
PS.
Вероятно, вы можете найти больше подобных трюков, если будете искать в Интернете что-то вроде управления рисками программных проектов.
Обновить
<копия из комментариев>
Я воспринимаю частые исправления как признак поломки тестового конвейера - разве это не так? В любом случае, они требуют многократных выпусков, чтобы выпустить оперативные исправления и сделать больше работы для оперативной команды. Кроме того, исправления, как правило, кодируются в условиях экстремального времени, что означает, что они, вероятно, будут более низкого качества, чем обычная работа.
</ копия из комментариев>
- горячие исправления в последнюю минуту - вышеупомянутые проблемы выглядят для меня разумными, так же как и ваша ссылка на прерванный тестовый конвейер. С этим обновлением ваше предыдущее замечание о том, что интеграция нового кода заблокирована в понедельник, звучит как еще один признак сломанного (я думаю, более точное слово будет утверждаться ) конвейера. Под соглашением я имею в виду следующее: вы используете одну ветвь для одновременного использования в двух целях: интеграция и выпуск. Когда релиз приближается, эти две цели начинают конфликтовать друг с другом, выдвигая противоречивые требования: цель интеграции лучше всего обслуживать с постоянно открытой ветвью ( объединение рано и часто ), в то время как стабильность релиза выигрывает от запечатывания ветвления.(изолированные) как можно дольше. А-ха, похоже, части головоломки начинают совпадать ...
..Посмотрите, что замораживание в понедельник теперь выглядит как компромисс для противоречивых целей: разработчики страдают от блока интеграции нового кода, в то время как тестеры страдают от того, что этот блок слишком короткий, все недовольны, но обе цели выполняются более или менее.
Вы знаете, учитывая вышеизложенное, я думаю, что вам лучше всего попытаться выпустить из специальной ветки (кроме интеграции) . Будет ли эта ветка долгоживущей, как интеграция, или недолговечной, как ваши ветки функций (с «функциональностью», ну, в общем, релизом) - решать вам, просто нужно быть отдельным.
Просто подумай об этом. В настоящее время вы находите, что одного дня недостаточно, чтобы удобно стабилизировать выпуск, верно? с новой стратегией ветвления вы можете просто разветвляться за 2 дня до релиза вместо одного, без проблем. Если вы обнаружите, что даже двух дней недостаточно, попробуйте разветвиться за 3 дня и т. Д. Дело в том, что вы можете изолировать ветку релиза так рано, как захотите, потому что это больше не будет препятствовать слиянию нового кода с веткой интеграции. Обратите внимание, что в этой модели нет нужды замораживать интеграционную ветвь - ваши разработчики могут постоянно использовать ее, в понедельник, вторник, пятницу, что угодно.
Цена, которую вы платите за это счастье, является усложнением исправлений. Это должны быть слияния в двух ветвях вместо одной (релиз + интеграция). Это то, на чем вы должны сосредоточиться при тестировании новой модели. Отслеживайте все, что с этим связано - дополнительные усилия, которые вы тратите на слияние со второй веткой, усилия, связанные с риском, о котором можно забыть, слияние со второй веткой - все, что связано.
В конце тестирования просто соберите то, что вы отслеживали, и узнайте, приемлемо ли количество этих дополнительных усилий или нет. Если это приемлемо, все готово. В противном случае вернитесь к своей текущей модели, проанализируйте, что пошло не так, и начните думать о том, как еще можно улучшить.
Update2
<копия из комментариев>
Моя цель состоит в том, чтобы тестировать и доставлять истории (за или за стеной конфигурации) в течение итерации, это может быть достигнуто только в том случае, если тестировщики тестируют работу, выполненную в итерации (а не стабилизируя код из предыдущей итерации).
</ копия из комментариев>
Понимаю. Ну, у меня нет прямого опыта с этим, но я видел, что итеративное тестирование было успешно выполнено в проекте, связанном с нашим. Поскольку наш проект шел по противоположному пути, у меня также была роскошь сравнения лицом к лицу для этих противоположных подходов.
С моей точки зрения, подход вне тестирования итераций выглядел лучше в этой гонке. Да, их проект прошел хорошо, и их тестеры обнаружили ошибки быстрее, чем у нас, но почему-то это не помогло. Наш проект тоже прошел нормально, и почему-то мы могли позволить себе более короткие итерации, чем они, и у нас было меньше (намного меньше) выпусков с проскальзыванием, чем их, и было меньше напряженности между разработчиками и разработчиками на нашей стороне.
Кстати, несмотря на более быстрое обнаружение с их стороны, нам удалось получить примерно одинаковую среднюю продолжительность жизни ошибки (срок службы - время между внедрением и исправлением , а не между введением и обнаружением). Вероятно, у нас даже было небольшое преимущество, поскольку с более короткими итерациями и менее проскальзывающими выпусками мы могли утверждать, что в среднем наши исправления достигают пользователей быстрее, чем их.
Подводя итог, я все еще верю, что изоляция кода выпуска имеет больше шансов повысить производительность вашей команды.
на дальнейшую мысль ...
- изоляция кодовой строки релиза имеет больше шансов - после перечитывания у меня может сложиться впечатление, что я отговариваю вас от попыток итеративного тестирования. Я хотел бы прояснить, что я не делаю.
В вашем случае подход к итеративному тестированию выглядит безопасным (э-э ... тестировать ), потому что у вас, кажется, есть четкое понимание того, как его достичь (плавный конвейер тестирования ) и каковы основные препятствия. И в конце концов, у вас всегда есть возможность вернуться к альтернативному подходу, если вам слишком сложно правильно настроить этот конвейер.
Кстати, о препятствиях, дополнительные, которые стоит отслеживать в этом случае, будут такими, как неспособность воспроизвести ошибку на стороне разработчика и позднее обнаружение / задержка для проверки исправления на стороне тестеров. Они также могут застрять в вашем конвейере , как это происходит сейчас с исправлениями.