Пропоную до розгляду такої міні it-кейс:
Сам я дизайнер сайтів, але в силу зрозумілих обставин доводиться в 70% випадків після цього (дизайну) робити клієнтам сайти «під ключ» ( «о, як круто, що ми знайшли програміста» :).
Оскільки сайти не великі і підпадають під поняття «промо -» / корпоративні в лайт-комплектації (без складних інтеграцій і т.п.) мною була замовлена фрілансеру самописна цмс-ка з набором найнеобхідніших функцій.
Зараз у цій системи близько 200-250 установок (за 3 роки роботи), з моменту розробки по суті ніяких глобальних доробок і ітерацій не робилося ... В ній за цей час розрізнено (в різних проектах) було виправлено і залатати багато дірок, багів, дописалися нові модулі-функції, оновився інтерфейс адмінки. Зараз, нарешті, у мене є цей код в одному місці.
1. є паролі до всіх сайтів, де хотілося б оновити код у вигляді логін: пароль @ сервер.
2. є остання версія коду, яку хотілося б всім разом оновити-викотити (розгалужена система папок з вкладеними в них скриптами). Логічно припустити, що тупо знести-перезаліть не пройде, тому що в тих же папках не нульовий рівня вкладеності лежать шаблони, кеши сторінок, картинки і т.п.
3. Бюджет на це мінімальний (вірніше його немає, просто хочеться сумління зовсім не турбуючись зробити це, тому готовий оплатити апгрейд зі своєї кишені).
Завдання - проста як 2 рубля:
Оновити автоматом все і відразу до останньої версії :)
Буду дуже вдячний за будь-які ідеї, лінки, поради, що почитати, приклади готових рішень і софта.
Подивіться на capistrano. По-моєму саме те, що вам потрібно. Що ні на PHP (чомусь мені здається, що ваша CMS на ньому) - не лякайтеся, освоїти синтаксис куди простіше, ніж синтаксис конфігов «нативного» Phing, призначеного для тих же цілей. Ruby доведеться встановлювати тільки на локальній машині. Документація відмінна, але англійською. Приклади використання, в тому числі і з PHP проектами, є і на Хабре.
З питання організації самого процесу - складно радити не знаючи особливостей движка і можуть / повинні бути на різних сайтах відмінності в коді і інших «як би» сайтовонезавісімих файлах і схеми БД. Якщо можуть / повинні, то порадив би познайомитися з системами контролю версій (я особисто віддаю перевагу Mercurial, але більш популярний Git), втім познайомитися з ними варто в будь-якому випадку. І організувати структуру репозиторіїв / гілок приблизно так: основна гілка / репозиторій - загальний код (+ дефолтний дизайн), відгалуження від неї / клони - код кожного з сайтів (туди ж можна помістити сайтоспеціфічние шаблони, картинки і т. П.). При наступному оновленні загального коду по черзі Мержа (поєднуєте) код гілок / клонів з основним (мабуть для вашого випадку краще клони) - щось автоматично об'єднається, десь руками конфлікти дозволити доведеться і заливаєте на сервера (по хорошому треба ще й тестувати попередньо, але схоже не ваш випадок).
Бюджет нульовий, але пару-трійку днів витратити доведеться на вивчення і організацію. Зате потім будь-яка правка (в тому Іслі зміна схеми даних) в основному репозиторії буде поширюватися на всі сервера однією командою Капістрана, залишаючи в недоторканності їх локальні нюанси. Повірте - воно того варте!
Я б запропонувала завести відкритий (або закритий?) Репозиторій з цієї цмс і просто сповіщати клієнтів про оновлення. Кому треба - нехай самі оновлюються.