@pechorin хотя, можно еще будет продумать схему, при которой от master ветки необходимо будет создать стабильную версию release и только её разворачивать (как вариант). Так и master можно без труда обновлять для каких-то "бета версий прода"
Top-level
14 comments
@pechorin ну обновлять 20+ файлов, загружая их по FTP (или SFTP) я уже подустал, поэтому и задумался о том, что бы централизовано подходить к обновлению своих проектов. Решение "для чего-то, что нельзя сделать на хостинге с php - буду думать про сборки и централизованное хранение образов с разворотом". Но мой принцип "выжимать из языка максимум, без подключений Reddis, Mongo, Rabbit или других ПО" - заставляет и учиться и пытаться максимально изучить язык. rsync это делает проще, но надо быть аккуратным с правами доступа и юзерами. иногда надо переписывать GID:PID для другой машины, чтобы не вышло криво и не появились уязвимости.
@pechorin @iron_bug можно сказать, что я понял ряд "дешевых вариантов", которые можно "реализовать уже сейчас", но так же понял несколько подходов, по которым мне стоит будет почитать документацию и изучить вопрос более точно. Ну и так же найти варианты применения для максимального уровня "производительности, удобства и простоты". пардон, и чем же "плох" rsync? используется повсеместно, никаких проблем с ним нет. не жирен, не жрёт лишние ресурсы. это стандартная утилита, можно сказать.
да, люди придумали много ненужных костылей, которые жрут ресурсы и требуют кучу времени. но нормальые простые инструменты вполне есть и они работают. @pechorin с разными Reddis, Rabbit, Memcache, MySQL, MongoDB я работал. Всегда смотрю на прототип и его ценность. Если не получается оптимизировать логику "кеша" и всё равно "глючит", то ищу способы вначале локально, а потом думаю про подключение Reddis или Memcache. Сталкиваю по работе с ситуациями, когда не хотят "изучать проблему", а "перекрывают проблему добавлением нового компонента". |
@bifik честно говоря это все ты решаешь сам, если освоишь любой ci/cd продукт типа github actions, там выбираешь после какого события что случается (on: push /on: release). Думаю так оно в любой continuous integration / continuous delivery системе работает. Главное не уходить в каменный век, с git pull'ом и rebuild'ом на серваке по крону. Так можно и до заливки по ftp дойти. (точнее откатиться)