十二因素应用宣言如何应用于 PHP 项目？
我刚刚阅读了十二因素应用程序，它看起来像是一套非常全面的规则，适用于基于网络的应用程序应用。它在示例中使用 python 或 Rails，但从不使用 php...我想知道宣言的哪些因素可以应用于 PHP 项目以及如何应用？
谢谢
I just read the Twelve-Factor App, which looks like a pretty comprehensive set of rules to apply in a web-based application. It uses python or rails in its examples, but never php... I was wondering which factors of the manifesto can be applied to PHP projects and how?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
简短回答：
所有要点都适用于 PHP，因为十二因素应用宣言专门针对 Web 应用程序。
PHP 很难遵守 12 个因素，特别是在第 2、7、8、9 项（作为 7 和 8 的副作用）和 12（部分）中。事实上，这是我在 Ruby 和 Python 社区中常见的“PHP 很烂”的咆哮中听到的第一个真正有根据的论点（别误会我的意思，我认为 Ruby 和 Python 是更好的语言，但我不讨厌PHP，并且绝对讨厌“我的语言更好”的咆哮。）
话虽如此，您的 PHP 项目可能不是 Web 应用程序或 SaaS，而只是一个简单的网站，所以您可能认为十二因子不是一种需要。
长答案：逐点分析将是：
代码库：不是问题
依赖关系： PEAR 的工作方式与这一点完全相反，因为 pear 依赖关系是在系统范围内安装的，通常您没有统一的宣言来声明它们。 PHP 安装通常还要求您将软件包添加到操作系统安装中以获得一些可用的库。最后，据我所知，PHP 中没有一个工具可以提供像“virtualenv”、“rbenv”或“rvm”这样的隔离（或者如果存在的话，在 PHP 社区中并不流行）编辑： Composer (< a href="http://getcomposer.org/">http://getcomposer.org/) 似乎在依赖关系方面做得正确，它仍然没有隔离 PHP 版本，但对于其余所有应该没问题。
Config：一些 PHP 框架不太适合这样做，但肯定还有其他框架做得很好，所以这不是平台本身的缺陷
支持服务：应该'这不是什么大问题，尽管可能需要破解一些一些框架以便将服务作为资源进行管理
构建、发布、运行：这完全适用于 PHP，因为这绝对不仅仅涉及“编译”。有人可能会说 PHP 社区上的几个项目和托管平台滥用了直接 FTP 等，但这并不是 PHP 本身的缺陷，并且在这一点上正确行事并不存在真正的障碍。
进程：这绝对与 PHP 有关。 PHP 非常有能力运行纯粹的无状态进程（重点是无状态这个词），实际上有几个框架可以让你的生活变得轻松。例如，symfony 通过 memcached 或数据库存储提供开箱即用的会话管理，而不是常规会话
端口绑定：简单来说，这一点基本上要求您进行反向代理并拥有实际的网络服务器嵌入在应用程序中，而不是作为一个单独的组件。这使得 PHP 处于非常难以遵守的境地。尽管有多种方法可以做到这一点（请参阅有关使用 PHP 作为 FastCGI 的回复），但这绝对不是为 PHP 应用程序提供服务的最常见也不是最好的支持方法，因为它在其他社区（例如 Ruby、Node.js）上。
进程：这在 PHP 中并非不可能。然而，有几个因素使 PHP 难以遵守。即第6项和第7项缺乏良好的支持；事实上，用于生成新进程的 PHP API 并不是很好用；特别是 Apache 的 mod_php 处理其工作线程的方式（这是迄今为止 PHP 最常见的部署模式）
可处置性：如果您使用正确的工具，PHP 固有的任何东西都不会阻止您创建快速、一次性、整洁的网络和工作流程。然而，我相信，由于底层流程模型很难按照第 7 点和第 8 点实现，因此第 9 点作为副作用会变得有点麻烦
开发/产品奇偶校验： 这是与平台无关的，我想说这是最难做好的事情之一。 PHP 也不例外，但它也没有特定的障碍。实际上，宣言中提到的大多数工具都可以应用于 PHP 项目
日志： 让您的应用程序不知道执行环境上的日志系统在 PHP 上是完全可行的
管理进程： PHP 在这一点上最重要的缺陷是它的缺乏REPL shell 的一部分。至于其余的，像 Symfony 这样的几个框架允许您对管理任务进行编程（例如基于 Doctine 的数据库迁移）并在与“常规”Web 环境相同的环境中运行它们。
由于 PHP 社区正在不断发展，它可能已经纠正了提到的一些错误。
Short answer:
All points apply to PHP as the twelve factor app manifesto refers specifically for web apps.
PHP has a very hard time complying to twelve factor, in particular in the items 2, 7, 8 9 (as a side effect of 7 and 8) and 12 (partially). Actually that's the first really grounded argument I have heard in the whole "PHP sucks" rant that is common on the Ruby and Python communities (don't get me wrong, I think Ruby and Python are better languages, but I don't hate PHP, and definitively hate the "my language is better" rants.)
Being that said, it may be that your PHP project is not a web app or SaaS, but just a simple website, so you may just deem that twelve factor is not a need.
Long answer: A point-by-point analysis would be:
Codebase: not an issue
Dependencies: the way PEAR works goes quite against this point, as pear dependencies are installed system wide and usually you don't have a consolidated manifesto to declare them. Is also usual for a PHP setup to require you to add packages to your OS installation to get some libraries available. Finally AFAIK there isn't a tool in PHP to provide isolation like "virtualenv", "rbenv" or "rvm" (or if it exists is not popular among the PHP community) Edit: Composer (http://getcomposer.org/) seems to do the right regarding dependencies, it still doesn't isolate the PHP version, but for all the rest it should be fine.
Config: some PHP frameworks are not very well suited to do this, but there are certainly others that do well, so it's not a flaw of the platform itself
Backing Services: shouldn't be much of an issue, despite maybe having to hack some frameworks a little in order to manage the services as resources
Build, release, run: this is totally appliable to PHP as this definitively doesn't concern only "compiling". One may argue that several projects and hosting platforms on the PHP community abuse of direct FTP, etc. but that's not a flaw of PHP itself, and there is no real impediment on doing things right regarding this item.
Processes: This definitively concerns to PHP. PHP is quite capable of running purely stateless processes (the emphasis is on the word stateless), and actually several frameworks make your life easy for it. For example, symfony provides out-of-the-box session management with memcached or database storage instead of regular sessions
Port binding: Over simplyfing it, this point basically demands you to reverse proxy and have the actual webserver embedded on the app instead of being a separated component. This puts PHP in a very hard position to comply. Despite there are ways to do this (see the reply about using PHP as FastCGI) that's definitively not the most common nor the best supported way to serve a PHP app as it is on other communities (e.g. Ruby, Node.js).
Processes: This is not impossible in PHP. However several elements put PHP in a hard position to comply. Namely the lack of good support for items 6 and 7; the fact that the PHP API to spawn new processes isn't really very nice to work with; and specially the way Apache's mod_php handles their workers (which is by far the most common deployment schema for PHP)
Disposability: If you use the right tools there is nothing inherent on PHP to prevent you from creating fast, disposable, tidy web and worker processes. However I believe that since the underlying process model is hard to implement as per points 7 and 8, then 9 becomes a bit cumbersome as a side effect
Dev/prod parity: This is very platform agnostic, and I would say one of the hardest to get done right. PHP is no exception to this rule, but it doesn't have a particular impediment either. Actually most of the tools named on the manifesto can be applied to a PHP project
Logs: Having your app agnostic of the log system on the execution environment is totally doable on PHP
Admin processes: The most important flaw of PHP regarding this point is its lack of a REPL shell. Regarding the rest, several frameworks like Symfony allow you to program admin tasks (e.g Doctine-based database migrations) and run them on the same environment as your "regular" web envionrment.
Since the PHP community is evolving, it may be that it has already righted some of the wrongs mentioned.
我并不声称对这 12 个因素的内容有任何权威，但我读到该部分后，作者会不同意。这不仅仅是编译，还涉及管理小型（代码快照）和大型（代码使用的任何库）的依赖关系。
想象一下，您是一名新开发人员，他们说：“好吧，这是一个自定义 php 应用程序，所以...
a) 自定义代码实际上是两个子项目，分别位于存储库 A 和存储库 B 中
。b) 您需要创建一个像这样的目录布局，然后
c) 将每个子项目的代码检查到这个子目录和这个子目录中
d) 您还需要这三个开源 PHP 库：
库 Foo 的版本 3.1，
Bar 库的 2.3 版，以及
Bat 库的 5.6 版。
e) 从他们的主项目站点下载它们并解压它们，然后将它们复制到这个目录、那个目录和另一个目录中。
f) 然后您需要在外部库中设置这些配置，
g) 并在我们的两个自定义代码项目中设置这些配置。
h) 全部完成后，将其全部 tar/gzip 起来，上传到 QA 服务器并将其解压到 htdocs 中。
这组步骤中没有进行编译，但您可以打赌有很多构建。
让所有这些设置并运行是构建步骤。
使用 tar/gzip 拍摄工作构建的快照是发布步骤。
将其 SCP'ing/解压到 QA 服务器的 htdocs 目录中是运行时步骤。
您可能会说上面的某些步骤是不必要的 - 库应该在系统级别部署并且只需导入。在 12factors.net 网站上，我想说作者更喜欢您为应用程序单独导入它们。它以更多磁盘空间为代价回避了依赖版本控制问题（没人关心）。将所有这些依赖项作为应用程序本地管理存在更多麻烦，但这就是构建/发布/运行时方案的重点。
I don't claim any authority on this 12 factor stuff, but my read of that section is that the author would disagree. It's not just about compiling, it's about managing dependencies both in the small (the snapshot of the code) and in the large (any libraries the code uses).
Imagine you're a new dev and they say, "Okay, this is a custom php app, so...
a) The custom code is really two subprojects, which are in repo A and repo B.
b) You'll need to create a directory layout like so, and then
c) check the code for each subproject out into this subdirectory and this subdirectory.
d) You'll also need these three open source PHP libraries:
version 3.1 of library Foo,
version 2.3 of library Bar, and
version 5.6 of library Bat.
e) download them from their home project sites and unpack them, then copy them into this directory, that directory, and the other directory.
f) then you'll need to set these configurations in the external library,
g) and these configs in our two custom code projects.
h) once that's all done, tar/gzip it all up, upload it up to the QA server and untar it into htdocs.
There's no compiling going in that set of steps, but you can bet there's a lot of building.
Getting all of that set up and working is the build step.
Using tar/gzip to take a snapshot of the working build is the release step.
SCP'ing/unpacking it into the QA server's htdocs directory is the runtime step.
You might say that some of those steps above are unnecessary - the libraries should be deployed at the system level and merely imported. From the 12factors.net site I'd say the author prefers you to import them uniquely and individually for the app. It sidesteps dependency versioning problems at the cost of more disk space (not that anybody cares). There are more hassles in managing all those dependencies as local-to-the-app, but then that's the point of the build/release/runtime scheme.
自从您阅读它以来，它可能已经发生了变化 - 现在有一些 PHP 示例，尽管其中一些看起来像是对十二因素概念的否定。
普通 mod_php 网站违反十二要素的方式之一是 VII。端口绑定。来自宣言：
然而，apache/php 可以通过这样的方式被引入这个世界观：
https://gist.github.com/1398498
并不完美，但它在大多数情况下都有效。要测试它，请安装 foreman：
然后在将要点克隆到的目录中运行它：
然后访问
http://localhost:5000/foo
It might have changed since you read it - there are a few PHP examples now, although a few of them seem like negations of the twelve-factor concept.
One of the ways that normal mod_php sites violate twelve-factor comes with VII. Port binding. From the manifesto:
However, apache/php can be coaxed into this worldview with something like this:
https://gist.github.com/1398498
Not perfect, but it works for the most part. To test it out, install foreman:
then run it in the directory you cloned the gist into:
then visit
http://localhost:5000/foo
请勿将此帖子作为参考，本文写于 2011 年，从那时起许多事情都发生了变化......编程世界正在不断发展。 2011 年的观点不一定在 2018 年仍然有效。
我只是阅读了每个观点的几行内容，以下是我对该文档的分析：
代码库：大家，即使对于小项目，无论是否使用 php，都应该有一个代码库
依赖项：PHP 使用包含和代码库，您应该始终能够通过简单地将代码复制到服务器来轻松移植它们。有时您使用 PEAR，如果服务器不支持它，您必须手动复制并安装 pear。我大部分时间都使用 Zend Framework，所以它只是通过 ftp 上传复制框架的代码。
配置：PHP 应用程序通常有一个可写的配置文件，您可以在其中存储配置。作为开发人员，您可以选择存储它的位置，但它通常位于应用程序的根目录或 settings/config 文件夹中。
后备服务：PHP 大多数时候确实使用后备服务，例如 MySQL。其他常见服务包括 Twitter 和 Facebook，具体取决于您的应用程序。您使用他们的 API 与它们通信并存储/检索要使用的数据。
构建、发布、运行：适用于已编译的代码，而 PHP 中则不然。所以这一点不是你需要关注的。
进程：HTTP 是无状态的并且是 SERVED，因此，除了 Web 服务器之外，通常没有任何进程。这并不完全正确，因为 Web 服务可能与您打包或为其创建的应用程序捆绑在一起。但是，出于标准的考虑，您通常不必使用网络世界中的进程。
端口绑定：PHP 根本不适用于端口绑定，因为它不是一个挂钩地址的进程，Apache、NGinx 或 Lighttpd 会为您完成此操作。阅读 #6/7 让我明白网站永远不可能成为十二要素应用程序。
并发性：这一点同样涉及不适用于 PHP 网页的进程。这一点适用于提供内容的服务器。
一次性：这一点讨论了流程应该有多快。显然，不是进程的 PHP 网站不应该适用，但请始终注意您的网站应尽可能快地执行页面...始终考虑这个或那个代码块，看看它是否经过优化。
开发/产品对等：这一点在任何应用开发中都至关重要。您永远不希望两个应用程序版本之间存在较大差距，否则升级可能会变得很麻烦。此外，切勿创建应用程序的客户端特定版本。始终找到允许在模板级别配置/自定义您的应用的方法，以便您可以使您的应用尽可能接近所有已安装的版本。
日志：日志总是一件好事，它们允许您跟踪代码的流程，而无需将其输出到屏幕。我最喜欢的策略是在 Linux 控制台中“tail -f logfile”，然后查看执行代码时发生的情况。
管理进程：不适用，在 php 中，您没有进程，但您确实有可以使用用户名和密码保护的页面。
DO NOT TAKE THIS POST AS A REFERENCE, THIS WAS WRITTEN IN 2011, MANY THINGS HAVE CHANGED SINCE THEN... THE WORLD OF PROGRAMMING IS IN CONSTANT EVOLUTION. A POINT OF VIEW OF 2011 IS NOT NECESSARILY STILL VALID IN 2018.
I just read a few lines of each points and here goes my analysis of the document:
Codebase: Everyone, php or not should have a codebase even for the little projects
Dependecies: PHP uses includes and code libraries that you should always be able to port easily by simply copying the code to a server. Sometimes you use PEAR and then if the server doesn't support it, you have to copy and install pear manually. I use Zend Framework most of the time, so it's just copying the code of the framework with the ftp upload.
Config: It is common for php apps to have a writable config file that you store configurations into. Where you store it is your choice as a developer, but it is usually either at the root of your app or in a settings/config folder.
Backing Services: PHP does use backing service most of the time such as MySQL. Other common services depending on your app are twitter and facebook. You use their API to communicate with them and store/retrieve data to work with.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this point is not something you need to look at.
Processes: HTTP is stateless and is SERVED,thus, you usually have no process apart from the web server. This is not entirely true as a webservice may be bundled with applications you package with or create for it. But, for the sake of standards, you usually don't have to use processes in the web world.
Port binding: PHP doesn't apply to port binding at all because it is not a process that hooks to an address, Apache, NGinx or Lighttpd does that for you. Reading #6/7 makes me understand that a website could never be a Twelve-Factor app.
Concurrency: Again this point treats about processes which do not apply to PHP web pages. This point applies to the server serving the content.
Disposability: This point discusses about how fast a process should be. Obviously, PHP web sites not being a process shouldnt apply but always note that your website should execute pages as fast as possible... Always think about this block or that block of code and see if it is optimized.
Dev/Prod Parity: This point is crucial in any app development. You never want to have a large gap between two app versions or upgrading can become a hassle. Furthermore, never create client specific versions of an app. Always find ways to allow your app to be configured/customized at the template level so you can keep your app as close as possible to all installed versions everywhere.
Logs: Logs are always a good thing to have, they allow you to follow the process of your code without having to output it to screen. My favorite tactic is to "tail -f logfile" inside of a linux console and look at what is happening as i execute my code.
Admin processes: Not applicable, in php, you don't have processes, but you do have pages that you can secure with usernames and passwords.