Как можно улучшить организацию дев окружения и деплоя при разработке библиотеки?

Question

[SymphoGraph]

Здравствуйте. Я привык к следующему способу разработки:
Локальные файлы проекта синхронизированы с дев папкой на удаленном сервере, исключая vendor, посредством PhpStorm. Запуск скриптов производится на сервере. Мне это нравится тем, что я сразу имею представление об их поведении ввиду того же окружения и железа на деве, что и на боевом.

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

• Внесение изменений.
  
• Комит, пуш.
  
• Создание релиза.
  
• composer update на локальном
  
• composer update на удалённом
  

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

Как это делаете вы? Может есть какой-то способ упростить жизнь?

Comments

[Ипатьев]

в качестве совсем уж костыля, можно синхронизировать не весь вендор, а только папку с этим пакетом )

[SymphoGraph]

Ипатьев, похоже, что именно к этому я сейчас наиболее близок.:)

Answer 1

[Ипатьев]

Докер.

Вообще очень странно, что вы так долго могли усидеть на такой неудобной конструкции.
99% разработчиков тестируют код локально, ничего никуда не "синхронизируя" и не "заливая".

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

Как вариант - можно попробовать Continuous Integration, который весь этот список от пуша до composer update на удалённом будет выполнять автоматом.

Comments

[Максим Федоров]

под маком вряд ли есть проблемы, но слышал о таковых
даже с учетом arm архитектуры — все ок у меня, например

[Максим Бабичев]

Максим Федоров, macbook pro (m1 pro/16gb/512). С докером есть проблемы на больших проектах 4м+ строк кода (не считая vendor/*). Приходится костылить docker-sync, чтобы не ждать синхронизации по 5-10 сек. С костылем docker-sync синк занимает ~100-300ms.

[SymphoGraph]

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

в качестве совсем уж костыля, можно синхронизировать не весь вендор, а только папку с этим пакетом )

Мне не очень часто приходится запускать новые проекты. С докером я в общих чертах знаком. Когда-то давно еще vagrant использовал, open server. В целом по ощущениям я разницы не замечаю особо. Мне что виртуальный локально, что удалённый, они одинаково выглядят.
А если Laravel, то ему теперь вообще никто не нужен: artisan сам всё запускает что нужно.

Вся неприятность сконцентрирована именно в процедуре релиза библиотеки, ибо у githab это происходит не самым эргономичным образом. Если это можно автоматизировать, расскажите плз куда почитать?
Подобным образом у меня реализован билд фронтенда: после пуша в githab запускается action, выполняет билд. После чего остаётся только сделать git pull на боевом. (Последнее я не автоматизирую осознанно)

[fenrir]

Правда, говорят что под виндой какие-то до сих пор проблемы с докером

WSL закрывает все проблемы

[Dmitry Bay]

Максим Бабичев, Это не надстройка cache?

Я докер давно специально не запускал ( только на тестах).
И вот стало интересно, как сейчас с торможением.

[Максим Бабичев]

Dmitry Bay, по сути, это кэш с маунтом в докер. Под капотом там обычный rsync

Answer 2

[galliard]

Есть у композера такая фишка https://getcomposer.org/doc/05-repositories.md#path

То есть можно прописать в свой основном composer.json репозиторий типа "path" и прописать там путь к папке с твоей библиотекой. Таким образом комит, пуш, создание релиза и composer update на локальном делать не придется, изменения в библиотеке сразу будут и в основном проекте.

Answer 3

[Максим Федоров]

Данный вопрос не совсем относится к докерам или обновляениям папок через Шторм... а просто удобства с пакетом, который вы и саппортите

Ошибки:
- нужно писать тесты, чтобы предупредить ошибки :)

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

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

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

Comments

[SymphoGraph]

сделайте не композер пакетом, а просто как сабрепозиторий, тогда любой из проектов просто как сабгит подтянет... при этом из каждого можно будет ее редактировать и не тянуть как вендор :)

С этим я совсем не знаком. Это что-то связанное с Submodules или можно как-то более эффективно загуглить?

[Максим Федоров]

Роман Чубич, https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%...