emacs, работа с кодом на сервере разработки

Ты хочешь странного, но можешь заюзать tramp с ssh для удалённого редактирования файлов из емакса со своего локалхоста.

while true; do
f=`inotifywait -r project-dir --format %w 2> /dev/null`
scp -r «$f» server:
done

Правда, если несколько файлов модифицирются одновременно, то будет race.

-e modify еще

написать может на елиспе, чтобы после сохранения вызывало копирование файлов по сети... или какой-нибудь шелл скрипт запускало, если он существует?

> есть разработческий сервер

Я что-то никак не пойму зачем он нужен, если можно всё тоже самое поднять на своей машине?

а я тоже не до конца :) Но, работаем с чем есть, это не моя прихоть.

> это не моя прихоть.

Так надо выяснить чья и дать ему в глаз. Как бы самый простой и правильный вариант решения проблемы.

а кто мешает просто повесить хук, чтобы сразу push-ились файлы с локального гита на удаленный?

ну и на крайний случай - tramp, открываешь dired-ом нужный каталог по ssh и работаешь в нём

до коммита надо еще проверить, работает ли то что ты понаписывал :)

зачем? можно проверить после коммита. git - это не унылое говно вроде перфорса - хоть обфоркайся и обкоммиться - проблем никаких

> У кого-то есть похожие проблемы?

ssh с ключём + ssh-agent что бы не вводить пароль и tramp:
C-x C-f /dev-srv:

> Я что-то никак не пойму зачем он нужен, если можно всё тоже самое поднять на своей машине?

И так стотыщпятьсот раз каждому из разработчиков на каждой их точке присутствия типа рабочий компьютер в офисе, ноутбук и домашний компьютер? а потом следить что бы у того что получилось версии совпадали с тем что на рабочем сервере и чтоб всё это вовремя и правильно бекапилось? По моему это мягко сказать не правильно :)

Проще сделать один сервер для всех куда все подключаются и работают.

По моему это мягко сказать не правильно :)

У вас очень большие и ярко-ярко рыжего цвета тараканы в голове.

Проще сделать один сервер для всех куда все подключаются и работают.

Схема очень хрупка. Что делать если разработчики работают над одним и тем же кодом?

И так стотыщпятьсот раз каждому из разработчиков на каждой их точке присутствия типа рабочий компьютер в офисе, ноутбук и домашний компьютер?

А какие сложности? Если разворачивание окружения представляет проблему, это серьезный повод задуматься.

Дык тебе ж сказали — tramp. Специально для этого написанный пакет, входит в стандартный emacs, начиная не помню уж с какой версии.

делаю в винде

(require 'tramp)
(setq tramp-default-method "plink")

Иногда система бывает такой сложной, что на локалхосте её просто за2.71бешься поднимать.

> Иногда система бывает такой сложной, что на локалхосте её

просто за2.71бешься поднимать.

Да ладно. локалхост сам по себе жутко сложная система, однако подымается на раз. Всё дело в правильной системе развёртывания. Если проект действительно так сложен, то ему нужна отлаженная система развёртывания. А то ведь потом и на боевой сервер за2.17бьешься изменения переносить и с этим будут постоянные проблемы.

Но скорей всего дело в том, что набрали пионеров, которые апач от xterm отличить не могут. Тогда да.

>а потом следить что бы у того что получилось версии совпадали с тем что на рабочем сервере и чтоб всё это вовремя и правильно бекапилось?

мне кажется в том числе для этого и делали распределенные VCS

>Если проект действительно так сложен, то ему нужна отлаженная система развёртывания.

+100500, иначе в конечном итоге оно свалится в неподдерживаемый адъ и апокалипсец

Боевая система может состоять из многих разнородных компонентов, которые разнесены по разным узлам. Её бета-аналог, естественно, тоже. Нафига все тянуть на локалхост? Я вот например не осилю поднять какой-нибудь оракл, который требуется для разработки и не хочу это осиливать когда есть админы. На локалхосте разве только тесты пускать можно.

> Я вот например не осилю поднять какой-нибудь оракл

Дык, его же и не надо подымать на локалхост в любом случае. Надо только попросить админов создать на имеющемся сервере с оракл тестовую базу, на которой ты будешь экспериментировать.

И чем это отличается от того, чтобы примонтировать удаленную ФС с помощью sshfs? Семантически и функционально — ничем.

Примонтировать fs по ssh это слишком сложно, особенно когда сидишь не на одном сервере, а на десятке, а про винду я вообще молчу.

а с гитом че?

> Семантически и функционально — ничем.

Это отличается кардинально когда Вы попробуете сделать grep по проекту.

sshfs Вам закачает все файлы на локальный хост потому что grep у Вас запущен на локальном хосте. А rgrep в emacs'е может работать поверх tramp'а, то есть emacs запускает grep на _удалённой_ системе и ничего по сети не перекачивает кроме вывода grep.

> Дык, его же и не надо подымать на локалхост в любом случае. Надо только попросить админов создать на имеющемся сервере с оракл тестовую базу, на которой ты будешь экспериментировать.

А потом у Вас должен возникнуть логичный вопрос, а зачем мне у себя поднимать и apache с java или php со всеми либами? Почему нельзя попросить админов создать на имеющемся сервере с apache отдельный vhost, на котором ты будешь экспериментировать? :)

> а зачем мне у себя поднимать и apache с java или php со всеми либами?

Вы так говорите, как будто на это требуется больше 5 минут.

Почему нельзя попросить админов создать на имеющемся сервере с

apache отдельный vhost, на котором ты будешь экспериментировать? :)

Затем, что разрабатывать на своей машине значительно проще и быстрее.

а, кажется тоже удаленно работает :) Круто.

> Вы так говорите, как будто на это требуется больше 5 минут.

А теперь представьте что у программиста - gentoo, а у Вас в проекте используется pdflatex, я боюсь что он будет компилировать и настраивать tex больше пяти минут на своём прошлогоднем ноуте с гигом памяти, причём он обязательно забудет поставить cm-super и потом долго будет удивляться почему pdf у него отличается от того что на сервере :)

> А теперь представьте что у программиста - gentoo

Представил, у меня gentoo. Если он не единственный пользователь Gentoo в коллективе, то делается бинарная сборка нужных пакетов одним человеком и все остальные ставят всё необходимое за 1 минуту.

он обязательно забудет поставить cm-super

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

В итоге, в коллективе нужен один вменяемый человек, а все остальные пользуются созданными им пакетами и разворачивают необходимую систему на localhost быстрее, чем успеют выпить утренний кофе.

и потом долго будет удивляться почему pdf у него отличается от того что на сервере :)

Это же прекрасно. Появляется возможность написать вменяемую документацию.

Более того, чем разнообразнее окружения разработчиков, тем лучше — система сама собой тестируется.

> В итоге , в коллективе нужен один вменяемый человек, а все остальные пользуются созданными им пакетами

И где же его взять?.. :)

Хернёй страдаете с удалённым емаксом и tramp. Нужно делать локальный коммит, тестировать, мёржить с удалённого на локальный git и push-ить смёрженный локальный git на сервер.
Остальные девелоперсы работают точно так же.

И что за система такая, которую локально развернуть прям так сложно? Бить палкой по жопе того, кто её так развертывал, что без бутылки не разберёшься — пусть пишет внятно читаемый документ-мурзилку, как развернуть локально. Чтобы у всех были девелоперсов локально были одинаковые одни и те же настройки, что и на сервере.

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

Чтобы настройка и «клонирование настроек» на новый сервер выполнялись одной кнопкой «запустить скрипт». Каждый девелоперс у себя локально запускает этот скрипт.

Вообще, осильте какой-нибудь buildbot/cruise control и сервер непрерывной интеграции. Такая же схема: один нормально развёрнутый сервер, на нём стоит buildbot и постоянно собирает по каждому коммиту. А локально у девелоперсов стоит клонированная такая же конфигурация, что и на сервере.

А по поводу pdflatex и т.п. — тоже всё решаемо. Ну не будет этот pdf собирать локальный девелоперс, а только центральный сервер интеграции. А .tex для этого pdf будет писать каждый девелопер локально. Его локальный .pdf можно проигнорировать и выкинуть, заместив собранным на центральном сервере.

То есть, не пушить на сервер сгенерированные файлы, а только их исходники. А сгенерированные генерятся на одном сервере интеграции.

> Скрипт , который после запуска установит нужный софт с нужными пакетами , настроит конфиги , создаст тестовую базу с нужными пользователями и правами .

Вы конечно понимаете что таким образом заставляете разработчиков ставить себе ту ОС, для которой написан этот скрипт? Либо нанимать администраторов тех ОС, поддержка которых в планах не значится?

то есть:
1. поднимаешь свой локальный сервер с конфигурацей, идентичной той, что на разработческом сервере.
2. В исходниках делаешь 2 варианта: свой_локальный или разработческий. Отличаются указанным IP сервера.
3. Локально делаешь правку. Локальный коммит. Собираешь вариант свой_локальный. Тестируешь.
4. Зелёный свет, протестировано => меняешь вариант на разработческий, который тоже должен работать. Тестируешь на нём тоже, или пропускаешь тестирование, понадеявшись на идентичность конфигурации.
5. Мёржишь изменения остальных с сервера в свой локальный git. Тестируешь, что их изменения не сломали твоё оттестированное.
6. push-ишь на центральный разработческий сервер слитые изменеия локальные + остальных разработчиков в варианте «разработческий сервер».

Здесь потенциально долгие процессы: тестирование; переключение на вариант и сборка нового варианта. Их можно распределить, то есть:
а) код тестируется локально и пушится на центральный уже локально оттестированный код
б) переключение на вариант и сборка варианта делается скриптом. Чтобы не нужно было помнить, какой вариант, локальный или центральный ты собираешь
в) на центральном сервере тестирование и сборка может делаться автоматически, по непрерывной интеграции. Перед сборкой центральный сервер сам переключает вариант «разработческий».

какую именно ОС? Топикстартер настаивает, что у него жутко уникальная ОС с жутко уникальной конфигурацией, а я в это не верю.

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

> И что за система такая, которую локально развернуть прям так сложно ?

У разработчика на ноуте windows, а система его не поддерживает и в нем не работает.

Да вообще-то, все VCS делали в том числе и для этого. Собственно, на всех локальных компах, as я понимаю, достаточно поставить тот же git и не мучаться с trampами и т.п.

> У разработчика на ноуте windows

Извините, но говорить о возможности нормальной разработки на windows не приходится в принципе. Так что рассматривать этот вариант не имеет никакого смысла.

У разработчика на ноуте windows, а система его не поддерживает и в нем не работает.

Шикарно. Просто лорд всех ССЗБ.

вот, к примеру, про непрерывную интеграцию вводная статья на хабре про Hudson+SVN+Maven+Java+Selenium

> не мучаться с trampами

Так никто и не мучается, Вы не увидите разницы между локальным файлом и tramp

>> И что за система такая, которую локально развернуть прям так сложно ?

У разработчика на ноуте windows, а система его не поддерживает и в нем не работает.

если он такой ССЗБ, пускай ставит Cygwin и тестирует в нём. Либо, пускай педалит код, который будет неоттестированный и скорее всего, кривой, пушит его в отдельный sandbox «ССЗБ-разработческий_сервер», где его более тщательно протестируют и оттуда push-нут в основной разработческий сервер.

Дайте ему шанс набраться опыта и поставить себе gentoo. А пока пускай на сервере поработает, ок? :)

вон, к примеру, dbdeploy (пример применения во второй ссылке по посту на хабре)

зачем ставить себе генту, если не писать свои ебилды?

Мы же тут вроде говорим о проблемах разработки, а не об обучении школьников?

Хернёй страдаете с удалённым емаксом и tramp.

emacs как раз локальный, просто он редактирует удаленные файлы

И что за система такая, которую локально развернуть прям так сложно?

Чего ты локально развертывать собрался? Ты представляешь себе многозвенную сложную систему уровня гугла? Ну поднимешь ты один из узлов у себя на машине локально, а дальше что? Все равно работа будет происходить фактически удаленно.

а мужики то не знали