Случайно выпущенный код для жизни. Как предотвратить повторение?

Question

Недавно у нас произошел инцидент, когда был выпущен какой-то код, который не планировалось выпустить.

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

Однако в этом случае он не должен был быть выпущен в следующем выпуске.

Какой тип проверок / стратегии / процесса можно внедрить, чтобы избежать преждевременного выпуска кода.

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

- Ли

Answer 1

Изменить ваши процедуры интеграции.

Если «запуск в эксплуатацию» означает, что кто-то выполняет какой-то пакетный скрипт - не удивляйтесь, если это произойдет снова.

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

Эта ветвь перед развертыванием в рабочей среде должна быть тщательно протестирована.

Answer 2

У вас должны быть разные ветки, если ваше ПО для управления исходным кодом допускает такую ​​вещь.

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

---

UPDATE: Руководство по ветвлению TFS 2008 2.0 предназначено для конкретного продукта, но содержит множество рекомендаций, которые можно применять к другим программам управления версиями, которые могут создавать ветки.

Answer 3

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

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

Answer 4

Мне кажется, даже с Continuous Интеграция и модульные тесты это человеческий вопрос?

В самом деле! Однако вы должны иметь возможность получить некоторую поддержку от вашей инфраструктуры для поддержки человеческой стороны вашего процесса. Когда вы собираетесь выпустить релиз, вы сможете легко увидеть все коммиты, которые будут его частью, и все связанные с этим проблемы. Это отчетная сторона непрерывной интеграции. (Я бы сказал, что четыре элемента (pdf): создание, развертывание, тестирование и создание отчетов.)

Answer 5

Чтобы продолжить обсуждение ветвления, это способ сохранить структурированную обработку версий.

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

Answer 6

Проблема, очевидно, не в проверке кода в хранилище. У вас есть две проблемы здесь:

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

2) Кто такой дебил, который в любом случае запускает непроверенный код? Существует серьезная нехватка связи, если человек, который его запустил, подумал, что ваш код в разработке готов к работе.

Answer 7

Мы создали менеджер релизов, который работает с Subversion. www.ReleaseManager.com Таким образом, мы можем контролировать то, что выпущено по номеру проблемы (или номеру ошибки), и у нас есть контроль, чтобы мы могли извлекать вещи из релиза, когда это необходимо. Сейчас ищем бета-сайты:)

Answer 8

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

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

Позвольте разработчикам регистрироваться рано и часто в своих ветвях функций и объединять их в магистраль, когда придет время.