¿Cuál es el flujo de trabajo sugerido para la configuración de migración (CMI) de dev -> stage -> production?

41

Tuvimos un drupalcamp hace unos meses y alguien preguntó sobre la administración de implementaciones con el nuevo sistema de configuración (CMI). Un posible flujo de trabajo ideal implicaría mantener la configuración en el control de versiones y aún así poder migrar la configuración entre los miembros del equipo.

Lo mejor que pudimos descubrir en la sala (parcialmente basado en la presentación en DrupalCon Portland) fue:

Indique al control de versiones que ignore el directorio de configuración activo.
Copie toda la configuración en el directorio provisional y comprométase con el control de versiones.

Y use settings.php para revertir el directorio activo / provisional entre los 2 entornos. Sin embargo, aunque descubrir un flujo de trabajo de implementación de un servidor al siguiente era complejo pero factible, ¿cuál es el flujo de trabajo sugerido desde múltiples entornos locales (es decir, múltiples desarrolladores) en desarrollo (o entre ellos)? Un posible problema sería que cada miembro del equipo estaría compartiendo el mismo entorno o uno similar, entonces, ¿cómo se producen los cambios en la máquina de un compañero de equipo?

migration 8 version-control

— btmash
fuente

55

Realmente no estoy de acuerdo con los votos cerrados actuales. Como CMI es un foco para Drupal 8, creo que podemos tener algunas buenas respuestas aquí.

— mpdonadio

3

De acuerdo, esta es la muy buena pregunta. Creo que la tarea crítica drupal.org/node/1703168 es sobre este y otros temas y aún no está completamente resuelta, por lo que las respuestas aquí podrían ayudar a impulsar ese problema.

— Berdir

Pido disculpas si mi pregunta resultó negativa con respecto a la iniciativa CMI (que no era mi intención en absoluto). He actualizado la pregunta para que suene más neutral.

— btmash

2

Casi iba a decir "¿Has probado las funciones?". ¿Quizás el "D8" debería ir en el título de la pregunta? La etiqueta "8" es un poco invisible.

— donquixote

1

Se revisó el título para que la pregunta se pueda ver por etiqueta o por título :)

— btmash

19

Después de hablar un poco con los mantenedores de CMI, la discusión sobre cuál es el mejor enfoque no ha terminado, pero lo siguiente es lo que tiene más sentido en este momento.

Intentando mantenerlo conciso por ahora, intentará expandirse según las preguntas / cuando el problema al que se hace referencia se resuelva con una respuesta oficial.

Entonces, primero, los hechos ...

Como ya se mencionó, existe el directorio activo y provisional. Active está totalmente administrado por Drupal, por lo que no se admiten los cambios directamente allí (directos o indirectos al cambiar a una ubicación diferente).
La puesta en escena es donde Drupal busca la configuración para importar y, de lo contrario, no le importa.
El proceso de importación es importante, los cambios de configuración pueden afectar a un sitio de cierta manera y es necesario verificar su validez. No puede cambiar el tipo de campo de un campo de texto a una referencia de entidad, por ejemplo, eso simplemente no funciona.
La importación de la configuración siempre debe ejecutarse en todas las configuraciones, no puede importar una sola vista o tipo de nodo. Se intentó, pero tratar de hacer frente a las dependencias, eliminar / renombrar, etc. resultó en un sistema muy complicado y no funcionó.
La única forma de reinstalar la configuración predeterminada es reinstalar ese módulo. Lo que significa que primero intentaría eliminar toda la configuración (como los campos). Entonces esa no es realmente una opción. Manual, cambios específicos en las funciones de actualización son posibles pero demasiado tediosos para esto, creo.
Como se describe en el módulo de características, se centrará en proporcionar una funcionalidad reutilizable, no en implementaciones continuas de configuración. Para eso fue diseñado en primer lugar.

Dado eso, la recomendación en este momento es poner el directorio provisional en el control de versiones. Cada desarrollador tiene control total sobre lo que pone allí, ya sea copiando todo el directorio activo o simplemente un archivo de configuración específico. Los cambios en el directorio de preparación se confirman, se envían a producción y se ejecuta la importación de la configuración (en la interfaz de usuario o con drush).

— Berdir
fuente

El directorio de ensayo en el control de versiones, obtengo esa parte. Las otras partes son lo que mi mente está tratando de procesar. Entonces, si alguien realiza un cambio, copia sus cambios en el directorio de ensayo y lo confirma. Después de ese punto, los otros desarrolladores / próximo servidor obtienen los cambios y sincronizan los cambios en el directorio activo. Y enjuague y repita para cualquier otra cadena de servidores en el camino (preparación, producción, etc.). Y siempre pasa por etapas para que ya no se produzca un cambio de directorio. ¿Sería eso exacto?

— btmash

Sí. No debe haber cambio de directorio. Cada cambio de configuración debe pasar por el proceso de importación o puede terminar con un sitio roto. Por ejemplo, la lista de módulos también es configuración. La implementación significa que los módulos deben instalarse / desinstalarse (Nota: esto aún no funciona, pero hay un problema para solucionarlo).

— Berdir

Ok, entonces aún hay más preguntas ahora (divididas en 2 comentarios) :) Primero, mencionas que los módulos son configuración. Entonces, incluso si un módulo se agrega a un repositorio y no se habilita / deshabilita, ¿debe instalarse / desinstalarse solo por sentarse allí?

— btmash

Y el seguimiento: (A) ¿Habrá un mecanismo para copiar los cambios desde el directorio activo -> puesta en escena (para simplificar frente a una persona que ingresa al directorio de configuración para estos componentes, posiblemente una forma de seleccionar ciertas variables). (B) ¿El directorio de ensayo se vacía después de que los cambios se sincronizan de ensayo -> activo? (B1) Si es así, ¿es la estrategia desde el punto de vista de DevOps restablecer ese directorio antes de un git pull? (B2) Si no es así, ¿es correcto suponer que mientras se produce la puesta en escena-> sincronización activa, no debería haber ningún efecto en la configuración que no ha cambiado?

— btmash

El estado de instalación del módulo es la configuración. No es el módulo en sí :) Eso es lo que implementas. a) Hay una interfaz de usuario para descargar un tar.gz del directorio activo, uno para cargar dicho tar.gz en el directorio de ensayo y otro para hacer la importación, con una descripción general y la diferencia de los cambios. B) Creo que en este momento está vacío, pero supongo que puedes revertirlo fácilmente con git. No estoy seguro, fácil de verificar. Todo eso se puede conectar, por lo que podría haber una implementación ligeramente diferente que no se elimine. B2) No entiendo este pero creo que sí.

— Berdir

4

Gran respondió hasta ahora. ¡Gracias a todos!

Comenzamos un proyecto Drupal 8 recientemente e implementamos el siguiente flujo de trabajo.

Tenemos tres carpetas activas, puesta en escena y exportación. Los desarrolladores vuelcan su para exportar. No quiero mantenerlo en escena. Creo que es más fácil trabajar cuando la configuración compartida no se almacena directamente en la carpeta de ensayo. Es solo una tala, no tengo hechos concretos sobre esto ...

Nuestra plantilla de proyecto actual de drupal 8 está disponible en github. También escribí algunos comandos prácticos drush para acelerar el flujo de trabajo devleoper. No se requiere copia manual de activo a exportar.

Plantilla de proyecto: https://github.com/webflo/d8-project-template
Comandos Drush adicionales: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
fuente

1

Hasta ahora, estoy de acuerdo con este enfoque. He agregado todas las características de los enlaces en esta publicación a los comandos Drush config-export y config-import. Espero que otros se unan a mí y a @florian para explorar esta solución de 3 directorios.

— moshe weitzman

¿Cómo lidiar con la sites/default/files/config_HASHconfiguración de la carpeta que tiene un sufijo numeral, por ejemplo config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow Es posible anular la ubicación de estas carpetas. Simplemente busque "Ubicación de los archivos de configuración del sitio". en settings.php utilizo el siguiente fragmento. Esto significa que la configuración se almacena fuera del directorio raíz de Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo

Gracias @webflo, vi esto. ¿Cuál sería el beneficio de administrar una base de código y una configuración por separado? Creo que esta separación es un poco artificial ya que tanto el código como la configuración (en yaml) determinan el comportamiento y dependen unos de otros. En Drupal 7, la configuración en código (o rastreable por Git) se realizó con el módulo Características creando un módulo para cada configuración particular que se requería rastrear en código. En Drupal 8, hay Características 3.x que, según tengo entendido, hace lo mismo pero usa YAML para almacenar la configuración y los módulos generados no dependen del módulo Características.

— therobyouknow

Creo que me malinterpretaste, el directorio de configuración todavía está en git, pero mi sitio Drupal no está en la raíz del repositorio de git. El sitio está almacenado / web. Entonces / config y / web están en el mismo nivel.

— webflo

2

Todavía no lo he intentado, pero mi plan es crear un módulo personalizado que contenga archivos de configuración "predeterminados" que solo contengan la configuración que me interesa. Creo que otros módulos pueden contener configuraciones que anulan otros módulos. (Si no, esto debería ser posible).

Creo que debes dejar sola la carpeta de configuración. Ignoralo. Se genera automáticamente en la instalación desde todos los archivos de configuración de los módulos individuales. El camino es largo y aleatorio. Si mantuviste todo eso en un repositorio, necesitarías un repositorio separado y estarías llevando consigo toneladas de archivos de configuración innecesarios y predeterminados.

Poner config en un módulo personalizado lo convierte en parte de su base de código principal.

El proceso de implementación sería:

Git pull o lo que sea para obtener nuevos archivos.
Borrar cachés.
Restablecer configuración predeterminada. (De los archivos de su módulo personalizado)

Puede crear módulos personalizados (con su propia configuración) para cada entorno si lo desea.

— jonpugh
fuente

Esto suena mucho como características, ¿no? ¿O hay una diferencia significativa que me falta?

— Letharion

Es un enfoque interesante y me gusta la idea. Sin embargo, una de las mayores ventajas que se ha mencionado como parte de la iniciativa CMI es la capacidad de moverse por la configuración desde los directorios de configuración. Y por lo que veo, el archivo settings.php le permite dictar dónde están los directorios activos / intermedios (es decir, no necesitan ser rutas autogeneradas). Por lo tanto, creo que un flujo de trabajo con la configuración actual debería ser posible sin necesidad de crear una característica como @Letharion menciona anteriormente.

— btmash

2

Nota: Aprecio que esta no sea una respuesta en el sentido más estricto en relación con la pregunta, pero la puse aquí de todos modos y volveré a visitarla y la editaré / eliminaré una vez que Features tenga una versión 8.x y el polvo haya se instaló un poco más. Esto era demasiado grande para un comentario y quería obtener £ 0.02 en :-)

Como gran fanático de las características , sugeriría que vigile la encarnación D8 del módulo de características .

Tomado de la página del proyecto

La versión 3.x de Características está planificada para que Drupal 8 se integre con el nuevo sistema de gestión de configuración. Si simplemente necesita exportar una configuración de sitio simple, se debe usar el sistema de administración de configuración D8 en lugar de Características. Utilizará Características en D8 para exportar la funcionalidad incluida (como una "función de galería de fotos").

La forma en que un poco veo es que esta idea hace que sea más fácil para dev equipos para trabajar en partes más pequeñas de un sitio. Sin embargo, todavía no voy a entrar en un flujo de trabajo, ya que todavía hay demasiadas variables desconocidas, pero no puedo ver que sea tan diferente de un procedimiento de implementación de características actual.

No puedo evitar pensar que sí, CMI es increíble; pero la mayoría de mis sitios todavía terminarán con módulos de características (aunque una cantidad menor debido a que no tienen que exportar CADA tipo de contenido, permiso, etc.)

— Chapabu
fuente

Si bien estoy de acuerdo en que las funciones cambiarán ligeramente su función y (con suerte) serán la herramienta para agrupar los componentes de configuración (como la función de la galería de fotos que mencionas), la configuración (hasta donde yo entiendo) todavía se mantendrá a través de la activa directorio de configuración Por lo tanto, las características pueden resolver un determinado componente, pero el problema real es cómo se gestiona el flujo de trabajo del directorio de configuración en todos los entornos. El procedimiento de implementación es ligeramente diferente del procedimiento de implementación de las características actuales principalmente porque los datos del almacén activo están en la base de datos y el almacén de datos son los archivos.

— btmash

... el procedimiento de implementación de las características de d7 involucra datos del almacén activo en la base de datos y el almacén de datos en archivos. Estamos pasando a ser archivos y solo necesitamos asegurarnos de cómo eso afecta un cambio en el flujo de trabajo.

— btmash

Tenga en cuenta que las características realmente no tienen el concepto de activo y almacenamiento de datos / puesta en escena. O al menos no es consistente, todo depende del gancho / cosa específica con la que se está integrando. Las vistas predeterminadas viven en el código, por ejemplo, los cambios están inmediatamente activos (aparte del almacenamiento en caché), no hay un proceso de implementación controlado con características. Ese siempre ha sido uno de los principales problemas al utilizar funciones para implementaciones.

— Berdir

Tienes razón. No sé cómo mezclé el módulo de configuración para D7 con las características, pero lo hice.

— btmash