Syncman — развертывание и синхронизация проектов на удаленном сервере

[webus]

Последние коммиты в проекте были 2 года назад. Не означает ли это что проект заброшен?

[vasiatka]

Тут логика такая. Если вас все устраивает — отлично, пользуйтесь. Нужно исправить ошибки или добавить функциональности — милости просим, новизна приветствуется. Просто текущая функциональность вполне устраивает пользователей проекта.

[drunken]

какие только костыли не вспоминают, лишь бы configuration management не изучать.

[vasiatka]

При чем здесь Configuration management? Syncman не решает его задачи. Его цель — уже подготовленный (возможно, с использосанием CM) программный продукт отправить на сервер.

[drunken]

именно, потому что configuration management должен решать задачи деплоя.

[vasiatka]

CM — это методология, и она никак не поможет выгрузить данные на сервер. Для этого потребуется некий инструмент.

[DeTerminator]

Это все здорово, но:
— как делать откат?
— что видят юзеры сайта в момент синхронизации? (половина файлов старая, половина новая)

[vasiatka]

В настройках проекта можно указать, опцию history=true. Я ей никогда не пользовался.
Но работает вроде бы как-то так:
Сервер натравливается на символьную ссылку. Эта ссылка указывает на текущую версию проекта.
Для каждой синхронизации создается папка, обозначенная датой. Из текущей копии все переписывается в эту папку. Затем символьная ссылка заменяется ссылкой на эту новую папку. И синхронизация выполняется уже в новой папке. При необходимости отката — жмете кнопку «откатить изменения», и ссылка опять указывает на старую папку. Работает, к сожалению только для файлов.

Как правило, все происходит быстро (rsync копирует только изменившиеся файлы) и ничего показывать не надо. Но чисто технически в presync_cmd можно установить для nginx редирект на статическую страницу, а в postsync_cmd — соответственно, его убрать.

[Anonym]

Хотелось бы увидеть сравнение с Jenkins.