У нас є додаток для електронної комерції, який ми розробляємо в нашій компанії. Це досить стандартний додаток LAMP, який ми розробляли і вимикали вже близько 3 років. Ми розробляємо додаток на тестовому домені, тут додаємо нові функції та виправляємо помилки тощо. Нашим відстеженням помилок та розробкою функцій керує всередині розміщеного рішення про підрив (undeudle.com). Як повідомляється про помилки, ми робимо ці виправлення на тестовому домені, а потім здійснюємо зміни до svn, коли ми раді, що помилка була виправлена. Ми дотримуємось цієї ж процедури з додаванням нових функцій.
Варто вказати на загальну архітектуру нашої системи та програми на наших серверах. Кожен раз, коли розробляється нова функція, ми передаємо це оновлення на всі сайти, використовуючи наш додаток (завжди це сервер, яким ми керуємо). Кожен сайт, що використовує нашу систему, по суті використовує абсолютно однакові файли для 95% кодової бази. На кожному веб-сайті є кілька папок, які містять файли, призначені для цього сайту - файли / зображення css тощо. Крім того, відмінності між кожним сайтом визначаються різними налаштуваннями конфігурації в базі даних кожного сайту.
Це переходить до власне розгортання. Як і коли ми готові внести якесь оновлення, ми запустимо команду на сервері, на якому знаходиться тестовий сайт. Це виконує команду копіювання (cp -fru / testingite / / othersite /) і проходить кожну силу vhost, оновлюючи файли на основі зміненої дати. Кожен додатковий сервер, на якому ми розміщуємо, має vhost, до якого ми rsync-кодуємо виробничу базу даних, а потім повторюємо процедуру копіювання на всіх сайтах цього сервера. Під час цього процесу ми переміщуємо файли, які не хочемо перезаписати, переміщуючи їх назад, коли копія завершена. Наш скрипт розгортання виконує ряд інших функцій, таких як застосування команд SQL для зміни кожної бази даних, додавання полів / нових таблиць тощо.
Ми все більше стурбовані тим, що наш процес недостатньо стабільний, не є стійким до відмов, а також є чимось брутальним методом. Ми також усвідомлюємо, що не використовуємо найкраще підрив, оскільки у нас є позиція, коли робота над новою функцією заважає нам виконувати важливе виправлення помилок, оскільки ми не використовуємо гілки або теги. Також здається неправильним, що у нас так багато реплікації файлів на наших серверах. Ми також не можемо легко виконати відкат на тому, що ми тільки що розгорнули. Ми виконуємо різницю перед кожним розгортанням, щоб ми могли отримати список файлів, які будуть змінені, тому ми знаємо, що було змінено після, але процес відкату все ще буде проблематичним. З точки зору бази даних я почав розглядати dbdeploy як потенційне рішення. Хоча ми насправді хочемо, це деякі загальні вказівки щодо того, як можна покращити управління файлами та розгортання. В ідеалі ми хочемо, щоб управління файлами було більш тісно пов'язане з нашим сховищем, щоб згортання / відкат було б більш підключеним до svn. Щось на зразок використання команди експорту, щоб переконатися, що файли сайту однакові як файли репо. Було б також добре, хоча, якщо рішення, можливо, також зупинить реплікацію файлів навколо наших серверів.
Ігноруючи наші нинішні методи, було б дуже добре почути, як інші люди підходять до тієї ж проблеми.
підсумовувати ...
- Який найкращий спосіб змусити файли на кількох серверах синхронізуватися зі svn?
- Як слід запобігти реплікації файлів? символічні посилання / щось інше?
- Як слід структурувати наше репо, щоб ми могли розробляти нові функції та виправляти старі?
- Як слід запускати перемотки / відкати?
Спасибі заздалегідь
Редагувати:
Нещодавно я прочитав багато хороших речей про використання Фінга та Капістрано для таких завдань. Чи може хто-небудь дати більше інформації про них і наскільки вони були б хороші для такого роду завдань?