Случайно выпущенный код для проживания. Как предотвратить случай снова?
Это охвачено в Главе 5 (Дженерики) Эффективный Java, 2-й Выпуск , объект 25... Предпочитают списки массивам
, Ваш код будет работать, хотя он генерирует предупреждение непроверенное (который Вы могли подавить со следующей аннотацией:
@SuppressWarnings({"unchecked"})
Однако, вероятно, было бы лучше использовать Список вместо Массива.
существует интересное обсуждение этой ошибки/функции на стройплощадка OpenJDK .
8 ответов
Внесите изменения в процедуры интеграции.
Если «запуск» означает, что кто-то выполняет какой-то пакетный сценарий - не удивляйтесь, если это повторится снова.
Также рассмотрите возможность ветвления. Типичным примером может быть использование основной ветви для разработки, отдельной ветки для тестирования (например, объединяется раз в неделю) и последней ветки (из вышеупомянутой тестовой ветки) для RTC.
Эта ветвь перед развертыванием в производство, следует тщательно протестировать.
У вас должны быть разные ветки, если ваше ПО управления версиями позволяет такое.
В этом сценарии у вас будет человек, который будет отвечать за слияние кода, который уже соответствует качеству bar из основной ветки в производственную.
ОБНОВЛЕНИЕ: Несмотря на то, что руководство относится к конкретному продукту, оно доступно по адресу TFS 2008 Branching Guide 2.0 и содержит множество рекомендаций, которые можно применить к другому программному обеспечению управления версиями, которое может создавать ветви.
Не производите сборку из ствола - вручную объедините проверенный код ствола в производственную ветвь и приступайте к работе из него. Или, как говорят другие ответы, используйте любое количество ветвей и шагов в процедуре тестирования, которое соответствует вашим потребностям.
Кроме того, изменения кода, которые занимают более дня или около того, обычно должны производиться в отдельной ветке функции, пока это не будет сделано .
Очевидно, проблема не в проверке кода в репозитории. У вас есть две проблемы:
1) Любой код, который должен быть запущен, должен иметь специальный тег версии или ветку или что-то еще, в зависимости от используемого вами источника управления. Таким образом, запускаемый код никогда не путают с кодом в разработке.
2) Кто тот придурок, который вообще запускает непроверенный код? ОЧЕНЬ не хватает общения, если человек, который запустил его в жизнь, думал, что ваш код, находящийся в разработке, готов к работе.
Продолжая обсуждение ветвления, это способ to go, чтобы сохранить структурированную обработку версий.
Мы используем магистраль в качестве основной ветки, и когда мы достигаем определенной точки в цикле разработки, когда нам больше не разрешено фиксировать функции (только исправления), мы создаем ветвь NEW для этого выпуска (вместо того, чтобы идти посредством слияния, подверженного ошибкам), и эта ветвь хорошо протестирована, прежде чем мы создадим из нее выпуск.
It seems to me even with Continuous Integration and Unit Tests this is a проблема с человеческими процедурами?
Действительно! Однако вы должны иметь возможность получить некоторую поддержку от своей инфраструктуры для поддержки человеческой стороны вашего процесса. Когда вы собираетесь делать релиз, вы должны легко увидеть все коммиты, которые будут его частью, и все связанные с этим проблемы. Это отчетная сторона непрерывной интеграции. (Я бы сказал, что есть четыре элемента (pdf): сборка, развертывание, тестирование и отчетность.)
Какие чеки / стратегии / процесс может быть запущен, чтобы избежать код выпущен, чтобы жить преждевременно.
Я бы сказал, что любой процесс, в котором нет регистрации в стволе, является обычным ритуалом разработки, что означает любую модель разработки, за исключением ковбойского кодирования.
Позвольте разработчикам рано и часто проверять свои функциональные ветви объедините их в багажник, когда придет время.
Мы создали диспетчер выпусков, который работает с Subversion. www.ReleaseManager.com Таким образом, мы можем контролировать то, что выпускается, по номеру проблемы (или номеру ошибки), и у нас есть контроль, поэтому мы можем вытаскивать вещи из выпуска при необходимости. Ищем бета-сайты сейчас :)