Советы по достижению «непрерывной» доставки

Команда испытывает трудности с выпуском программного обеспечения на частой основе (один раз в неделю). Ниже приводится типичный график выпуска:

Во время итерации:

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

Каждый понедельник:

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

Каждый вторник:

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

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

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

Я думаю, что тестовое покрытие, качество кода, способность к регрессионному тестированию быстро, изменения в последнюю минуту и ​​различия в окружающей среде играют здесь. Кто-нибудь может дать какой-нибудь совет относительно того, как лучше всего добиться "непрерывной" доставки?

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

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

• с энтузиазмом реализованные ветки функций - означает ли это, что некоторое время назад вы также пытались работать над одной веткой и обнаружили, что она уступает? Если да, то пропустите остальное. В противном случае, попробуйте поработать с одной веткой (если необходимо, обратитесь к Google для стратегии ветвления «ветка разработки» или стратегии ветвления «нестабильная ветка » для получения подробной информации). Или, если вы используете Perforce, поищите в Интернете рекомендации Microsoft по ветвлению и слиянию. Попробуй я это сказал? Извините, подходящее слово должно быть проверено : я имею в виду, 1) планировать, когда и как измерить, лучше ли одна ветвь, чем та, что у вас есть сейчас, и 2) планировать, когда и как вы переключитесь обратно на функциональные ветки в случае, если это тестирование не проходит .

PS.

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

Обновить

<копия из комментариев>

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

</ копия из комментариев>

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

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

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

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

Цена, которую вы платите за это счастье, является усложнением исправлений. Это должны быть слияния в двух ветвях вместо одной (релиз + интеграция). Это то, на чем вы должны сосредоточиться при тестировании новой модели. Отслеживайте все, что с этим связано - дополнительные усилия, которые вы тратите на слияние со второй веткой, усилия, связанные с риском, о котором можно забыть, слияние со второй веткой - все, что связано.

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

Update2

<копия из комментариев>

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

</ копия из комментариев>

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

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

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

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

на дальнейшую мысль ...

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

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

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

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

ИМХО график просто чертовски плотный.

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

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

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

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

Почему бы не использовать фактическое непрерывное развертывание, когда фиксация (или push) приводит к выполнению тестов, а если тесты проходят, развертывание происходит?

Затем, если вы не уверены в изменении, вы делаете это в отдельной ветке, что все еще приводит к запуску тестов, но не к развертыванию.

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