система така :
Є dev server на якому розміщений головний репозиторій.
Після того як ми зробили push локального репозиторію, дані попадають на дев сервер
Дальше з цього сервера розкидуємо зміни по інших серверах.
Якщо у вас 1н сервер то з git-hook цілком хороший варіант. Можна додати ще фішку що перше проганяємо тести а дальше уже закидуємо дані куди треба.

П.С. Синхронізуємо через rsync

До речі, для тестового сервера завжди треба передбачати можливість створення snapshots. Якщо якийсь тест пройшов невдало, то легко можна відкотитись до останнього снепшота. І навпаки - якщо тест пройшов успішно і доходить справа до впровадження цих же змін на продакті, то робиться черговий снепшот.

Я у себе на локальній віртуалці роблю тестовий сервак...

Щось у вас взагалі слабо з CI/CD... Хоча цим страждають багато починаючих web пехапе студій.

Не треба винаходити колесо
Почитайте про continuous deployment/delivery.

Я особисто використовую такий варіянт:
0) Уся розробка відбувається у кожного розробника у його локальному середовищі. Середовища НЕ використовуються розробниками. Середовище інтеграційне для тестіів qa та acceptance tests.
00) Деплоймент на продакшн це останній крок циклу/ітерації розробки. Ніколи ніхто не робить деплой з локального середовища.

1) Git
2) Gitflow: master бранч лише для продакшн коду/релізів; develop для integration environment.
3) Jenkins
4) Дженкінс наслуховує зміни у цих бранчах і окремо їх будує
5) через плагін налаштовую delivery pipeline що робить деплой різних білдів на різні середовища: master на продукцію, develop на тестове середовище (nightly builds)
6) на стороні серверів доставку очікують баш скрипти, що далі виконують деплой.

Може бути у нагоді: http://www.tutorialspoint.com/jenkins/j … oyment.htm

А давайте почнемо з того, що єдина моя порада Вам була це почитати про continuous deployment/delivery, ок?  Я не експерт і все, що написано нижче - метод, та констрейнти, котрі прийшли з досвіду. Вам ніхто не пропонував його використовувати. Якщо Вас так дуже цікавить мій досвід, шукайте на linkedin.

Така впевненість теж, як і у Вас, з особистого досвіду. На жодному нормальному проекті де я був, ніколи ніхто не робив деплою зі свого локального середовища. Більше того, як Ви й зазначили, у більшості випадків девелопер навіть не має "фізичного" доступу до продукції. Я не теоретизую, я вважаю що має бути розділення відповідальності, автоматичні білди та визначений воркфлоу, який не полягає на "Я просто зроблю маленьку зміну у конфігу на проді і це нічого не зламає". Є навіть такі думки, що девелопер НЕ хоче мати доступу взагалі: якщо щось піде на проді не так, то більше вірогідність, що це не моя вина. [1] Якщо Вас цікавить холівар на цю тему, тут [2] достатньо інфи чому доступ має бути закритий.

Я тут не свою точку якусь нав'язуюсь. Як і сказав, не треба вигадувати колесо. Є усталені, перевірені воркфлоу для CI/CD. Є спеціальні інструменти, які вже існують з десяток років (Hudson (->Jenkins) Initial release 2005y). Залишилося лише їх собі прикрутити.

[1] http://stackoverflow.com/a/4147591/2180005
[2] http://stackoverflow.com/questions/4147 … production

reverse2500 можна посилання на DVCS і як ви використовуте це?

iovchynnikov у нашому проджекті після кожного коміту проганяються тести. Залишилось робити деплой при успішному білді - якщо гілка мастер. Або якщо тест провалився відправляти нотіфікейшин.