Práctica de la plataforma de automatización de operaciones de actividadesLa plataforma de operación de actividades de Renrendai es desarrollada y mantenida por el equipo de front-end de Renrendai y se utiliza para construir automática y visualmente un sistema para las actividades regulares de Renrendai. Este artículo compartirá las ideas de diseño y la implementación técnica parcial de la "Plataforma de Operación Renrendai", con la esperanza de ser útil para todos. 1. Antecedentes En los últimos años, el equipo de front-end de Renrendai ha recibido muchas necesidades de desarrollo de actividades por parte del departamento de marketing. Estas actividades se dividen principalmente en cuatro categorías: actividades LP (LandingPage) y páginas de actividades para nuevos registros, que son básicamente una caja de registro + varias tarjetas de productos MGM (Membersgetmember) se utilizan para crear nuevas páginas de actividades entre amigos, generalmente incluyendo registros. y clasificación. Las actividades habituales con funciones de intercambio generalmente incluyen sorteos de lotería, tarjetas de productos, clasificaciones, intercambio y otras funciones. Se utilizan para promover las ventas de eventos especiales, generalmente páginas de juegos. Básicamente, el mismo formulario solo utiliza actividades 1.1 para desarrollar cuellos de botella de recursos humanos y tiene un largo ciclo en línea. ¿Cuánto tiempo lleva desarrollar una actividad ordinaria (incluidas las actividades LP anteriores, actividades MGM, actividades regulares)? En circunstancias normales, para una actividad simple que involucra tanto H5 como PC, se necesitan 2 personas * 2 días para que el diseñador complete el trabajo de diseño y 3 personas * 2 días para el desarrollo (incluido H5, página de PC, desarrollo de interfaz de back-end). y depuración de interfaz). La prueba requiere 2 personas*2 días. De esta manera, se necesitan * *14 personas* días de recurso humano para completar los requisitos desde que se propone hasta que se pone en línea, lo que demora 7 días hábiles. En caso de que exista una necesidad urgente de desarrollar un evento y sea necesario comprimir el ciclo de lanzamiento, todos tendrán que trabajar horas extras para completarlo. Además, debido a la particularidad del acuerdo financiero de la empresa, muchas actividades generalmente comienzan temprano en la mañana. Los desarrolladores y evaluadores deben confirmar que las actividades se desarrollan normalmente en línea antes de salir del trabajo. 1.2 Repetición y modificación de funciones de actividad Con el desarrollo del negocio de la empresa, existen cada vez más demandas de desarrollo de actividades. Un tercio de la mano de obra del equipo de front-end se ha invertido en el desarrollo de páginas de eventos durante mucho tiempo. De hecho, las funciones de la mayoría de nuestras actividades ordinarias no son complejas y la mayoría de ellas son repetitivas. Este tipo de desarrollo de páginas con funciones repetidas tiene poco valor para individuos y equipos. Además, una vez iniciada la actividad, a menudo es necesario modificar y reiniciar el código debido al estilo y la redacción, lo que hace que los miembros del equipo generalmente se sientan disgustados con el desarrollo de actividades tan ordinarias. Durante este período, el equipo también propuso un método de desarrollo de componentes, intentando extraer diferentes módulos funcionales y hacer referencia a ellos en diferentes páginas de actividades para ahorrar tiempo de desarrollo. Sin embargo, debido a la incertidumbre del plan de diseño y la participación de diferentes desarrolladores, la reutilización de este módulo funcional extraído no es alta y el efecto no es particularmente ideal. Y no puede resolver el problema de los estilos y las modificaciones de redacción que requieren volver a estar en línea. En resumen, las características de las actividades ordinarias son que las funciones de la página son similares, el tiempo de desarrollo es reducido, el tiempo fuera de línea es rápido y el contenido técnico es bajo. A medida que el sistema técnico del equipo se vuelve cada vez más maduro, finalmente liberamos nuestra energía para intentar solucionar diversos puntos débiles en el desarrollo de las actividades ordinarias. 2. Plataforma de operación de actividades Renrendai Hace ya diez años, Dreamweaver se utilizaba para construir visualmente páginas estáticas de front-end. Aunque Dreamweaver es cosa del pasado, la idea de construcción visual todavía se utiliza ampliamente. En una encuesta de soluciones comúnmente utilizadas en la industria, descubrimos que muchas empresas tienen sus propios sistemas de operación de actividades, que pueden usarse para configurar actividades de manera eficiente y visual y monitorear los datos de operación de las actividades. Esperamos utilizar la idea de construir visualmente páginas de actividades para que los operadores puedan agregar actividades y configurar las páginas de actividades correspondientes de acuerdo con las necesidades operativas reales. Marco general de la plataforma operativa 2.1 Primero, presentemos brevemente el modelo de desarrollo del front-end de Renrendai. Con el surgimiento de Node.js, a partir de 2016, transformamos el modelo de desarrollo front-end original basado en JSP en un modelo con Node.js como capa intermedia y la separación entre front-end y back-end. Separación de front-end y back-end El front-end de Renrendai adopta el modelo de desarrollo de separación de front-end como se muestra en la figura (la imagen proviene de la evolución del modelo de I + D web). En este modelo de desarrollo, las responsabilidades del front-end y del back-end son claras. En cuanto al front-end, cada una de las dos capas de UI tiene sus propias funciones: la capa de UI del front-end maneja la lógica de visualización de la capa del navegador, y la capa de UI del back-end se puede usar para manejar el enrutamiento, las plantillas, la recopilación de datos, cookies, renderizado del lado del servidor, etc. Bajo este modelo de desarrollo front-end y back-end, la arquitectura de toda la plataforma operativa de Renrendai es la siguiente: Diseño general Todo el sistema de plataforma operativa se divide en cuatro bloques principales. 1. Biblioteca de componentes. La plataforma operativa adopta una solución de componentes común en la industria y utiliza React.js como biblioteca de desarrollo de componentes. Los métodos de división y desarrollo de la biblioteca de componentes se presentarán en detalle a continuación. 2. Sistema frontal.
Toda la plataforma operativa incluye el sistema de bloques de construcción, rrd-h5 y rrd-pc. Entre ellos, Building Blocks System es un sistema interno para crear, editar y publicar páginas de eventos. Rrd-h5 y rrd-pc son capas de UI back-end orientadas al usuario que representan páginas de actividad basadas en datos de configuración de actividad generados y proporcionan interfaces asincrónicas para que los usuarios accedan. 3. Interfaz de fondo. En el servicio en segundo plano, debido a que las actividades no son particularmente complejas, tenemos una gran cantidad de interfaces, como sorteos de lotería, registro de direcciones de cosecha, etc. Solo necesita realizar algunos cálculos o almacenamiento simples e implementarlos directamente usando Node.js, que es el servicio de servicio de mercado de nodos en la imagen de arriba. Algunas interfaces relacionadas con el negocio principal de la empresa, como el reembolso de inversiones, todavía utilizan directamente la interfaz Java proporcionada por el backend. 4. Capa de datos. Se utiliza para almacenar datos relacionados con la configuración activa y algunos datos operativos. 2.2 Biblioteca de componentes Según los módulos funcionales, dividimos la página de actividad anterior en diferentes componentes. Tomemos como ejemplo la página de amigos en el terminal móvil. Esta página incluye: componente de imagen (imagen de banner), componente de regla de actividad, componente de registro, componente de clasificación del equipo, componente de mejora de crédito de la plataforma y componente de botón de amigo. Una vez completada la división de componentes, obtenemos una biblioteca de componentes. Para facilitar la gestión de la biblioteca de componentes, dividimos la biblioteca de componentes en tres categorías: jm-common, jm-mobile y jm-pc, que corresponden a los componentes comunes, componentes H5 y componentes del lado de la PC en ambos extremos. respectivamente. Como se mencionó anteriormente, nuestro sistema de bloques de construcción se posiciona como una plataforma de edición visual. Después de configurar el componente, debe mostrarse en tiempo real en la página de edición. Los servicios Rrd-h5 y rrd-pc también necesitan representar componentes según los datos de configuración de la página. Los tres sistemas requieren el uso de bibliotecas de componentes. Para facilitar el desarrollo y la vista previa de los componentes, integramos el código fuente de la biblioteca de componentes en el repositorio de código del sistema de bloques de construcción. El sistema de bloques de construcción carga la biblioteca de componentes a través del código fuente de la biblioteca de componentes en el código del proyecto. Cuando se modifica el código de un componente, el sistema de bloques de construcción puede recompilar, actualizar la página y obtener una vista previa de los nuevos estilos de componentes. La biblioteca de componentes también será juzgada por el entorno de desarrollo y los datos de simulación en el sistema de edición se utilizarán automáticamente para facilitar las pruebas del desarrollo de componentes. Para facilitar la administración de versiones y el acceso a la biblioteca de componentes, cuando se complete el desarrollo del componente, publicaremos la biblioteca de componentes en el almacén privado de npm y actualizaremos el número de versión de la biblioteca de componentes correspondiente en rrd-h5 y rrd-pc para cargar nuevos componentes. . 2.3 Configuración de actividad y configuración de página En el sistema de bloques de construcción, primero debe crear una actividad y luego crear las páginas móviles y de PC correspondientes a la actividad, en lugar de crear directamente la página de actividad. Esto se debe a que, según la experiencia operativa anterior, una actividad puede corresponder a varias páginas de promoción (al menos dos páginas en H5 y PC), y estas páginas de promoción deben disfrutar de algunas configuraciones de actividad. En términos de almacenamiento de datos, creamos tres tablas nuevas: actividad, página y registro de página para almacenar datos relacionados con la configuración de la actividad, la configuración de la página y la configuración de los componentes. Una actividad es una tabla de configuración de actividades que es responsable de registrar el nombre de la actividad, el tiempo en línea y fuera de línea de la actividad, la configuración de la actividad relacionada con el negocio y la configuración de la actividad pública. Entre ellos, la configuración del componente público se refiere a la página bajo la actividad, que requiere elementos de configuración del componente público. Por ejemplo, el componente de recopilación de cupones almacenará el monto, tipo, lote, etc. El uso de la configuración de componentes comunes puede evitar eficazmente errores de configuración o inconsistencias cuando los componentes de varias páginas se configuran por separado. M * * *La página de configuración es una tabla de páginas. Cuando se crea una nueva página, los datos se insertarán en la tabla. Esta información registrará el nombre de la página, el ID de actividad a la que pertenece la página, la plataforma (móvil o PC) a la que pertenece la página y el tiempo de lanzamiento. Cabe señalar que esta tabla no registra datos de configuración de componentes específicos. Esto es para separar los datos de la página de los datos de configuración del componente. Sin embargo, la tabla de páginas registra el online_record_id utilizado por la página en línea, que se utiliza para asociar los datos de los componentes utilizados por la página en línea. Después de publicar cada página, actualizaremos el último online_record_id con los datos de la página correspondiente. Page_record es una tabla de registro de configuración de componentes, principalmente responsable de registrar la identificación de la página, datos de componentes específicos, editor, tiempo de lanzamiento, etc. En la edición de página activa del sistema de bloques de construcción, cada vez que se guarda una página, se insertará un dato en esta tabla para facilitar la búsqueda de registros de edición y la reversión. Editar página 2.4 Configuración de componentes y análisis de datos de configuración De acuerdo con nuestro proceso de operación planificado, el operador agrega actividades en el sistema de bloques de construcción.