Сохраняет ли код заморозки при использовании настройки сборки с непрерывной интеграцией?
В прошлом я использовал сервер Continuous Integration с большим успехом, и у меня никогда не было необходимости останавливать код в системе контроля версий.
Однако в последнее время кажется, что куда бы я ни посмотрел, большинство магазинов используют концепцию зависания кода при подготовке к выпуску или даже новой тестовой версии своего продукта. Эта идея работает даже в моем текущем проекте.
Когда вы регистрируетесь рано и часто и используете модульные тесты, интеграционные тесты, приемочные тесты и т. Д., Все еще нужно заморозить код?
5 ответов
Непрерывная интеграция - это "сборка", но это часть программной части цикла разработки. Как и "тесты" в TDD, они являются частью программной части цикла разработки.
Все еще будут сборки и тестирование как часть общего цикла разработки.
Цель непрерывной интеграции и тестирования заключается в сокращении циклов обратной связи и предоставлении программистам большей видимости. В конечном итоге это означает меньше проблем при тестировании и сборке, но это не значит, что вы больше не выполняете первоначальные части цикла разработки - они просто более эффективны и могут быть подняты на более высокий уровень, поскольку возникают более существенные проблемы. поймали ранее в цикле разработки.
Таким образом, вам все равно придется заморозить код (или хотя бы ветвь), чтобы обеспечить исходный уровень того, что вы отправляете, как ожидалось. Тот факт, что кто-то может реализовать что-то с высокой степенью уверенности, не означает, что это входит в ваш выпуск без прохождения тех же самых заключительных циклов, и замораживание кода является важной частью этого.
С CI ваш код может быть очень коротким, так как ваша окончательная сборка, тестирование и выпуск могут быть очень надежными, и замораживание кода может даже не существовать в небольших проектах, так как нет необходимости в ветке - вы выпускаете и возвращаетесь обратно в разработку следующего набора функций очень быстро.
Я также хотел бы добавить, что CI и TDD позволяют завершающей фазе сборки и тестирования вернуться ближе к традиционному водопаду (сделать все dev, выполнить все тестирование, затем выпустить), в отличие от более продолжительного QA, который был сделан на проектах с еженедельной или ежемесячной сборкой. Ваши тестировщики могут использовать сборки CI для получения ранней обратной связи, но это фактически обратная связь другого рода, чем в финальном тестировании, где вы ищете стабильность и надежность в отличие от функциональности (которая, очевидно, была упущена в "тестах" модуля, которые разработчики построили).
Замораживание кода важно, потому что продолжение интеграции не заменяет регрессионное тестирование во время выполнения.
Сборка приложения и прохождение модульного тестирования - это лишь малая часть проблемы, в идеале, когда вы замораживаете код для выпуска, вы подписываетесь на две вещи:
- Этот код был полностью регрессирован и не содержит дефектов
- Этот код является ТОЧНЫМ кодом, который должен быть в производстве (для соответствия SOX).
Если вы используете современный SCM, просто разветвите код в этой точке и начните работу над следующим выпуском в ветке, а затем выполните слияние при развертывании проекта. (Конечно, разместите метку, чтобы вы могли откатить эту точку, если вам нужно применить патч для разрыва).
Когда код находится в "режиме выпуска", его не следует трогать.
Наш типичный процесс:
Development
||
\/
QAT
||
\/
UAT => Freeze until deploy date => Deploy => Merge and repeat
\ /
\- New Branch for future dev -------/
Конечно, у нас обычно есть много параллельных веток во время разработки, которые сливаются обратно в поток релизов до UAT.
Замораживание кода больше связано с QA, чем с Dev. Замораживание кода - это тот момент, когда QA говорит: "Достаточно. У нас есть только пропускная способность, чтобы полностью протестировать новые функции, добавленные до сих пор". Это не значит, что у dev нет пропускной способности, чтобы добавить больше возможностей, просто для того, чтобы QA требовало времени с незаметной базой кода, чтобы все работало вместе.
Если вы все в режиме непрерывной интеграции (включая QA), это может быть просто остановкой на очень короткое время, пока QA ставит окончательную печать одобрения на весь пакет непосредственно перед тем, как он выйдет за дверь.
Все зависит от того, насколько тесно ваши QA и регрессионное тестирование интегрированы в цикл разработки.
Я бы поддержал уже упоминавшиеся голоса о ветвлении SCM и разрешении dev продолжать работу в ветке кода, отличной от той, которую тестирует QA. Все восходит к одному и тому же. QA и регрессионное тестирование нуждаются в постоянной базе кода в течение периода времени до выпуска.
Я думаю, что заморозка кода важна, потому что каждая новая функция является потенциальным новым источником ошибок. Конечно, регрессионные тесты хороши и помогают решить эту проблему. Но замораживание кода позволяет разработчикам сосредоточиться на исправлении существующих в настоящее время ошибок и переводит текущий набор функций в состояние, достойное выпуска.
В лучшем случае, если бы я действительно хотел разработать новый код во время замораживания кода, я бы раскошелил замороженное дерево, выполнил там свою работу, а затем после замораживания слил разветвленное дерево обратно.
Я буду звучать как один из людей, управляемых контекстом, но ответ "это зависит".
Code Freeze - это стратегия для решения проблемы. Если у вас нет проблемы, к которой можно обратиться, то нет, она не нужна. Если у вас есть другой метод решения проблемы, то нет, он не нужен.
Замораживание кода является одним из методов снижения риска. Преимущества, которые приносит, - это стабильность и простота. Недостаток это приносит
Другой метод заключается в использовании ветвления, например, в "Feature Branches". Недостатком ветвления является стоимость работы с ветками, слияния изменений.
Техника, которую вы описываете для снижения риска, - это автоматическое тестирование, которое дает быструю обратную связь. Компромисс здесь - увеличенная скорость для некоторого увеличенного риска (вы пропустите некоторые ошибки).
Из этих подходов я с тобой предпочитаю автоматическое тестирование. Но есть некоторые ситуации, такие как очень высокая стоимость сбоев, когда заморозка кода действительно имеет большую ценность.