Несколько приложений с композитором

Существует основное приложение, давайте назовем его ПРИЛОЖЕНИЕМ.

ПРИЛОЖЕНИЕ имеет несколько зависимостей (включая проекты с открытым исходным кодом и собственные библиотеки).

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

В настоящее время я реализовал это следующим образом:

  • Разрабатывайте приложение локально, используйте Composer для обновления его зависимостей (composer update), push ПРИЛОЖЕНИЕ для центрального репо

  • Для каждого обычного клиента pull ПРИЛОЖЕНИЕ из центрального репозитория и установите зависимости Composer (composer install)

  • Для клиентов с определенной реализацией создайте новый SM (конкретный модуль), содержащий следующий файл composer.json: 

    ...
"require": {
    "APP": "X.X.X"
} 
...

Затем примените те же шаги, что и раньше для этого SM (composer update локально, PUSH к центральному репо, PULL из центрального репо, composer install).

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

  1. composer.lock из ПРИЛОЖЕНИЯ будет игнорироваться SM (поскольку приложение загружается как библиотека в папке vendor/, а composer игнорирует файлы библиотек composer.lock); это совсем не хорошо, так как я не буду уверен, что конкретные клиенты будут использовать те же библиотеки, что и ПРИЛОЖЕНИЕ.

  2. Каждый раз, когда я исправляю ошибку или внедряю новую функцию в приложение (и это происходит часто - несколько раз в день), помимо шагов, которые я выполняю для постоянных клиентов, мне также нужно перестроить SMS (так как одна из их библиотек - ПРИЛОЖЕНИЕ - была обновлена до новой версии, которую мне нужно использовать). Это накладные расходы, так как большинство изменений, которые я выполняю, находятся внутри приложения (а не в SM). Итак, если бы это было по-другому (приложение, имеющее SM в качестве зависимости), оно бы работало быстрее (так как мне не нужно было бы composer update на каждом SM).

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

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

Author: Wouter J, 2015-05-14
Source

1 answers

Я реализовал это, создав определенный модуль (назовем его SM) для каждого клиента, который я просто добавляю в их экземпляр ПРИЛОЖЕНИЯ

Для клиентов с определенной реализацией создайте новый SM (конкретный модуль), содержащий следующий файл composer.json:

Это приложение с клиентским модулем (рядом с другими зависимостями).

Приложение имеет модуль в качестве зависимости (приложение, имеющее SM в качестве зависимости).

И не : модуль извлекает приложение, поскольку оно зависит от поставщика. Это приведет только к дополнительным шагам, которые необходимо предпринять на этапе разработки (ваша проблема 2).

Я бы предложил провести рефакторинг приложения и его модулей, пока вы не получите следующую структуру папок:

|-application             #< the application has dependencies
  |-src
  |-tests
  |-vendor
    |-framework           #< maybe your application is framework based
    |-libs                #< more dependencies
    |-...                 #< other modules
    |-sm                  #< the client specific module

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

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

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

Да! Необходимость перестраивать модуль каждый раз, когда вы меняете приложение, исчезнет, если вы начнете "разрабатывать внутри приложения" с помощью модуля зависимости.

А для нескольких клиентов просто используйте несколько репозиториев приложений, которые имеют собственный набор требований. 10 клиентов, 10 репозиториев приложений, 10 файлов composer.json. Запустите composer install no-dev, затем предварительно упакуйте каждое репо и поместите zip в загрузки. Готово.

Вы можете использовать проект "контейнер" или "упаковка" здесь, где composer.json каждого проекта будет включать приложение и конкретные модули. Вы можете использовать оператор каретки или тильды, чтобы указать диапазон версий для приложение ("vendor/app": "^1.2.3"), а затем просто update и repackage, после выпуска новой версии приложения. Этот подход должен работать с автоматической загрузкой композитора, потому что приложение также останется в папке поставщика. Требуется только небольшая обертка, чтобы настроить автозагрузчик composer и переключиться на ваше приложение.

Или, если приложение действительно модульное. Просто упакуйте основное приложение и предоставьте клиентские модули в качестве дополнительных загрузок. При таком подходе обновления будут состоять из нескольких этапов загрузки: обновление приложения, обновление модулей. Думайте об этом как об обновлениях/обновлениях в стиле wordpress.

Вы можете еще больше снизить сложность процесса обновления/развертывания, удалив часть composer install --no-dev на клиентском компьютере , создав "архивы приложений для конкретного клиента" на компьютере разработчика. Это в основном пакет приложения "--no-dev" со всеми его зависимостями, включая клиентские модули= предварительно упакованный.

Как, Application-v1.2.3-WithModuleAForClientA-v3.2.1.zip.

На компьютере разработчика: composer install --no-dev --optimize-autoloader + zip.

Для установки или обновления просто download на клиент, extract, выполните сценарий upgrade. Сделано.

 0
Author: Jens A. Koch, 2015-05-14 21:38:08