Все в одном установщики или Core + Plugin Sub установщики? - PullRequest
1 голос
/ 29 августа 2011

Соберите все в один устанавливаемый блок

  • Pros
    • Один пакет для тестирования и развертывания во всех средах
    • Все плагины установлены, но, возможно, не зарегистрированы для использования в конфигурации
  • Cons
    • Плагины могут быть в разных состояниях канала, как развертывать только хорошие.
    • Как обрабатывать регистрацию, какие плагины для развертывания в какой среде
    • Трудно изменить свое мнение, может быть месяц между сборкой dev и продвижением prod

Build Core Installer (без плагинов) + вспомогательные инсталляторы (только плагин)

  • Pros
    • Меньшая занимаемая площадь, чтобы меньше места для ошибок
  • Cons
    • Возможность ошибок интеграции между плагинами, так как они могут быть установлены в различных порядках
    • Как откатить развертывание, если предыдущее развертывание могло представлять собой странный ассортимент основных и вспомогательных установщиков. Нужен способ отследить, что содержит конкретная установка
    • Как воспроизводить ошибки в QA, когда в QA есть все плагины, а prod может иметь меньшее, возможно, более старое подмножество.

Это мои мысли по вопросу, который я изо всех сил пытался получить и съесть свой пирог, но я, кажется, застрял с этими двумя вариантами. Кто-нибудь еще боролся с этой проблемой и как вы ее решили? Любые другие плюсы и минусы, которые я пропустил? Пока что я выбрал подход «все или ничего», но я открыт для идей.

Заранее спасибо.

1 Ответ

1 голос
/ 29 августа 2011

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

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

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

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

Есть еще один вариант: комбинация двух подходов, описанных выше. Рассмотрим проект Eclipse: у него общая платформа и плагины. Можно скачать пакет с набором плагинов, которые обычно используются в конкретной среде. Другие плагины могут быть установлены позже, если это необходимо. Таким образом, вы объединяете свое ядро ​​с несколькими логически связанными плагинами; другие плагины могут быть добавлены к установке позже.

...