Всем привет.
Попробую в кратце описать суть вопроса:
есть проект на битриксе, назовем его site.ru. Есть его dev версия dev.site.ru, под гитом, все работает отлично.
Но тут мне приходит мысль новый функционал выполнить на React, используя ES6 и JSX. Не могу сказать, что я знаком со всем стеком современных технологий, поэтому и нуждаюсь в поддержке. Я немного продумал схему действий, но не уверен, что она верная:
нужно установить npm, webpack, babel на дев копии.
соответственно, при разработке вся работа будет идти на dev.site.ru:3000
а при успешном результате нужно взять полученный bundle.js и с помощью гита перенести его на prod.
Имеет ли данная схема право на жизнь?
Какие могут возникнуть проблемы?
Вопрос достаточно холиварный на самом деле. Ответ во многом зависит от того, как вы доставляете код в production, есть ли какая-то система типа Gitlab CI, или делаете всё руками через git push/git pull.
Я думаю что вполне нормально держать в git'е и исходники js, и собранный/минифицированный bundle.js.
Так вы упростите себе жизнь - достаточно будет только перенести файлы в prod, это лучше, чем на боевом сервере запускать сборку.
Спасибо за ответ. в прод все попадает через pull/push.
Ещё не большое добавление:
допустим это проект я закончил, сформировал бандл, например, bundle-reports.js
далее приступил к другой не связанно задаче, которая будет использоваться в другой части сайта. Я так понимаю, под неё я должен буду собрать новый бандл, который так же переедет на прод, например, bundle-task.js или я не правильно понимаю принцип сборки ?
Snatch87, проще всего хранить всё в одном бандле, а на модули делить в исходниках.
Например, у вас может быть одна точка входа - src/app.js, в которой вы подключаете src/reports.js, src/tasks.js и так далее.
Это все собирается в один bundle.js, который подключается на всех страницах. Несмотря на то, что файл может получиться немаленький, пользователь загрузит его всего раз - и далее он попадет в кеш браузера.
Проблема хранения bundle в git -- невозможность их автоматического слияния при работе в нескольких ветках. Если проект будет развиваться, и понадобится возможность работать над несколькими задачами отдельно (или работать нескольким персонам параллельно), это станет очень мешать.
Алексей Казаков, я думал об этом, поэтому и спрашивал про несколько бандлов. Но думаю, что текущая схема работы с гитом должна подойти: у каждого разработчика есть своя ветка и своя копия проекта, на которой он ведет разработку. Перед началом каждого проекта, разработчки делает pull из master. По окончанию разработки всё пушится на общую ветку для разработки (dev) и тестируется менеджером. Здесь можно так же собрать бандл и сделать пуш. Ну а потом на прод.
Просто не хочется менять выработанную схему по работе с гитом.
Обычно bundle в git не хранят.
Можно или вручную, или автоматически при обновлении запускать где-то тесты и сборку, после чего выкатывать обновление на прод.
Спасибо за ответ.
Я не уверен, что мои мысли в этом направлении верны, поэтому расширю исходные данные:
данный проект, как и остальные работают в связке nginx + php-fpm
К примеру, данная задача, это страница с отчетами, которая доступна по site.ru/reports/index.php
Как я понимаю, на prod нужно так же установить npm, babel
И после переноса написанных на React компонентов, также запустить npm и собрать bundle или npm должен работать постоянно, а nginx слушать его порт?
PS: я бэкэндер, мои опыт во frontend - это jQuery и ES5. Ну и сама связка работы npm, webpack для меня пока темновата)
Алексей Казаков, т.е на проде npm и все к нему прилагающиеся не нужны?
Все никак логику процесса не уловлю. Получается, что все компоненты на прод переносить не нужно?
И можно по подробнее об отдельном сервисе
Да, в таком варианте не нужны. Процесс может происходить так:
На dev сервере разрабатывается обновление
Ветка с обновлением мержится в master
CI сервер (например, такой) узнает об обновлении, скачивает его из гита, запускает тесты
Если тесты прошли успешно, этот же сервер, где будут установлены все нужные для этого вещи, собирает проект и заливает его на прод, где нет ни гита, ни npm
Сложный