Как лучше переносить файлы с локального сервера на удалённый?
Здравствуйте!
Сейчас у нас в компании разработка ведётся не самым лучшим образом — редактор подключен по SFTP к удалённому серверу и все изменения вносятся сразу туда. Всё бы ничего, но проект с недавнего времени запущен и такая схема естественно не подходит.
Мы поставили локальный сервер в офис, настроили и подняли там локальную копию проекта и собираемся перейти на разработку и тестирование на нём, а с него уже выгружать обновления в паблик, на удалённый сервер.
Вопрос в следующем — как и чем лучше выгружать изменения на удалённый сервер?
Хочется:
Чтобы инструмент был не в качестве демона, а срабатывал по запуску.
Иметь возможность по маске запрещать выгрузку определённых файлов (например *.jpg, *.json)
Простую настройку
Системы контроля версий наверное в этом случае не нужны по двум причинам:
1. Планируется ввести её локально
2. Для этого потребуется обучиться и обучить нескольких людей, что требует много времени и в данный момент не подходит из-за нехватки этого самого времени.
1. Планируется ввести её локально
2. Для этого потребуется обучиться и обучить нескольких людей, что требует много времени и в данный момент не подходит из-за нехватки этого самого времени.
1. введите где хотите, ничего не мешает на сервак тянуть изменения с локального репозитория
2. для начала просто svn commit и svn update достаточно чтоб не терять времени, остальное можно постепенно учить. есть гуишные системы контроля версий, есть встроенные в иде.
Было бы желание. Хотя если вам проще тратить время на настройку того с чем справятся системы контроля версий лучше советов выше чем обучить пару людей пожалуйста. Вспомните еще этот камент когда зальете поверх файл с ошибкой и начнете вместо одной простой команды делать на много больше телодвижений на живом серваке. =)
На сколько я понимаю придётся сделать как минимум 2 репозитория, настроить удалённо хуки для выгрузки самих файлов, в двух местах хранить настройки репозиториев (те же игнор-листы) и обновлять так же в двух местах. Это достаточно усложняет и замедляет процесс разработки. Да, так правильнее, но не всегда это возможно.
Возможно и не вспомню :) я как раз здесь писал о том, что будет как минимум 2 версии — локальная и внешняя. Если кто-то из разработчиков и зальёт на локальный сервер ошибочный файл, то его можно будет восстановить как минимум из двух мест — с другого разработчика и с удалённого сервера.
Один репозиторий храните, в нем будет несколько веток (тестовая, живая итд) переключаются ветки одной командой, репозиторий можете хранить где угодно, лишь бы был доступ к нему с сервака. Ошибочно никто никуда не зальет, все работают с тестовой веткой и изменения мержатся лишь после тесрирования.
rsync по ssh хорошо лишь если вам нужно смержить файлы, для чего-то серьезного (защита от ошибок) он не спасет. Не зря системы контроля версий на столько популярны, они того стоят. Да и обучение выйдет дешевле чем одна фатальная ошибка при заливе на живой сервак испорченого кода :)
1. Что мешает поднять Git локальный?
2. Время? Попробуйте посчитать, не сэкономите ли больше обучив за пару дней всех кого надо а потом все будет работать. Все таки системы контроля версий ни разу не Rocket Science.
При должной настройке копирование файлов на удаленный сервак происходит по одной команде.
При этом в полном вашем распоряжении возможности по игнорированию различных типов файлов, хуки, проверяющие на синтаксические ошибки и прочее.
Git/Mercurial/(или даже)SVN вполне справляются с такими задачами. Да и VCS для разработки штука полезная.
Если по каким-то причинам все-таки не желаете, то 1. ищите именно системы деплоя (Capistrano или что там есть), 2. bash + rsync.
по-моему вполне естественно использовать dvcs — mercurial или git
1) то же, что и «локально», только история изменений будет в нескольких местах
2) для большинства достаточно показать/запомнить 3-5 команд — это вопрос даже не часов, а минут.
Система контроля версий нужна, потому что с ней жизнь в тысячу раз лучше, чем без неё.
Это не очевидно сразу, зато становится ясно, когда она пару раз поможет при крупном факапе, и когда разработчиков будет больше одного.
Про SVN ничего не слушайте. Двадцать первый век на дворе, изучать SVN сейчас это маразм.
Простой
Средний
Средний
