PHP+Netbeans
Добрый день.
Вопрос по воркфлоу.
Есть нетбинс и проектов
Hot Positions, Cool Company! NeoGames
✖
×Закрыть
Facebook
Twitter
LinkedIn
Oleksandr Suvorov
git + repo або git + submodules. Думаю, в вашому випадку краще git submodules.
git-scm.com/...n/v2/Git-Tools-Submodules
Це не змінить вашого процесу деплою, але дозволить вашу лібу оновлювати локально на проектах автоматично.
Paul Loyanich
А потом эти люди приходят на собеседования и просят 3K$, потому что рынок.
Олексій Пєніє
И пусть себе просят. Ключевое слово «потом». И заметь, в отличие от тех кто «знает как правельна», не постеснялся спросить.
Paul Loyanich
И заметь, в отличие от тех кто «знает как правельна», не постеснялся спросить.
Да, ты прав, прошу прощения у ТС.
Я не пойду просить 3k потому что работаю на себя. Первую программу я написал в 1987 году, первые деньги в IT заработал 1989. Моя проблема заключается в том что у меня нет времени разбираться в модных трендах деплоя и интеграций, нанимать человека из-за такой ерунды как-то глупо, объяснить мне не кому. Конечно я знаю про батники и симлинки, и я немного при***л что мне их начали советовать,конечно я использую git. Возможно я не вполне корректно поставил вопрос, честно говоря я ожидал живой дискуссии о cd/ci решениях для php или какой-то гитфлоу, TeamCity или GitLab, GoCD или Jenkins? Но, б***ь, нет.
Ну, раз так, тогда можно попробовать разделить деплой и разработку.
У NetBeans же есть какие-то Include Path’s? Вот в разработке их и используйте.
Ну а в рантайме — PHP же может в
ini_set("include_path", ini_get("include_path") .PATH_SEPARATOR. FOLDER_WITH_THE_LIBRARY_FILE)
и уже работать с FOLDER_WITH_THE_LIBRARY_FILE где-то
Valeriy Shvets
конечно я использую git
Руслан, без обид, но об этом ни слова не сказано. А фразы:
которые деплоятся на сайты клиентов как правило из редактора ide при сохранении
Сейчас я копирую новую версию библиотеки в папку проекта
дали основания думать что нет контроля версий и возможно даже ssh, а только ftp.
И при таких вводных данных начинать давать советы что срочно нужно ставить дженкинс, паковать всё в контейнеры, настраивать kubernetes, мульти-стейджинг окружение и куда без «канареечного развёртывания». Это ещё более нелепо, чем советы с bat-никами или симлинками.
Так как не ясно как сейчас происходит деплой и какие есть инструменты кроме git’а, то следующим логическим шагом будет предложить вынести библиотеку в:
a) git submodule
b) сделать собственный composer пакет (выкладывать в packagist.org не обязательно, просто прописать url на свою репу)
С композером может быть гибче, зафиксировав мажорную версию в репозиториях проектов, можно больше не трогать composer.json при изменении библиотеки, пока не нарушается обратная совместимость. А на сервере делать composer update. Но это всё равно плохая практика, особенно если есть другие зависимости, которые вы не контролируете. Всё же правильней комитить composer.lock и на сервере делать composer install.
Это про то, как сделать правильней, но от ручного труда или написания скрипта не избавляет.
Самый простой, но рискованный вариант, это реально симлинки. На сервере в отдельном месте лежит библиотека и на неё симлинки со всех проектов, обновив её, сразу изменения везде подхватились (в зависимости от настроек opcache, конечно).
Можно это всё конечно «наворотить» — каждая версия/тег разворачивается в свою директорию и в проектах меняются симлинки на максимальный тег своей мажорной версии, чтоб проекты, зависящие от v1.x библиотеки, не поломались, когда выкатим v2.x с другим интерфейсом, если все будут ссылаться на одну директорию/версию.
В общем можно сделать множеством способов, как лучше зависит от того, как часто делаются изменения, особенно ломается обратная совместимость. Если меняется раз в неделю-месяц, так может реально копировать руками — это самый простой вариант )
Как будто по итогу всё не сводится к батникам. Если ты ТОЧНО знаешь, чего хочешь — то самое простое решение и есть самое правильное. Самое глупое — это придумывать абстракции «на будущее» ради масштабирования. Потому что ты реально не знаешь, в какую сторону это будущее намерено масштабироваться, и где твоим проектам потребуется кобыле х&u пришить. Чаще всего всё останется как есть, и будет работать без шума и пыли.
У «модных» тенденций есть свойство становиться немодными, очень быстро превращаясь в говно мамонта ради очередных инновационных способов сделать по сути то же самое.
Хочешь счастья — пиши свой инсталлятор на основе типовых конструкторов и готовых сборок, не ошибёшься. Там ты сможешь чётко предусмотреть что делать, когда какое-нить нестандартное окружение подвернётся, или конфликт юзера со здравым смыслом.
С деплоем на серверную часть — вообще забей на моду, лучшее — враг хорошего.
Биг дата копатель
Я знаю, что тебе надо. Придумал гениальную идею, аналогов нет в мире. Нужно написать скрипт который будет загружать папки/архивы с кодом из какого то сервера удаленно когда вызываешь этот скрипт. Нужен файл в котором будут прописаны эти зависимости в корне каждого проекта и потом ты в корне этого проекта вызываешь скрипт чтобы обновить зависимость.
Вот набросал апи дизайн апликухи по быстрому:
bash$ bike update
P.S. Серьезно. Если есть возможность запускать composer то наверно более нормальный вариант обновляеть через него если нет CI и контроля версий.
Олексій Пєніє
Тупо раскидать симлинки на файл по папкам — не судьба?
Valeriy Shvets
Сделай bat-файл, который будет копировать твою «библиотеку» во все
p.s. тема прямо на 20 лет назад вернула — выливка по ftp, никакого version control, миграций, ci/cd.
Хотя в 2002 уже проекты были в cvs и какие-то кастомные велосипеды для накатывания изменений структуры базы делал.
11 комментариев
Добавить комментарий Подписаться на комментарииОтписаться от комментариев