Сохраняются ли какие-либо ограничения кода при использовании непрерывной интеграции?

Question

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

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

Когда вы регистрируетесь раньше и часто, и используете модульные тесты, интеграционные тесты, приемочные испытания и т. Д., Еще нужны заморозки кода?

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

Конечно, мы, как правило, имеют много параллельных ветвей в процессе разработки, которые сливаются обратно в поток выпуска до ЕСХН.

Answer 3

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

Все еще будут сборки и испытания в рамках общего цикла разработки.

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Другой метод - использовать ветвление, например, с «Вложениями функций». Недостатком Branching является стоимость работы с филиалами, слияния изменений.

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

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