Комментарии 81
Когда то давно, в 2005 году, этот вопрос задал на PHPClub участник ForJest
phpclub.ru/talk/showthread.php?s=&threadid=78095&perpage=20&pagenumber=1
Интересно, что изменилось с тех пор?
phpclub.ru/talk/showthread.php?s=&threadid=78095&perpage=20&pagenumber=1
Интересно, что изменилось с тех пор?
На коммит SVN повешен триггер, чекаутит из него файлы в рут проекта.
SVN->export->FTP
ant
rsync
Сетевой диск.
hg push
НЛО прилетело и опубликовало эту надпись здесь
А если у вас 54 фронтенда? А если больше? То что на каждый делать руками push? Или на каждом делать руками pull?
capistrano
CVS/SVN извлекаю из репозитория
а я еще коммиты иногда делаю в репозитарий :-D
а я еще коммиты иногда делаю в репозитарий :-D
По большей части — ручное развертывание. Бекап баз, бекап системы, апгрейд базы и системы — стрёмно делать на автомате.
Если уделять много времени тестированию, то все будет, хорошо.
А если падает в автомате, значит у вас проблемы в тестирование того что делаете вы.
А если падает в автомате, значит у вас проблемы в тестирование того что делаете вы.
Очень многие вещи нельзя проверить — скажем миграция продакшен баз. Ее можно многократно проверять на тестовых данных, но никогда не знаешь, что получится на реальной системе. Assumption is the mother of all fuck ups.
А что мешает на тестовом стенде/у программистов использовать snapshot живой базы?
Финансовые / страховые данные, никто не даст копию живой базы.
md5sum от ключевых полей. Например от всяких имен клиентов и адресов. И вообще всегда можно в NDA поиграть.
NDA, он всегда есть, как же без него.
Копии кусков базы тоже есть, естественно аннонимизированые. Но:
*) не целиком (тут всё банально — слишком большие базы)
*) случаются веселые проблемы на записях, которые были вырезаны/изменены в процессе аннонимизации. Извращенские кодировки, скажем (это, впрочем, обычно только при первой миграции случается). Вариантов бывает очень много.
Я к чему веду: не всегда нужно автоматизировать процессы. Да и TCO иногда получается ниже при ручном варианте.
Копии кусков базы тоже есть, естественно аннонимизированые. Но:
*) не целиком (тут всё банально — слишком большие базы)
*) случаются веселые проблемы на записях, которые были вырезаны/изменены в процессе аннонимизации. Извращенские кодировки, скажем (это, впрочем, обычно только при первой миграции случается). Вариантов бывает очень много.
Я к чему веду: не всегда нужно автоматизировать процессы. Да и TCO иногда получается ниже при ручном варианте.
Сейчас использую Microsoft Visual SourceSafe
А вообще cvs/svn больше нравится
А вообще cvs/svn больше нравится
IMHO правильно использовать репозиторий для вашей ОС. Если это debian, для примера, вы просто собираете их в пакетики, и кладете в stable репозиторий, и оно само расползается по тому, куда ходят люди. При этом репозитории должны быть, как минимум: development, testing и stable. На development катаются программисты на development площадке. Testing — это то, что скоро станет стабильной версией, или не станет. А stable, на него ходят клиенты.
Да, собираться и класться в репозиторий должно *только* через скрипты. Никакой ручной работы. Соответсвенно, в development попадает каждый коммит. Если коммит поломал сборку, это уже *очень* большая проблема (поломал сборку, это, в том числе и не прошли тесты, да). В stable/testing кладется тоже через скрипты, при условии коммита в эти ветки.
Да, это очень сложная система, но она позволяет добиться большой автономности.
Да, собираться и класться в репозиторий должно *только* через скрипты. Никакой ручной работы. Соответсвенно, в development попадает каждый коммит. Если коммит поломал сборку, это уже *очень* большая проблема (поломал сборку, это, в том числе и не прошли тесты, да). В stable/testing кладется тоже через скрипты, при условии коммита в эти ветки.
Да, это очень сложная система, но она позволяет добиться большой автономности.
Теперь по софту.
Естесвенно нам нужен репозиторий для исходгого кода, который бы умел хуки. git, hg, svn и далее вполне подойдет.
Далее нам нужен сборщик пакетов, скорее всего у нас все будет внутри одной архитектуры. Ну или двух. amd64/i386. Для сборки нам будет нужен pbuilder, его хватит, да. Если хочется всяких извращений, то можно пойти qemubuilder.
Далее у нас идет управление репозиторием. Для этого можно взять dak (отрыв башки) или reprepro.
Теперь это все надо связать скриптами и начать перется ☺
Естесвенно нам нужен репозиторий для исходгого кода, который бы умел хуки. git, hg, svn и далее вполне подойдет.
Далее нам нужен сборщик пакетов, скорее всего у нас все будет внутри одной архитектуры. Ну или двух. amd64/i386. Для сборки нам будет нужен pbuilder, его хватит, да. Если хочется всяких извращений, то можно пойти qemubuilder.
Далее у нас идет управление репозиторием. Для этого можно взять dak (отрыв башки) или reprepro.
Теперь это все надо связать скриптами и начать перется ☺
Напишите кто нибудь список какие вообще варианты есть не считая тех что в опросе. И можно разновидности софта (скриптов) для CSV, FTP
sftp, т. е. ftp+ssh
sftp это не ftp + ssh. Это именно новый протокол, разработаный с нуля.
да, я знаю
но по сути-то это именно ftp over ssh
но по сути-то это именно ftp over ssh
По сути это не ftp over ssh. Говоря так, вы показываете что не знаете как работает ftp и как sftp. Это совершенно разные (!) вещи.
хм, видимо мы не понимаем друг друга.
мне, как пользователю, нету принципиальной разницы в использовании sftp вместо ftp — только плюс в виде секьюрности. Хотя есть шанс, что я путаю sftp с scp ибо я опять же не вижу никакой разницы при простом копировании/переименовывании/удалении
зы я о en.wikipedia.org/wiki/SSH_file_transfer_protocol
мне, как пользователю, нету принципиальной разницы в использовании sftp вместо ftp — только плюс в виде секьюрности. Хотя есть шанс, что я путаю sftp с scp ибо я опять же не вижу никакой разницы при простом копировании/переименовывании/удалении
зы я о en.wikipedia.org/wiki/SSH_file_transfer_protocol
Разные подходы, да, возможно.
Но sftp != ftp over ssh. Как бы этого не хотелось :(
Но sftp != ftp over ssh. Как бы этого не хотелось :(
и всё-таки я не понимаю, почему ":("?
:( очень просто почему.
Вы сейчас не понимаете что такое sftp и как оно работает. Вы не понимаете что такое ftp и как оно работает. Так же вы не понимаете что такое ssh. При этом вы заявляете что sftp = ssh + ftp или ftp over ssh. Это утверждение ложно. И вы не хотите разобраться почему, вы просто продолжаете стоять на своем и ставить мне минусы. Это ваше право, да.
Но грусть мою, это все, вызывает и сильную.
Вы сейчас не понимаете что такое sftp и как оно работает. Вы не понимаете что такое ftp и как оно работает. Так же вы не понимаете что такое ssh. При этом вы заявляете что sftp = ssh + ftp или ftp over ssh. Это утверждение ложно. И вы не хотите разобраться почему, вы просто продолжаете стоять на своем и ставить мне минусы. Это ваше право, да.
Но грусть мою, это все, вызывает и сильную.
во-первых, я вам минусов не ставил
во-вторых, я утверждаю, что с точки зрения пользователя разницы между ftp и sftp нету почти никакой. Хотите убедить меня, что я неправ — так покажите в чём именно я неправ.
во-вторых, я утверждаю, что с точки зрения пользователя разницы между ftp и sftp нету почти никакой. Хотите убедить меня, что я неправ — так покажите в чём именно я неправ.
Принципиально (с точки зрения пользователя) sftp не отличается от ftp. Та же возможность удалённых операций (просмотр каталога, удаление файла). Ну, сами файлы по другому передаются, мультиплексируются по одному защищённому соединению. Принципиальной разницы нет, учитывая что ftp и ftps также должны как-то мультиплексироваться при работе через игольное ушко «жёсткого» файрвола.
у ftp/ftps есть passive и active mode, у sftp этого нет. Это *очень* веская разница в протоколе. Согласен?
Passive/active — это всего лишь особенности реализации, некритичные к целям выкладывания на сервер, о которой идёт речь в топике. Зачем такое было сделано в оригинальном несекьюрном ftp — понятно: ускорение передачи файлов за счёт отсутствия их дополнительной подготовки. Когда файлы прогоняются через шифратор, это преимущество всё равно теряется.
С помощью openssh можно запускать на удалённом конце другой ssh и, таким образом эмулировать passive (недавно на хабре была статья, как это автоматизировать с помощью ~/.ssh/config). Либо пользоваться пробросами сокетов и, таким образом эмулировать active. На худой конец, можно запускать удалённый socks сервер и через него работать обычным ftp клиентом — собственно то, что называется ftp over ssh (не sftp/ftps).
Но принципиальной разницы нет: scp, sftp, socks (и, соответственно, ftp-ssh), пробросы, удалённый логин — это всего лишь отключаемые эндпойнт-примочки к конкретной реализации шифрации/мультиплексирования сокетов. Поэтому ваша придирка к оригинальному комментатору не очень логична (и не стоит такого треда). Если мне закрыли файрволом всё, кроме исходящих http и https и я пользуюсь corkscrew для коннекта к удалённому ssh серверу, слушающему на 443 порту, — я этим не изобретаю нового протокола, хотя corkscrew — это внешняя, по отношению к [open]ssh программа. Изменяется только конфигурация эндпойнтов, а само шифрование остаётся тем же.
Проводя аналогии, если мы закручиваем винт с помощью отвёртки, входящей в мультитул, можно сказать, что мы _завинчиваем_ винт раскладным _ножом_, не называя процесс другим «ножевинчиванием» или другим словом, хотя в других ситуациях, возможно, имел бы смысл различать два процесса. И, раз уж мы завинчиваем, имеет смысл говорить именно о завинчивании, а не о забивании (мультитул может откатываться на возможность забивания, в частности, если у винта сорвана головка) и имеет смысл не уточнять, чем мы его завинчиваем — крестовой отвёрткой или плоской, хотя в мультитуле могут быть обе.
Такие вот лингвистические субботние придирки. :-)
С помощью openssh можно запускать на удалённом конце другой ssh и, таким образом эмулировать passive (недавно на хабре была статья, как это автоматизировать с помощью ~/.ssh/config). Либо пользоваться пробросами сокетов и, таким образом эмулировать active. На худой конец, можно запускать удалённый socks сервер и через него работать обычным ftp клиентом — собственно то, что называется ftp over ssh (не sftp/ftps).
Но принципиальной разницы нет: scp, sftp, socks (и, соответственно, ftp-ssh), пробросы, удалённый логин — это всего лишь отключаемые эндпойнт-примочки к конкретной реализации шифрации/мультиплексирования сокетов. Поэтому ваша придирка к оригинальному комментатору не очень логична (и не стоит такого треда). Если мне закрыли файрволом всё, кроме исходящих http и https и я пользуюсь corkscrew для коннекта к удалённому ssh серверу, слушающему на 443 порту, — я этим не изобретаю нового протокола, хотя corkscrew — это внешняя, по отношению к [open]ssh программа. Изменяется только конфигурация эндпойнтов, а само шифрование остаётся тем же.
Проводя аналогии, если мы закручиваем винт с помощью отвёртки, входящей в мультитул, можно сказать, что мы _завинчиваем_ винт раскладным _ножом_, не называя процесс другим «ножевинчиванием» или другим словом, хотя в других ситуациях, возможно, имел бы смысл различать два процесса. И, раз уж мы завинчиваем, имеет смысл говорить именно о завинчивании, а не о забивании (мультитул может откатываться на возможность забивания, в частности, если у винта сорвана головка) и имеет смысл не уточнять, чем мы его завинчиваем — крестовой отвёрткой или плоской, хотя в мультитуле могут быть обе.
Такие вот лингвистические субботние придирки. :-)
Существует два SFTP: SSH File Transfer Protocol и Simple File Transfer Protocol.
Simple File Transfer Protocol не является защищенным.
SSH File Transfer Protocol является.
И это два совершенно разных протокола.
en.wikipedia.org/wiki/SSH_file_transfer_protocol
en.wikipedia.org/wiki/Simple_File_Transfer_Protocol
Simple File Transfer Protocol не является защищенным.
SSH File Transfer Protocol является.
И это два совершенно разных протокола.
en.wikipedia.org/wiki/SSH_file_transfer_protocol
en.wikipedia.org/wiki/Simple_File_Transfer_Protocol
Думаю стоило в дополнение к FTP упомянуть WebDAV.
Стационар (дома):
— В vim подключил плагины project и netrw.
Asus eee pc (всегда с собой):
— Поставил сервер. Разрешил доступ через ssh.
Сервер (далеко-далеко):
— Пофайлово (задумываюсь о маленьком скрипте для вима).
Итого:
Еее всегда доступен, его можно принести, показать (можно подключить к монитору/проектору), на нем можно в случае чего поправить «на месте».
Чтобы вечно не портить зрение о его маленький монитор решаю проблему синхронизации удаленным доступом с домашнего компа (когда я дома) с большим монитором и привычной клавиатурой.
Таким образом постоянное туда-сюда с сервера и обратно отбрасывается. Конечный вариант — в сеть и там его уже не править, только на еее.
Насколько это удобно судить рано, недавно так начал работать. Пока что все нравится.
Интересно услышать плюсы-минусы, кому моя идея понравилась или нет :)
— В vim подключил плагины project и netrw.
Asus eee pc (всегда с собой):
— Поставил сервер. Разрешил доступ через ssh.
Сервер (далеко-далеко):
— Пофайлово (задумываюсь о маленьком скрипте для вима).
Итого:
Еее всегда доступен, его можно принести, показать (можно подключить к монитору/проектору), на нем можно в случае чего поправить «на месте».
Чтобы вечно не портить зрение о его маленький монитор решаю проблему синхронизации удаленным доступом с домашнего компа (когда я дома) с большим монитором и привычной клавиатурой.
Таким образом постоянное туда-сюда с сервера и обратно отбрасывается. Конечный вариант — в сеть и там его уже не править, только на еее.
Насколько это удобно судить рано, недавно так начал работать. Пока что все нравится.
Интересно услышать плюсы-минусы, кому моя идея понравилась или нет :)
deb-пакеты очень удобны, если на продакшне debian.
Ну или rpm, если redhat'оподобный дистрибутив.
Ну или rpm, если redhat'оподобный дистрибутив.
Деб пакеты означают, что апгрейд должен делать только root (или пользователь-sudoer). Или вы используете какое-то решение с дебами в отдельном каталоге? Если да, то какое, — интересно.
Да, только пользователь с привилегиями.
Но это снижает возможность ошибки.
Но это снижает возможность ошибки.
Предпологается что под решение выделяется отдельная машина (и не одна) или отдельно vps.
capistrano
а как же rsync?
samba.anu.edu.au/rsync/ — rsync is an open source utility that provides fast incremental file transfer.
о таком забыли!!!
samba.anu.edu.au/rsync/ — rsync is an open source utility that provides fast incremental file transfer.
о таком забыли!!!
Rails + Capistrano + git
Весьма удобно.
Весьма удобно.
TFS
ViceVersa — универсальный способ синхронизации папок, копирования, бекапа, поддержки архива. Можно создавать задания синхронизации через встроенный планировщик или по событию изменения файла.
Есть возможность фильтрации по маске. Вместо удаления можно складывать старые версии файлов. Копирование может осуществляется через ShadowCopy
Z использую для анимационных проектов с 100Gb+ гигабайтами данных).
Минус — это не SVN, нет коммит etc. Это именно апдейт + синхронизация
Есть возможность фильтрации по маске. Вместо удаления можно складывать старые версии файлов. Копирование может осуществляется через ShadowCopy
Z использую для анимационных проектов с 100Gb+ гигабайтами данных).
Минус — это не SVN, нет коммит etc. Это именно апдейт + синхронизация
Mercurial
в основном по ftp, а вообще да — тоже очень интересует этот вопрос и возможные решения
сейчас просто идем по SSH и делаем git pull + запускаем скрипт migrate если обновилась БД
но хочется все это упаковать в деплоилку как у рубистов
но хочется все это упаковать в деплоилку как у рубистов
> другой вариант
на лайве вертится bzr бранч. Собственно, мерж.
на лайве вертится bzr бранч. Собственно, мерж.
НЛО прилетело и опубликовало эту надпись здесь
MAVEN2 + BAMBOO — ОЧЕНЬ УДОБНАЯ СВЗЯКА
Когда-то давно использовали такую схему:
Ант собирает проект, запускает тесты, создает тэг в репозитарии, пакует build-директорию, коммитит его в тэг и заливает на удаленный сервер. Далее она распаковывается и заменяет собой старую. Все занимало около 5 минут.
Но это подмножество варианта «через SSH».
Ант собирает проект, запускает тесты, создает тэг в репозитарии, пакует build-директорию, коммитит его в тэг и заливает на удаленный сервер. Далее она распаковывается и заменяет собой старую. Все занимало около 5 минут.
Но это подмножество варианта «через SSH».
Последнее время только rsync
Sharepoint Solutions
IBM Rational ClearCase
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поддержка, апдейты, production, синхронизация версий.