Яка у вас краща стратегія розгортання php? [зачинено]

Я починаю новий проект в PHP, і я хотів би отримати відгуки від інших розробників про їх переважну стратегію розгортання PHP. Я хотів би трохи автоматизувати речі, щоб після внесення змін їх можна швидко перенести на сервер розробки або виробництва.

У мене є досвід розгортання використання Capistrano з Ruby, а також деякі базові сценарії оболонки.

Перш ніж я зануритися в голову першим самостійно, було б чудово почути, як інші підходили до цього у своїх проектах.

Додаткова інформація

В даний час розробники працюють над локальними установками сайту і здійснюють зміни в сховищі субверсій. Початкові розгортання здійснюються шляхом експортування тегованого випуску зі svn та завантаження його на сервер.

Додаткові зміни, як правило, вносяться по частках шляхом завантаження змінених файлів вручну.

Для PHP - це шлях до SVN із скриптами збірки Phing . Фінг схожий на ANT але написаний на PHP, що значно спрощує розробникам PHP змінити їхні потреби.

Наш режим розгортання такий:

• Усі працюють на одному локальному сервері на роботі, кожен розробник має замовлення на своїй машині і додому.
• Здійснює запуск гачка після фіксації, який оновлює сервер налаштування.
• Тести проводяться на етапі сервера, якщо вони проходять - продовжують.
• Сценарій збірки Phing запускається:
• Знімає виробничий сервер, перемикаючи домен на сторінку "У стадії розробки"
• Запускає оновлення SVN на замовлення виробництва
• Запускається сценарій дельти схеми
• Працює тести
• Якщо тести не вдається - запустіть сценарій відкату
• Якщо тести пройдуть, сервер повертається до замовлення виробництва

Також є phpUnderControl , який є сервером безперервної інтеграції. Я не вважаю дуже корисним для чесних веб-проектів.

Наразі я розгортаю PHP за допомогою Git . Просте виробництво git push - це все, що потрібно для оновлення мого виробничого сервера з останньою копією від Git. Це легко і швидко, тому що Git досить розумний, щоб надсилати лише розрізнення, а не весь проект заново. Це також допомагає зберегти зайву копію сховища на веб-сервері у випадку збою апаратного забезпечення на моєму кінці (хоча я також натискаю на GitHub, щоб бути безпечним).

Ми використовуємо Webistrano , веб-інтерфейс для Capistrano, і дуже задоволені цим.

Webistrano дозволяє здійснювати багатоступеневі, багатосередовищні розгортання від SVN, GIT та інших. Він має вбудовану підтримку відкату, підтримку окремих ролей сервера, таких як веб, db, додаток тощо, і розгортається паралельно. Це дозволяє переосмислити параметри конфігурації на декількох рівнях, наприклад, на етапі, і записувати результати кожного розгортання, необов'язково надсилаючи їх.

Незважаючи на те, що Capistrano та Webistrano є додатками Ruby, синтаксис "рецептів" розгортання є простим і потужним, щоб зрозуміти будь-якого програміста PHP. Спочатку Capistrano був побудований для проектів Ruby on Rails, але легко вміщує проекти PHP.

Після налаштування це навіть досить легко використовувати непрограмістів, таких як тестери, що розгортають поетапну версію.

Для забезпечення найшвидшого розгортання ми встановили метод fast_remote_cache , який оновлює кеш- файли svn робочої копії на віддаленому сервері, а потім твердо посилається на результат.

Я використовую Apache Ant для розгортання різних цілей (dev, QA та live). Ant призначений для роботи на розгортанні Java, але забезпечує досить корисне загальне рішення для розгортання довільних файлів.

Синтаксис файлу build.xml досить легко вивчити - ви визначаєте різні цілі та їх залежності, які запускаються при виклику програми мурашника в командному рядку.

Наприклад, у мене є цілі для dev, QA та live, кожна з яких залежить від цілі cvsbuild, яка перевіряє останню редакцію голови з нашого CVS-сервера, копіює відповідні файли в каталог збирання (використовуючи тег набору файлів), а потім rsyncs збирає каталог на відповідний сервер. Є кілька химерностей, щоб навчитися, і крива навчання не зовсім плоска, але я роблю це таким чином роками без проблем, тому я рекомендую це для вашої ситуації, хоча мені цікаво, які інші відповіді я я побачу в цій темі.

Я роблю речі вручну за допомогою Git. Одне сховище для розробки, яке потрапляє git push --mirrorна загальнодоступне репо, а сервер в реальному часі - це третє репо, витягнуте з цього. Я вважаю, що ця частина така ж, як і ваша власна установка.

Велика різниця полягає в тому, що я використовую гілки майже для кожної зміни, над якою працюю (у мене зараз близько 5), і, як правило, перегортаюсь між ними. Основна гілка не змінюється безпосередньо, за винятком об'єднання інших гілок.

Я запускаю живий сервер прямо з ведучої гілки, і коли я закінчу з іншою гілкою і готовий об'єднати її, на деякий час переверніть сервер до цієї гілки. Якщо він зламається, його повернення до майстра займає секунди. Якщо він працює, він об'єднується в головний і живий код оновлюється. Я припускаю, що аналогією цього в SVN було б створення двох робочих примірників і вказівка ​​на пряму трансляцію через симпосилання.

Я знаю, що Phing вже згадувалося кілька разів, але мені дуже пощастило з phpUnderControl . За нас ми

1. Перевірте окремі копії гілок на місцевих машинах
2. Гілки випробовують, а потім об'єднують у магістраль
3. PhpUnderControl автоматично будує комісії до Trunk, виконує тести та створює всю документацію, застосовує дельти бази даних
4. Магістраль проходить через тестування якості та потім об'єднується в нашу стабільну філію
5. Знову ж таки, phpUnderControl автоматично створює програму Stable, запускає тести, створює документацію та оновлює базу даних
6. Коли ми готові приступити до виробництва, ми запускаємо сценарій rsync, який створює резервну копію виробництва, оновлює базу даних, а потім підштовхує файли вгору. Команда rsync викликається вручну, щоб ми переконалися, що хтось спостерігає за акцією.

Альтернативою домашнім сценаріям розгортання є розгортання на платформі як послуга, яка абстрагує багато того, що працює для вас. PaaS, як правило, пропонує власний інструмент розгортання коду, а також масштабування, стійкість до відмов (наприклад, не виходить з ладу при збої обладнання), і, як правило, чудовий набір інструментів для моніторингу, перевірки журналу і т.д. відома хороша конфігурація, яка буде постійно оновлюватися з часом (один менший головний біль для вас).

Я б порекомендував PaaS - dotCloud , крім PHP ( див. Їх швидкий старт PHP ), він також може розгорнути MySQL, MongoDB і цілу купу додаткових сервісів. У ньому також є приємні смаколики, такі як розгортання з простою, швидкий відкат, повна підтримка SSL та websocket тощо.

Звичайно, я трохи упереджений, оскільки працюю там! Інші параметри, які варто перевірити, окрім dotCloud, - це Pagodabox та Orchestra (зараз це частина Engine Yard).

Сподіваюся, це допомагає!

Соломон

Те, що ви автоматично і сліпо приймаєте зміни зі сховища на сервери виробництва, звучить небезпечно. Що робити, якщо ваш скоєний код містить помилку регресії, тож ваша виробнича програма стає глюкозною?

Але, якщо вам потрібна система безперервної інтеграції для PHP, я вважаю, що Phing - найкращий вибір для PHP. Я сам не перевіряв це, хоча я вкладаю ручний спосіб, наприклад, scp.

Я запізнююся на вечірку, але думав, що поділюсь нашими методами. Ми використовуємо Phing з Phingistrano , що забезпечує функцію Phing, подібну Capistrano, за допомогою попередньо вбудованих файлів збірки. Це дуже круто, але працює лише в тому випадку, якщо ви використовуєте Git на даний момент.

У мене на сервері працює робоча копія відділення випуску SVN. Оновлення сайту (коли немає змін схеми) так само просто, як і команда оновлення SVN. Мені навіть не доводиться брати сайт офлайн.

Phing - це, мабуть, найкраща ставка, якщо ви можете витримати біль конфігураційних файлів xml. У рамки Symfony є власний порт рейк (pake), який працює досить добре, але досить щільно поєднаний з рештою Symfony (хоча ви, ймовірно, могли їх розділити).

Ще один варіант - використовувати Capistrano. Очевидно, він не так добре інтегрується з PHP, як це робиться з Ruby, але ви все одно можете використовувати його для багатьох речей.

Нарешті, ви завжди можете писати сценарії оболонки. Поки що це я зробив.

http://controltier.org/wiki/Main_Page

ми будемо використовувати його для розгортання та обслуговування декількох серверів.

Пізніше на рік, але ... У моєму випадку розгортання не є автоматичним. Мені здається небезпечним розгортання коду та запуск сценаріїв міграції баз даних автоматично.

Натомість підривні гачки використовуються для розгортання лише для тестування / постановки сервера. Код розгортається у виробництві наприкінці ітерації, після проходження тестів та впевненості, що все буде працювати. Для самого розгортання я використовую Makefile на замовлення, який використовує rsync для передачі файлів. Makefile також може запускати сценарії міграції на віддаленому сервері, призупиняти / відновити веб-сервери та сервери баз даних.

На моїй роботі я та моя команда розробили орієнтацію на Phing для розгортання capistrano, і ми також включили деякі корисні товари, доступні у phing, такі як тестування PHPUnit, phpcs та PHPDocumentor. Ми зробили це git repo, який можна додати до проекту як підмодуль в git, і він працює дуже добре. Я додав його до декількох проектів, і це досить модульно, щоб легко було змусити його працювати з будь-яким проектом у будь-якому з кількох наших середовищ (постановка, тестування, виробництво тощо).

За допомогою скриптів збирання phing ви можете запускати їх з командного рядка вручну, і я також мав успіх в автоматизації процедур збирання / розгортання з Хадсоном і тепер Jenkins ci.

Зараз я не можу розміщувати жодних посилань, оскільки РЕПО ще не є загальнодоступним, але мені сказали, що ми інколи скоро відкриватимемо його, тому, будь ласка, не соромтесь зв’язатися зі мною, якщо вам це цікаво або якщо у вас є будь-які запитання щодо автоматизації розгортання за допомогою phing та git.

Я думаю, спосіб розгортання SVN не дуже хороший. Тому що:

Вам потрібно відкрити доступ до SVN для всього світу

є багато .svn у виробничих веб-серверах

Я думаю, що Phing створити гілку + поєднати всі js / css + замінити конфігурацію стадії + завантаження ssh на всі www-сервери - це кращий спосіб.

ssh до 10 www сервера і svn up - це також неприємності.