Лучшая стратегия для обновления скелета проекта Symfony

Question

Лучшая стратегия для обновления скелета проекта Symfony

1

У меня есть настроенный Symfony-проект и пользовательский поставщик. В composer.json проекта тип имеет значение "project". Для обновления моего поставщика я использую composer update. Все идет нормально.

Но как мне обновить сам проект? Он установлен композитором create-project, но я знаю, что для композитора не существует такого update-project. Какова наилучшая стратегия для поддержания моего "скелета" в актуальном состоянии? Использование git потребует init git репозитория и проверки правильной ветки/тега. Так что это не мое любимое решение для конечных пользователей и управление релизами. Какие другие методологии можно использовать для решения этого сценария?

RockKeeper 18 нояб. 2015, в 11:00

Источник

0

Что вы подразумеваете под скелет?
eRIZ 18 нояб. 2015, в 09:48
0

Я имею в виду сам проект ... Следующая структура папок: - [приложение] - [bin] - [vendor] - [web] - composer.json - и т. Д. ... с обновлением composer я могу обновлять только пакеты в папке vendor а как насчет отдыха? папка app (которая содержит конфигурационные файлы и т. д.). со скелетом я имею в виду все остальные вещи за пределами папки продавца
RockKeeper 18 нояб. 2015, в 10:08
0

Незначительные версии не должны модифицировать скелет, только Symfony3 представит некоторые модификации.
COil 18 нояб. 2015, в 12:51
0

До сих пор не совсем понятно, о чем вы спрашиваете. Что касается разработки, вы бы использовали git push для обновления своего хранилища. Для развертывания вашего конечного пользователя используйте git clone с последующей установкой composer. Для обновления конечный пользователь будет использовать git pull с последующим обновлением композитора. Конечно, есть много других подходов к доставке, которые скрывали бы команды git / composer от конечного пользователя. Но похоже, что вы просите что-то еще?
Cerad 18 нояб. 2015, в 13:22
0

Нет, это именно то, что я имею в виду. Я хочу, чтобы обновление было как можно более простым для конечного пользователя ... Of course there are many other delivery approaches which would hide the git/composer commands from the end user. Можете ли вы рассказать мне больше об этом? Какие способы доставки вы имеете в виду?
RockKeeper 18 нояб. 2015, в 14:18
0

(возможно мой плохой английский тоже проблема). Ситуация: я скачал Symfony и поместил его в Git-репо (A). Я создал продавца во втором репо (B) и подключил его через composer.json. Все идет нормально. Enduser может запустить composer create-project xxxx для установки приложения. он может вызвать composer update чтобы обновить моего поставщика. Но теперь я изменил файл за пределами папки продавца в Repo (A). Конечный пользователь не может получить эти модификации, запустив composer update . Но как он может сделать это как можно проще? (без git fetch , git checkout tag/xxx т. д.… для выполнения вручную).
RockKeeper 18 нояб. 2015, в 14:24
1

самое простое решение - это git
john Smith 18 нояб. 2015, в 16:09
0

Вот список инструментов, которые могут помочь: symfony.com/doc/current/cookbook/deployment/tools.html . И нет, конечный пользователь никогда бы не использовал composer create-project для установки приложения. create-project используется только разработчиками в качестве отправной точки.
Cerad 18 нояб. 2015, в 19:16

Показать ещё 6 комментариев

Теги:

php

symfony

composer-php

2 ответа

Ещё вопросы

Что вы подразумеваете под скелет?
Я имею в виду сам проект ... Следующая структура папок: - [приложение] - [bin] - [vendor] - [web] - composer.json - и т. Д. ... с обновлением composer я могу обновлять только пакеты в папке vendor а как насчет отдыха? папка app (которая содержит конфигурационные файлы и т. д.). со скелетом я имею в виду все остальные вещи за пределами папки продавца
Незначительные версии не должны модифицировать скелет, только Symfony3 представит некоторые модификации.
До сих пор не совсем понятно, о чем вы спрашиваете. Что касается разработки, вы бы использовали git push для обновления своего хранилища. Для развертывания вашего конечного пользователя используйте git clone с последующей установкой composer. Для обновления конечный пользователь будет использовать git pull с последующим обновлением композитора. Конечно, есть много других подходов к доставке, которые скрывали бы команды git / composer от конечного пользователя. Но похоже, что вы просите что-то еще?
Нет, это именно то, что я имею в виду. Я хочу, чтобы обновление было как можно более простым для конечного пользователя ... Of course there are many other delivery approaches which would hide the git/composer commands from the end user. Можете ли вы рассказать мне больше об этом? Какие способы доставки вы имеете в виду?
(возможно мой плохой английский тоже проблема). Ситуация: я скачал Symfony и поместил его в Git-репо (A). Я создал продавца во втором репо (B) и подключил его через composer.json. Все идет нормально. Enduser может запустить composer create-project xxxx для установки приложения. он может вызвать composer update чтобы обновить моего поставщика. Но теперь я изменил файл за пределами папки продавца в Repo (A). Конечный пользователь не может получить эти модификации, запустив composer update . Но как он может сделать это как можно проще? (без git fetch , git checkout tag/xxx т. д.… для выполнения вручную).
Вот список инструментов, которые могут помочь: symfony.com/doc/current/cookbook/deployment/tools.html . И нет, конечный пользователь никогда бы не использовал composer create-project для установки приложения. create-project используется только разработчиками в качестве отправной точки.

Wouter J · Answer 1 · 2015-11-18T14-34-00.000Z

Нет лучшей альтернативы, так как скелет полностью свободен. Вы можете использовать Symfony, просто добавив зависимость symfony/symfony и создав собственную структуру каталогов.

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

Каждый раз, когда выпущена новая версия скелета, вы можете проверить diff (например, https://github.com/symfony/symfony-standard/compare/v2.7.2...v2.7.3) и проверить изменения и применить изменения на ваш проект, когда они необходимы в вашем проекте.

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

RockKeeper · Answer 2 · 2015-11-19T07-20-00.000Z

На данный момент я тестирую другой подход. Я создал bash-скрипт, который входит в состав composer.json в части после установки и после обновления. Я знаю, что это должно существовать, но с этим, конечный пользователь должен сделать только composer update

composer.json

[...]
    "scripts": {
    "post-install-cmd": [
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::removeSymfonyStandardFiles",
      "chmod +x init_update_app && ./init_update_app"
    ],
    "post-update-cmd": [
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
      "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::removeSymfonyStandardFiles",
      "chmod +x update_app && ./update_app"
    ]
  },
[...]

После установки:

#!/bin/bash

if ! git ls-remote origin > /dev/null; then
    git init
    git remote add origin https://github.com/xxx/xxx.git
fi
git fetch --tags
latestTag=$(git describe --tags 'git rev-list --tags --max-count=1')
git checkout $latestTag

Post-Update:

#!/bin/bash

git fetch --tags
latestTag=$(git describe --tags 'git rev-list --tags --max-count=1')
git checkout $latestTag

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