Как манифест приложения «Двенадцать факторов» применяется к проектам PHP?

Question

Я только что прочитал Приложение с двенадцатью факторами , которое выглядит как довольно полный набор правил, применимых в веб-приложении.Он использует python или rails в своих примерах, но никогда не php ... Мне было интересно , какие факторы манифеста могут быть применены к проектам PHP и как ?

Спасибо

Answer 1

Краткий ответ:

Все пункты относятся к PHP , поскольку манифест приложения из двенадцати факторов относится именно к веб-приложениям.

PHP очень трудно справиться с двенадцатью факторами, в частности, в пунктах 2, 7, 8 9 (как побочный эффект 7 и 8) и 12 (частично).На самом деле, это первый действительно обоснованный аргумент, который я услышал во всей разглагольствованию «PHP sucks», который распространен в сообществах Ruby и Python (не поймите меня неправильно, я думаю, что Ruby и Python - лучшие языки, но я не ненавижуPHP, и, безусловно, ненавижу «мой язык лучше».)

Сказав это, возможно, ваш PHP-проект не является веб-приложением или SaaS, а просто простым веб-сайтом, так что вы можете простопосчитайте, что двенадцать факторов не нужны.

Длинный ответ: Точечный анализ будет:

1. Кодовая база: не проблема

2. Зависимости: работа PEAR идет вразрез с этой точкой, поскольку зависимости от Pear устанавливаются во всей системе, и обычно это не так.иметь сводный манифест, чтобы объявить их.Также обычно для установки PHP требуется, чтобы вы добавляли пакеты к вашей установке ОС, чтобы получить некоторые доступные библиотеки.Наконец, AFAIK, в PHP нет инструмента для обеспечения изоляции, такого как "virtualenv", "rbenv" или "rvm" (или, если он существует, не популярен среди сообщества PHP) Редактировать: Композитор (http://getcomposer.org/), кажется, делает правильно в отношении зависимостей, он все еще не изолирует версию PHP, но для всего остального все должно быть в порядке.

3. Config: некоторые PHP-фреймворки не очень хорошо подходят для этого, но, безусловно, есть и другие, которые преуспевают, так что это не недостаток самой платформы

4. Службы поддержки: не должно быть большой проблемой, хотя, возможно, придется немного взломать некоторые фреймворки, чтобы управлять сервисами как ресурсами

5. Сборка, выпуск, запуск: это полностью применимо к PHP, поскольку это определенно не касается только «компиляции». Можно утверждать, что несколько проектов и хостинговых платформ в сообществе PHP злоупотребляют прямым FTP и т. Д., Но это не недостаток самого PHP,и нет реВсе препятствия для правильной работы с этим элементом.

6. Процессы: Это определенно относится к PHP.PHP вполне способен запускать процессы без сохранения состояния (упор делается на слово без сохранения состояния), и на самом деле несколько сред делают вашу жизнь прощеНапример, Symfony обеспечивает готовое управление сессиями с помощью memcached или хранилища базы данных вместо обычных сессий

7. Привязка порта: В этот момент все простов основном требует обратного прокси-сервера и встроенного в приложение реального веб-сервера, а не отдельного компонента.Это ставит PHP в очень сложное положение.Несмотря на то, что есть способы сделать это (см. Ответ об использовании PHP в качестве FastCGI), это определенно не самый распространенный и не лучший поддерживаемый способ обслуживания приложения PHP, как в других сообществах (например, Ruby, Node.js).

8. Процессы: Это не невозможно в PHP.Однако некоторые элементы ставят PHP в трудное положение для соблюдения.А именно отсутствие хорошей поддержки пунктов 6 и 7;тот факт, что PHP API для порождения новых процессов не очень приятен для работы;и особенно то, как mod_php Apache работает со своими работниками (что на сегодняшний день является самой распространенной схемой развертывания для PHP)

9. Доступность: Если вы используете правильные инструменты, естьPHP ничего не мешает создавать быстрые, одноразовые, аккуратные веб-и рабочие процессы.Однако я полагаю, что поскольку базовую модель процесса сложно реализовать в соответствии с пунктами 7 и 8, то 9 становится немного громоздким в качестве побочного эффекта

10. Соотношение между разработчиками и разработчиками: Это очень независимый от платформы, и я бы сказал, один из самых трудных для правильной работы.PHP не является исключением из этого правила, но он также не имеет особых препятствий.На самом деле большинство инструментов, названных в манифесте, могут быть применены к проекту PHP

11. Журналы: Полное отсутствие привязки вашего приложения к системе журналов в среде выполнениявыполнимо на PHP

12. Административные процессы: Самым важным недостатком PHP в этом вопросе является отсутствие оболочки REPL.В остальном, некоторые фреймворки, такие как Symfony, позволяют программировать задачи администратора (например, перенос баз данных на основе Doctine) и запускать их в той же среде, что и ваша «обычная» веб-среда.

Поскольку сообщество PHP развивается, возможно, оно уже исправило некоторые из упомянутых ошибок.

Answer 2

Сборка, выпуск, запуск: Применимо к скомпилированному коду, чего нет в PHP.Таким образом, этот момент не является тем, на что вам нужно обратить внимание.

Я не претендую на какие-либо полномочия по этим 12 факторам, но мое прочтение этого раздела заключается в том, что автор не согласится.Речь идет не только о компиляции, но и об управлении зависимостями как в маленьких (снимок кода), так и в больших (любые библиотеки, которые использует код).

Представьте, что вы новый разработчик, и они говорят: «Хорошо, это пользовательское приложение php, так что ...

a) Пользовательский код - это на самом деле два подпроекта, которые находятся вrepo A и repo B.

b) Вам нужно будет создать макет каталога следующим образом, а затем

c) проверить код для каждого подпроекта в этом подкаталоге и этом подкаталоге.

d) Вам также понадобятся три библиотеки PHP с открытым исходным кодом:

версия 3.1 библиотеки Foo, версия 2.3 библиотеки Bar и версия 5.6 библиотеки Bat.

e) загрузите их со своих сайтов домашних проектов и распакуйте их, затем скопируйте их в этот каталог, этот каталог и другой каталог.

f) затем вам нужно будет настроить эти конфигурации во внешней библиотеке,

g) и эти конфиги в наших двух проектах с пользовательским кодом.

h) как только все будет сделано, tar / gzip все это, загрузите его на сервер QA и распакуйте вhtdocs.

В этом наборе нет компиляциишаги, но вы можете поспорить, что есть много зданий.

Настройка всего этого и работа - это шаг сборки.

Использование tar / gzip для создания снимка рабочей сборки - это шаг выпуска.

SCP 'вставка / распаковка его в каталог htdocs сервера QA - это шаг времени выполнения.

Можно сказать, что некоторые из этих шагов не нужны - библиотеки следует развертывать на системном уровне и просто импортировать.Я бы сказал, что с сайта 12factors.net автор предпочитает импортировать их уникально и индивидуально для приложения.Это позволяет избежать проблем с версионированием зависимостей за счет увеличения дискового пространства (не то, чтобы это кого-то беспокоило).Существуют и другие трудности в управлении всеми этими зависимостями как локальными для приложения, но в этом суть схемы build / release / runtime.

Answer 3

Возможно, это изменилось с тех пор, как вы его прочитали - сейчас есть несколько примеров PHP, хотя некоторые из них кажутся отрицанием концепции двенадцати факторов.

Один из способов, которым обычные сайты mod_php нарушают двенадцатикратный фактор, - VII. Порт привязки . Из манифеста:

Приложение с двенадцатью факторами является полностью автономным и не требует внедрения веб-сервера в среду выполнения для создания веб-службы. Веб-приложение экспортирует HTTP как службу, связываясь с портом и прослушивая запросы, поступающие на этот порт.

Тем не менее, apache / php можно убедить в этом мировоззрении примерно так:

https://gist.github.com/1398498

Не идеально, но это работает по большей части. Чтобы проверить это, установите мастера:

мастер установки драгоценных камней

затем запустите его в каталоге, в который вы клонировали сущность:

Форман старт

затем посетите

http://localhost:5000/foo

Answer 4

НЕ ПРИНИМАЙТЕ ЭТУ ПОЧТУ В КАЧЕСТВЕ ССЫЛКИ, ЭТО БЫЛО ПИСАНО В 2011 ГОДУ, МНОГИЕ ВЕЩИ ИЗМЕНИЛИСЬ С ПОСЛЕ ... МИР ПРОГРАММИРОВАНИЯ В ПОСТОЯННОЙ ЭВОЛЮЦИИ. ТОЧКА ЗРЕНИЯ 2011 ГОДА НЕ ДОЛЖНА ДЕЙСТВОВАТЬ В 2018 ГОДУ.

---

Я просто прочитал несколько строк каждого пункта, и вот мой анализ документа:

1. Кодовая база : У каждого, php или нет, должна быть кодовая база даже для небольших проектов

2. Зависимости : PHP использует библиотеки включений и кода, которые вы всегда сможете легко перенести, просто скопировав код на сервер. Иногда вы используете PEAR, а затем, если сервер не поддерживает его, вы должны скопировать и установить Pear вручную. Я использую Zend Framework большую часть времени, поэтому он просто копирует код фреймворка с загрузкой по ftp.

3. Config : Обычно приложения php имеют доступный для записи файл конфигурации, в который вы сохраняете конфигурации. Где вы храните, это ваш выбор разработчика, но обычно он находится либо в корне вашего приложения, либо в папке settings / config.

4. Службы поддержки : PHP большую часть времени использует службы поддержки, такие как MySQL. Другие распространенные сервисы в зависимости от вашего приложения - это Twitter и Facebook. Вы используете их API для связи с ними и хранения / извлечения данных для работы.

5. Сборка, выпуск, запуск : Применимо к скомпилированному коду, чего нет в PHP. Так что на этот момент вам не нужно смотреть.

6. Процессы : HTTP не имеет состояния и обслуживается, поэтому у вас обычно нет процесса, кроме веб-сервера. Это не совсем так, поскольку веб-сервис может быть связан с приложениями, которые вы упаковываете или создаете для него. Но ради стандартов вам обычно не нужно использовать процессы в мире Интернета.

7. Привязка порта : PHP вообще не применяется к привязке порта, потому что это не процесс, который подключается к адресу, Apache, NGinx или Lighttpd делает это за вас. Чтение № 6/7 позволяет мне понять, что веб-сайт никогда не может быть приложением с двенадцатью факторами.

8. Параллелизм : Опять же, этот пункт касается процессов, которые не применяются к веб-страницам PHP. Этот пункт относится к серверу, обслуживающему контент.

9. Одноразовость : В этом пункте обсуждается, насколько быстрым должен быть процесс. Очевидно, что веб-сайты PHP, не являющиеся процессом, не должны применяться, но всегда помните, что ваш сайт должен выполнять страницы как можно быстрее ... Всегда думайте об этом блоке или этом блоке кода и посмотрите, оптимизирован ли он.

10. Четность Dev / Prod : Этот момент имеет решающее значение при разработке любого приложения. Вы никогда не хотите иметь большой разрыв между двумя версиями приложения, или обновление может стать проблемой. Кроме того, никогда не создавайте специфичные для клиента версии приложения. Всегда находите способы, позволяющие настраивать / настраивать ваше приложение на уровне шаблонов, чтобы вы могли максимально приблизить свое приложение ко всем установленным версиям.

11. Журналы : Журналы всегда полезны, они позволяют вам следить за процессом вашего кода без необходимости выводить его на экран. Моя любимая тактика - это "tail -f logfile" внутри консоли linux и посмотреть, что происходит, когда я выполняю свой код.

12. Административные процессы : Не применимо, в php у вас нет процессов, но у вас есть страницы, которые можно защитить с помощью имен пользователей и паролей.