La experiencia de desarrollo acumulada en proyectos grandes y complejos se materializa en herramientas útiles y prácticas de ingeniería, que necesitan enriquecer los procesos de desarrollo, repensándolo nuevamente. Fue el reconocimiento del valor de la experiencia adquirida como un artefacto, el deseo de desarrollar, lo que nos llevó a comprender la necesidad de implementar herramientas y prácticas en los procesos actuales. Y lanzamos una revisión radical de los enfoques para diseñar soluciones y para el proceso de desarrollo en su conjunto. No tiene sentido describir las limitaciones y deficiencias típicas del enfoque "clásico" para el desarrollo de equipos en el mundo 1C. Ya se ha dicho mucho sobre este tema. Solo describiré los patrones que nos permitieron hacer que estas deficiencias sean pequeñas y casi no dan miedo.
¡Conozca, el
soporte de desarrollo integrado!Principios generales de arquitectura.
Al diseñar la arquitectura del stand, intentamos cubrir todo el ciclo de vida de las soluciones implementadas en los proyectos, implementar la experiencia adquirida, estandarizar procesos y automatizar la rutina. Al mismo tiempo, era necesario establecer el potencial de desarrollo, para mantener la capacidad de escalar y la máxima simplicidad, en términos de servicio, desarrollo y experiencia del usuario. Deben agregarse al proceso herramientas y técnicas que hayan demostrado ser efectivas en la práctica. Y todo inútil, interfiriendo con el trabajo debe ser eliminado.
El proceso
El ciclo de vida de cualquier solución permanece prácticamente sin cambios dependiendo de la escala y la complejidad del proyecto. Incluye: análisis, diseño, desarrollo, pruebas, implementación, mantenimiento, desmantelamiento. Para obtener la máxima eficiencia, cada uno de estos procesos debe verificarse y coordinarse con los procesos anteriores y posteriores, combinados en una especie de transportador automatizado, que puede replicarse para un número ilimitado de proyectos. La tarea se resolvió mediante la implementación del sistema en forma de microservicios conectados a través de API exportadas en contenedores aislados, que pueden implementarse tanto en el servicio en la nube como en la red local de la empresa.
Así es como se ve nuestra pila que implementa el proceso:
Intentamos minimizar el uso de servicios pagos con código fuente cerrado, lo que afectó positivamente el costo de propiedad. Casi todos los servicios son de código abierto y se ejecutan en Linux.
El proceso está diseñado para aprovechar al máximo cada miembro del equipo de desarrollo, y la estandarización y la automatización eliminan la complejidad y la rutina innecesarias.
Diseño (Servicios de diseño de aplicaciones)
Una de las etapas más significativas al comienzo de un proyecto es el diseño de una solución futura basada en un análisis de requisitos. La tarea principal es describir la arquitectura de la solución futura de la manera más clara, inequívoca y rápida, en términos comprensibles tanto para el desarrollador / ingeniero como para el consultor. Describir metadatos, algoritmos de procesos comerciales implementados. Al mismo tiempo, quería maximizar el uso de plantillas listas para usar y rápidamente personalizables para condiciones específicas que se pueden adaptar a los datos de entrada y obtener documentación del proyecto en la salida.
Hemos implementado la configuración "1C: DSS" como una interfaz única para el diseño de soluciones aplicadas, hemos modificado significativamente el concepto de describir procesos y funciones comerciales, así como diseñar TP (FDR). También automatizaron los procesos de generación de documentación a través de la integración con la funcionalidad 1C: DO y microservicios para generar documentos en formato docx.
"1C: DPR". Edición de información del proyecto:
"1C: DPR". Informe de proceso:
"1C: DPR". Edición de metadatos de objeto:
"1C: DPR". Edición de un diagrama de proceso de negocio:
Por cierto, podemos visualizar la relación entre los procesos comerciales y los objetos en el sistema, crear una lista de mejoras basadas en los requisitos registrados y obtener la documentación del proyecto automáticamente, lo que simplifica el proceso de gestión de cambios. Entonces, para planificar el proceso de desarrollo en detalle, para ver la complejidad, la conexión de las tareas, para determinar con mayor precisión el momento y el procedimiento para su implementación.
Por supuesto, no se puede decir que el proceso de diseño haya cambiado drásticamente, pero la unificación de los enfoques organizacionales y la automatización de muchas funciones ya contribuyen a la calidad de los proyectos.
Desarrollo (Servicios de Integración Continua, Inspección y Pruebas)
Intentamos centrarnos en la posibilidad de un control de calidad completo, continuo y automatizado del código desarrollado para garantizar el cumplimiento del estándar establecido en CROC. Además, incluso si contactamos con equipos de desarrollo de terceros, los métodos, herramientas y estándares de desarrollo pueden diferir significativamente de los adoptados por nosotros.
En el stand, cada confirmación de desarrollador inicia automáticamente el procedimiento para analizar la configuración en el directorio y la estructura de archivos a través del servicio Gitsync. Los cambios resultantes se indexan y se colocan en el repositorio de Git. En nuestro caso, este es el servicio de Gitlab. El mensaje de confirmación se genera automáticamente a partir del texto del comentario ingresado cuando los cambios se publicaron en el repositorio de configuración, y el autor de la confirmación en el sistema de control de versiones se asigna al usuario del repositorio de configuración. Durante el análisis del texto del comentario, podemos obtener información sobre la tarea de desarrollo y los costos laborales, pasarla al sistema de seguimiento de tareas, por ejemplo, Jira. Esto proporciona una imagen completa de la historia del desarrollo. Por ejemplo, podemos encontrar al autor por una línea de código, y los comentarios inteligentes sobre las confirmaciones le permiten controlar automáticamente el estado de las tareas y evaluar el código en relación con las tareas directamente en las tareas mismas.
Gitlab Ahora es posible comentar en cualquier línea del código colocado por el commit:
Gitlab Realice la "Revisión de código" con resaltado de sintaxis:
Gitlab Obtenga una imagen clara de los cambios en el código en la nueva confirmación:
Después de cada confirmación, el procedimiento para la inspección del código estático por parte del servicio SonarQube se inicia automáticamente en el repositorio. El código de confirmación BSL se verifica para cumplir con un conjunto de reglas (perfil de calidad) que describen el estándar de desarrollo del código. El procedimiento se realiza tanto para el código de la configuración que se está desarrollando como para los mecanismos externos: extensiones, informes y procesos externos y, en principio, cualquier otro código de proyecto, incluso en otros idiomas.
SonarQube:
Cada verificación actualiza la información de las métricas de calidad de la base del código rastreado, como:
- deuda técnica: trabajo total requerido para corregir errores identificados;
- umbral de calidad: los indicadores máximos permisibles de errores, vulnerabilidades y otras deficiencias del código, al alcanzar el cual, la publicación de la publicación se considera imposible;
- duplicación de código: el número de líneas de código que se repiten muchas veces dentro del marco de la configuración desarrollada;
- Complejidad ciclomática y cognitiva: algoritmos con una gran cantidad de ramas que complican el soporte y el refinamiento del código.
Las métricas recopiladas como resultado de la verificación ofrecen una representación visual del estado actual de la base del código del proyecto, le permiten evaluar la calidad, identificar riesgos y corregir rápidamente los errores.
El perfil de calidad se puede ampliar con sus propios conjuntos de reglas a través de XPath, y también debido al lanzamiento de nuevas reglas como parte de su propia implementación del complemento 1C. Esto le permite administrar de manera flexible los requisitos de calidad, basados en las realidades de una solución particular.
Inicio automatizado de procesos de análisis de configuración, inspección de código, pruebas automatizadas, etc. Lanza el Servicio de Integración Continua (Servicio Jenkins). El número y la naturaleza de tales líneas de ensamblaje se pueden cambiar de acuerdo con los detalles de un proyecto.
A pesar de la relativa complejidad del proceso descrito, todos los mecanismos de transporte que realizan la rutina están ocultos en el servicio en la nube. Y el desarrollador se ocupa de la interfaz familiar del configurador, y también puede desarrollar sus habilidades utilizando herramientas más avanzadas. Por ejemplo, git, un repositorio de mecanismos externos junto con editores de código de terceros y SonarLint, SourceTree, etc.
En el caso general, el desarrollador conecta la base de información al servicio de almacenamiento de configuración 1C, escribe el código y lo coloca en este servicio, iniciando así el proceso oculto en el stand. Si, como resultado de verificar una confirmación, se identifican deficiencias en el código, el desarrollador recibe una notificación por correo electrónico (o mensaje de chatbot) con un enlace a la descripción del error y recomendaciones para la corrección y evaluación temporal de los costos laborales en la interfaz del servicio SonarQube. Después de corregir el error, se produce una nueva confirmación y el proceso se repite, las tareas editadas se cierran automáticamente ... la deuda técnica disminuye. Por la misma lógica, se construye un proceso de prueba automatizado, donde cada confirmación inicia el lanzamiento de la implementación del entorno de prueba, conecta las pruebas necesarias de la biblioteca de prueba. Y después de la ejecución, se agrega información sobre errores durante las pruebas, así como sobre la cobertura del código con las pruebas.
Es difícil sobreestimar el efecto de la verificación continua y completa del código, seguido de pruebas automatizadas de la funcionalidad desarrollada. Esto le permite deshacerse de las consecuencias de largo alcance, hacer que las etapas de desarrollo sean transparentes y, junto con procesos adecuadamente construidos, evaluar objetivamente las calificaciones de los desarrolladores, lo que elimina los riesgos de dependencia de los contratistas. Al estimar los parámetros de la base de código actual, podemos identificar y mitigar rápidamente los riesgos emergentes, corregir fallas de diseño y responder a los requisitos cambiantes de manera oportuna.
La organización modular de la arquitectura del stand le permite incorporar nuevos módulos en el proceso, replicar la solución para la cantidad requerida de proyectos. Esquemáticamente, se ve así:
Pruebas (servicio de pruebas continuas)
Ya he hablado sobre el servicio de pruebas continuas, que está integrado en la tubería del proceso de desarrollo. Por el momento, se ha implementado una prueba de pruebas de humo y pruebas unitarias en el stand. La funcionalidad de las pruebas automáticas se implementa utilizando el marco xUnitFor1C.
El lanzamiento de los procesos de prueba, así como la inspección del código, está vinculado al evento de confirmación en el repositorio del proyecto. Para las pruebas unitarias, significa desarrollar una prueba en paralelo con el desarrollo de la funcionalidad. Inmediatamente antes de su implementación, la última configuración se implementa automáticamente en la base de información de prueba preparada. Luego se inicia el cliente, que ejecuta scripts de prueba para la funcionalidad ya implementada. La estrecha integración de los servicios de prueba automatizados con el complemento BSL SonarQube le permite calcular parámetros como la cobertura del código con las pruebas. El resultado de la ejecución de la prueba es un informe que se carga en el sistema de análisis y visualización de pruebas de ReportPortal. Este servicio es un portal de informes en el que se agregan datos sobre las pruebas (estadísticas y resultados), se realiza una capacitación básica del sistema sobre la categorización de caídas y una determinación automática adicional de las causas. Todos los parámetros de las ejecuciones de prueba están disponibles en una interfaz web conveniente con varios tableros para gráficos, cuadros (widgets). Para expandir las funciones del portal, puede usar sus propias extensiones.
Un servicio de prueba automatizado es otro paso que reduce los riesgos de ingresar a un código de lanzamiento que rompe la funcionalidad implementada anteriormente o funciona con errores.
ReportPortal. Tablero de instrumentos:
ReportPortal. Pruebas fallidas:
ReportPortal. Tipos de defectos:
ReportPortal. Edición de tipos de defectos:
Desarrollo
Al evaluar los resultados del trabajo realizado, vemos que desde el plan ya implementado, qué ideas ya están funcionando con éxito y cuáles aún no se han implementado.
De los planes para el futuro cercano, el desarrollo del stand es la creación de un portal de gestión de servicios de stand. La interfaz web del portal le permitirá trabajar con aplicaciones para conectar proyectos al stand, con una calculadora del costo de los servicios, con su implementación automatizada a pedido del proyecto. Como resultado, el gerente puede obtener inmediatamente un cálculo del costo de los servicios seleccionados y estimar los costos, determinar los desarrolladores para el proyecto.
Planeamos integrar el portal con una solución en la nube para operar sistemas 1C. Esto ayudará a implementar rápidamente soluciones estándar replicadas junto con los servicios de desarrollo implementados en el stand para una migración más eficiente de los sistemas del cliente a la nube CROC.
También planeamos integrar el portal de administración con el servicio de administración de configuración automatizada (implementación, configuración, eliminación). Esto reducirá el tiempo de implementación, simplificará la configuración y el mantenimiento del sistema. Y para aumentar el nivel de seguridad, introduciremos un servicio de autenticación de paso para todos los servicios del stand con el fin de utilizar la misma cuenta en todos ellos.
Si consideramos todo el proceso desde el punto de vista de la historia del ciclo completo del desarrollo de la solución, la tubería creada nos permitirá recopilar y agregar una gran cantidad de diversas métricas, tanto por artefactos del proyecto como por especialistas que participaron en él. Una retrospectiva tan detallada contribuirá a la acumulación y reutilización de la experiencia en la resolución de problemas complejos, para formar equipos de desarrolladores exitosos para un trabajo más eficiente y coordinado.UPD A petición de los comentarios, agregue una lista de productos de código abierto que utilizamos, con enlaces.