the - ¿Cómo se aplica el manifiesto de la aplicación Twelve-Factor a los proyectos PHP?
twelve factor cloud (4)
Build, release, Run: Aplicable al código compilado que no es el caso en PHP. Entonces este punto no es algo que debas mirar.
No reclamo ninguna autoridad sobre este factor de 12 factores, pero mi lectura de esa sección es que el autor no estaría de acuerdo. No se trata solo de compilar, se trata de administrar dependencias tanto en el pequeño (la instantánea del código) como en el grande (cualquier biblioteca que use el código).
Imagina que eres un nuevo desarrollador y dicen: "Bueno, esta es una aplicación php personalizada, así que ...
a) El código personalizado es en realidad dos subproyectos, que están en repo A y repo B.
b) Tendrá que crear un diseño de directorio como tal, y luego
c) verifique el código de cada subproyecto en este subdirectorio y este subdirectorio.
d) También necesitarás estas tres bibliotecas de código abierto de PHP:
versión 3.1 de library Foo, versión 2.3 de library Bar y versión 5.6 de library Bat.
e) descárguelos de los sitios de sus proyectos domésticos y descomprímalos, luego cópielos en este directorio, ese directorio y el otro directorio.
f) entonces necesitarás establecer estas configuraciones en la biblioteca externa,
g) y estas configuraciones en nuestros dos proyectos de código personalizado.
h) una vez que esté todo listo, descargue / descargue todo, cárguelo en el servidor de control de calidad y descomprímalo en htdocs.
No hay compilación en ese conjunto de pasos, pero puedes apostar que hay mucho edificio.
Poner todo eso configurado y funcionando es el paso de compilación.
El uso de tar / gzip para tomar una instantánea de la compilación de trabajo es el paso de la versión.
SCP''ing / descomprimirlo en el directorio htdocs del servidor QA es el paso del tiempo de ejecución.
Podría decir que algunos de los pasos anteriores son innecesarios: las bibliotecas deben implementarse a nivel del sistema y simplemente importarse. Desde el sitio 12factors.net, diría que el autor prefiere que los importe de forma única e individual para la aplicación. Evita los problemas de versiones de la dependencia al costo de más espacio en el disco (no es que a nadie le importe). Hay más problemas en la administración de todas esas dependencias como local para la aplicación, pero ese es el punto del esquema de compilación / lanzamiento / tiempo de ejecución.
Acabo de leer la aplicación Twelve-Factor , que parece un conjunto de reglas bastante completo para aplicar en una aplicación basada en web. Utiliza python o rails en sus ejemplos, pero nunca php ... Me preguntaba qué factores del manifiesto se pueden aplicar a los proyectos de PHP y cómo .
Gracias
Es posible que haya cambiado desde que lo leyó; ahora hay algunos ejemplos de PHP, aunque algunos de ellos parecen negaciones del concepto de los doce factores.
Una de las formas en que los sitios mod_php normales violan el factor doce viene con VII. Enlace de puerto . Desde el manifiesto:
La aplicación de doce factores es completamente independiente y no se basa en la inyección en tiempo de ejecución de un servidor web en el entorno de ejecución para crear un servicio orientado a la web. La aplicación web exporta HTTP como un servicio vinculando a un puerto y escuchando las solicitudes que llegan a ese puerto.
Sin embargo, apache / php puede ser persuadido en esta cosmovisión con algo como esto:
https://gist.github.com/1398498
No es perfecto, pero funciona en su mayor parte. Para probarlo, instale el capataz:
instalador de gemas
luego ejecútalo en el directorio en el que clonaste la esencia en:
comienzo del capataz
luego visitar
NO TOME ESTE POST COMO UNA REFERENCIA, ESTA ES ESCRITO EN 2011, MUCHAS COSAS HAN CAMBIADO DESDE QUE ENTONCES ... EL MUNDO DE LA PROGRAMACIÓN ESTÁ EN EVOLUCIÓN CONSTANTE. UN PUNTO DE VISTA DE 2011 NO ES NECESARIAMENTE TODAVÍA VÁLIDO EN 2018.
Acabo de leer algunas líneas de cada punto y aquí va mi análisis del documento:
Base de código : todos, php o no deben tener una base de código incluso para los pequeños proyectos
Dependecies : PHP utiliza bibliotecas de códigos y de código que siempre debería poder portar fácilmente simplemente copiando el código a un servidor. A veces usa PEAR y luego, si el servidor no lo admite, debe copiar e instalar pear manualmente. Utilizo Zend Framework la mayor parte del tiempo, así que solo estoy copiando el código del framework con la carga ftp.
Configuración : es común que las aplicaciones php tengan un archivo de configuración de escritura en el que almacena las configuraciones. Donde almacena es su elección como desarrollador, pero generalmente se encuentra en la raíz de su aplicación o en una carpeta de configuración / configuración.
Servicios de respaldo : PHP utiliza el servicio de respaldo la mayor parte del tiempo, como MySQL. Otros servicios comunes dependiendo de su aplicación son twitter y facebook. Utiliza su API para comunicarse con ellos y almacenar / recuperar datos para trabajar con ellos.
Build, release, Run : Aplicable al código compilado que no es el caso en PHP. Entonces este punto no es algo que debas mirar.
Procesos : HTTP no tiene estado y está SERVIDO, por lo tanto, por lo general, no tiene ningún proceso aparte del servidor web. Esto no es del todo cierto, ya que un servicio web se puede incluir en las aplicaciones que usted empaqueta o crea para él. Pero, por el bien de los estándares, generalmente no tiene que usar procesos en el mundo web.
Enlace de puerto : PHP no se aplica en absoluto al enlace de puerto porque no es un proceso que se enlaza a una dirección, Apache, NGinx o Lighttpd lo hace por usted. La lectura # 6/7 me hace entender que un sitio web nunca podría ser una aplicación de Twelve-Factor.
Concurrencia : Nuevamente, este punto trata sobre procesos que no se aplican a las páginas web de PHP. Este punto se aplica al servidor que sirve el contenido.
Disposibilidad : este punto discute acerca de qué tan rápido debe ser un proceso. Obviamente, los sitios web de PHP no deben ser un proceso, pero siempre tenga en cuenta que su sitio web debería ejecutar las páginas lo más rápido posible ... Siempre piense en este bloque o en ese bloque de código y vea si está optimizado.
Paridad Dev / Prod : Este punto es crucial en el desarrollo de cualquier aplicación. Nunca querrá tener una gran brecha entre dos versiones de aplicaciones o la actualización puede convertirse en una molestia. Además, nunca cree versiones específicas del cliente de una aplicación. Siempre encuentre formas de permitir que su aplicación se configure / personalice en el nivel de la plantilla para que pueda mantener su aplicación lo más cerca posible de todas las versiones instaladas en todas partes.
Registros : los registros siempre son buenos, ya que le permiten seguir el proceso de su código sin tener que mostrarlo en la pantalla. Mi táctica favorita es "tail -f logfile" dentro de una consola Linux y ver lo que sucede cuando ejecuto mi código.
Procesos de administración : no aplicable, en PHP, no tiene procesos, pero sí tiene páginas que puede proteger con nombres de usuario y contraseñas.
Respuesta corta:
Todos los puntos se aplican a PHP, ya que el manifiesto de doce factores se refiere específicamente a las aplicaciones web.
PHP tiene dificultades para cumplir con el factor doce, en particular en los ítems 2, 7, 8 9 (como efecto secundario de 7 y 8) y 12 (parcialmente). De hecho, ese es el primer argumento realmente fundamentado que he escuchado en el discurso "PHP chupa" que es común en las comunidades de Ruby y Python (no me malinterpreten, creo que Ruby y Python son mejores idiomas, pero no odio PHP, y definitivamente odio las "quejas mi idioma es mejor".
Dicho esto, puede ser que su proyecto PHP no sea una aplicación web o SaaS, sino un simple sitio web, por lo que puede considerar que el factor doce no es una necesidad.
Respuesta larga: un análisis punto por punto sería:
Codebase: no es un problema
Dependencias: la forma en que funciona PEAR va bastante en contra de este punto, ya que las dependencias de pera se instalan en todo el sistema y, por lo general, no tiene un manifiesto consolidado para declararlas. También es habitual que una configuración de PHP requiera que agregue paquetes a la instalación de su sistema operativo para obtener algunas bibliotecas disponibles. Finalmente, AFAIK no hay una herramienta en PHP que proporcione aislamiento como "virtualenv", "rbenv" o "rvm" (o si existe no es popular entre la comunidad de PHP) Edición: Compositor ( http://getcomposer.org/ ) parece hacer lo correcto con respecto a las dependencias, todavía no aísla la versión de PHP, pero por lo demás debería estar bien.
Configuración: algunos frameworks PHP no son muy adecuados para hacer esto, pero ciertamente hay otros que funcionan bien, por lo que no es un defecto de la plataforma en sí.
Servicios de respaldo: no debería ser un gran problema, a pesar de tener que hackear algunos marcos un poco para administrar los servicios como recursos
Genere, libere, ejecute: esto es totalmente aplicable a PHP, ya que esto definitivamente no se refiere solo a la "compilación". Se puede argumentar que varios proyectos y plataformas de alojamiento en la comunidad de PHP abusan de FTP directo, etc., pero eso no es una falla del propio PHP, y no existe un impedimento real para hacer las cosas bien con respecto a este elemento.
Procesos: Esto definitivamente concierne a PHP. PHP es bastante capaz de ejecutar procesos puramente sin estado (el énfasis está en la palabra sin estado), y en realidad varios marcos le facilitan la vida. Por ejemplo, Symfony proporciona administración de sesión inmediata con memcached o almacenamiento de base de datos en lugar de sesiones regulares
Enlace de puerto: más que nada, este punto básicamente exige que invierta el proxy y tenga el servidor web real incrustado en la aplicación en lugar de ser un componente separado. Esto pone a PHP en una posición muy difícil de cumplir. A pesar de que hay formas de hacerlo (ver la respuesta sobre el uso de PHP como FastCGI), definitivamente no es la forma más común ni la mejor manera de servir una aplicación PHP como lo es en otras comunidades (por ejemplo, Ruby, Node.js).
Procesos: Esto no es imposible en PHP. Sin embargo, varios elementos ponen a PHP en una posición difícil de cumplir. Es decir, la falta de un buen apoyo para los artículos 6 y 7; el hecho de que la API de PHP para generar nuevos procesos no es realmente agradable trabajar con ellos; y especialmente la forma en que mod_php de Apache maneja a sus trabajadores (que es, con mucho, el esquema de implementación más común para PHP)
Disposibilidad: si usa las herramientas adecuadas, no hay nada inherente en PHP que le impida crear procesos web y de trabajo rápidos, desechables y ordenados. Sin embargo, creo que dado que el modelo de proceso subyacente es difícil de implementar según los puntos 7 y 8, entonces 9 se vuelve un poco engorroso como efecto secundario
Paridad de desarrollo / producción: Esto es muy agnóstico en cuanto a plataformas, y diría que es uno de los más difíciles de hacer bien. PHP no es una excepción a esta regla, pero tampoco tiene un impedimento particular. En realidad, la mayoría de las herramientas nombradas en el manifiesto se pueden aplicar a un proyecto PHP
Registros: hacer que su aplicación sea independiente del sistema de registro en el entorno de ejecución es totalmente factible en PHP
Procesos de administración: el defecto más importante de PHP con respecto a este punto es su falta de un shell REPL. Con respecto al resto, varios marcos como Symfony le permiten programar tareas de administración (por ejemplo, migraciones de base de datos basadas en Doctine) y ejecutarlas en el mismo entorno que su entorno web "normal".
Dado que la comunidad de PHP está evolucionando, puede ser que ya haya corregido algunos de los errores mencionados.