Замораживание кода по-прежнему актуально при использовании настройки сборки с непрерывной интеграцией?

Question

В прошлом я с большим успехом использовал сервер Continuous Integration, и у меня не было необходимости когда-либо останавливать код в системе контроля версий.

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

Когда вы регистрируетесь рано и часто и используете модульные тесты, интеграционные тесты, приемочные тесты и т. Д., Все еще необходимо заморозить код?

Answer 1

Непрерывная интеграция - это «сборка», но это часть программной части цикла разработки. Так же, как «тесты» в TDD являются частью программной части цикла разработки.

Все еще будут сборки и тестирование как часть общего цикла разработки.

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

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

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

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

Answer 2

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

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

• Этот код был полностью регрессирован и не содержит дефектов
• Этот код является ТОЧНЫМ кодом, который должен быть в производстве (для соответствия SOX).

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

Когда код находится в «режиме выпуска», к нему не следует прикасаться.

Наш типичный процесс:

Development
   ||
   \/
   QAT 
   ||
   \/
   UAT => Freeze until deploy date => Deploy  => Merge and repeat
            \                                     /
             \- New Branch for future dev -------/

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

Answer 3

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

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

Все зависит от того, насколько тесно ваши QA и регрессионное тестирование интегрированы в цикл разработки.

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

Answer 4

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

Code Freeze - это стратегия для решения проблемы. Если у вас нет проблемы, к которой можно обратиться, то нет, она не нужна. Если у вас есть другой метод решения проблемы, то нет, он не нужен.

Замораживание кода - это один из методов снижения риска. Преимущества, которые приносит, - это стабильность и простота. Недостаток, который это приносит,

Другой метод заключается в использовании ветвления, например, в «Feature Branches». Недостатком ветвления является стоимость работы с ветками, слияния изменений.

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

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

Answer 5

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

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