En NORBIT nos ocupamos de soluciones SRM . Hoy le contaremos sobre un proyecto especial para nuestro equipo: el desarrollo de la plataforma NBT BPMS. No solo creamos una solución comercial para el cliente, sino que desarrollamos nuestro propio producto desde cero; todo esto implica un enfoque completamente diferente para el diseño, el desarrollo, la gestión de equipos, la organización de los procesos de entrega de cambios y la planificación de lanzamientos.
En general, el artículo no trata solo sobre la hermosa KDPV. También aprenderá:
- sobre nuestra experiencia en el diseño de arquitectura de microservicios (la elección de herramientas, enfoques para usar estas herramientas, es decir, abstracción de su uso);
- sobre el desarrollo de un diseñador de objetos comerciales y la implementación de un diseñador de procesos comerciales en la solución para asegurar el enfoque de desarrollo Low-code;
- sobre cómo organizamos el trabajo en el proyecto y salvamos a los desarrolladores de algunos aspectos rutinarios o de distracción al trabajar en el sistema (interacciones abstractas entre servicios, autogeneración de código, atmósfera de equipo);
- y sobre qué meme nos ayudó en tiempos difíciles.
Nuestra división en la empresa NORBIT se dedica principalmente a la automatización de procesos de aprovisionamiento, para lo cual crea diversos tipos de soluciones en la plataforma .Net.
El desarrollo de tales soluciones comenzó con ASP.NET WebForms, luego se crearon nuevas versiones de estas soluciones sobre la base de ASP.NET MVC. Además de los desarrollos en .NET, hemos tenido y tenemos otros proyectos y soluciones, pero sin embargo, el desarrollo en .NET representa alrededor del 80% de todos los proyectos del departamento.
Las limitaciones de ASP.NET WebForms y ASP.NET MVC sugieren que para que las soluciones funcionen en estas plataformas, se requirió la implementación en un sistema operativo de la familia Windows Server, y en el lado de la base de datos (base de datos), se implementó un volumen de lógica que no permitió una transición rápida y sin dolor. en un DBMS que no sea MS SQL Server. Esto no supuso obstáculos ni dificultades antes del inicio de la transición masiva al software doméstico.
A partir de 2014-2015, el mercado de TI comenzó a moverse muy seriamente hacia la sustitución de importaciones, y el problema de implementar nuestros sistemas en sistemas operativos y DBMS que se ajustaran a los nuevos requisitos fue bastante grave. De hecho, se convirtió en la pregunta número 1.que necesitábamos resolver para que nuestras soluciones pudieran cubrir los requerimientos de los clientes potenciales a largo plazo.
Al mismo tiempo, teniendo competencias sólidas y un equipo bastante grande de desarrolladores de .NET, no parecía racional comenzar a desarrollar un nuevo kernel multiplataforma que no fuera .NET. El lanzamiento de la plataforma .NET Core de código abierto fue muy útil para nosotros, incluso por su compatibilidad con sistemas operativos como Windows, Linux y macOS.
La pregunta número 2 , que necesitábamos resolver, era que la mayoría de las soluciones creadas anteriormente asumían una programación obligatoria para agregar atributos de objetos comerciales o cambiar procesos comerciales en el sistema.
Está asociado a dos aspectos.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
Y la pregunta número 3 , a la que nos hemos enfrentado durante muchos años, es la imperfección de las arquitecturas de los sistemas que se están creando, que no permite reescribir rápidamente alguna parte sin la necesidad de reescribir módulos individuales, o crea un umbral de entrada suficientemente alto para programadores, analistas y probadores al conectarse a proyectos.
Hubo muchas más preguntas y problemas a la entrada del proyecto, que se discutirán más adelante. Pero estos tres (sustitución de importaciones y código abierto, código bajo, umbral de entrada bajo y tasa de inmersión rápida de los nuevos miembros del equipo) consideramos los clave que teníamos que resolver.
Diseño
Pensar en estas preguntas nos llevó a darnos cuenta de que necesitamos una especie de constructor con el que los analistas puedan "jugar" y diseñar un sistema (objetos de negocio y procesos de negocio) según las necesidades del cliente. Suena atrevido, pero es mucho más interesante que escribir otro sistema para un cliente. De hecho, decidimos fabricar nuestro producto en forma de constructor y desarrollarlo.
Definitivamente no se nos ocurrió nada revolucionario, y hay bastantes productos similares en el mercado, pero fue fundamental para nosotros resolver nuestras preguntas acumuladas, especialmente porque, por las razones descritas anteriormente, fue difícil para nosotros, por decirlo suavemente, seguir el camino de la refactorización de los sistemas existentes.
En la etapa de diseño, tuvimos que repensar el hecho de que no siempre sabemos de antemano quién es nuestro cliente potencial, grande o pequeño, exigente o leal, qué procesos de negocio tiene, qué tipo de infraestructura. Algunos de los requisitos para el futuro sistema comenzaron a surgir por sí solos: necesita escalado, necesita multiplataforma, necesita personalización flexible y rápida de objetos comerciales / procesos comerciales, una interfaz, probablemente un "vagón y un carrito pequeño" de integraciones. Se volvió aterrador, muy aterrador.
Pero, como dice uno de los líderes de nuestro equipo, "El elefante necesita ser devorado poco a poco, empezando por el pie". En esta etapa, nos planteamos dos tareas: la elección de la arquitectura de microservicio y la elección de herramientas. Sí, solo microservicio de inmediato (Martin Fowler recomienda MonolithFirst , pero decidimos desobedecerlo), porque con los monolitos hemos estado contigo durante mucho tiempo y es hora de aceptar el desafío para seguir adelante. Pero en serio, en nuestra opinión, el requisito de la escala horizontal del sistema por sí solo es suficiente.
Elección de arquitectura y herramientas
Al diseñar la arquitectura, perseguimos varios objetivos:
- abstracción de las herramientas utilizadas para poder sustituir una herramienta inadecuada por otra en cualquier momento;
- ( , );
- , .
Dado que nuestro equipo se especializa en tecnologías de Microsoft, se eligió .NET Core versión 2.1 como plataforma de implementación. En el momento en que comenzó el desarrollo de nuestro producto, esta versión era LTS (soporte a largo plazo), y para nosotros este era un criterio importante, ya que algunos sistemas operativos domésticos (en los que potencialmente podríamos implementar el sistema) solo admiten versiones .NET Core LTS ...
Decidieron hacer Frontend en React + TypeScript, ya que es fácil de aprender. Decidimos promover el enfoque de pila completa de los desarrolladores.
Decidimos sincronizar la interacción entre servicios, porque se suponía que nuestras cadenas de llamadas eran cortas y la comunicación entre servicios todavía se abstrae. Un servicio llama a otro servicio a través de un proxy abstracto. Y puede contener cualquier lógica. En nuestro caso, se trata de una llamada a otro servicio a través de http a través de Service Discovery. Este diseño nos permitió, por un lado, simplificar la vida de los desarrolladores (simplemente pueden usar la interfaz del servicio para llamarlo, pero de hecho, en el contenedor del servicio ASP.NET Core, la implementación registrada de esta interfaz es el mismo Proxy), y por el otro - para proporcionar escalado horizontal del sistema de forma automática, ya que siempre le preguntamos a Service Discovery cómo llamar a un servicio, y que, a su vez, puede dar una de las instancias en ejecución de este servicio.
En algún momento, la estructura del servicio se volvió estándar y realizamos extensiones para Visual Studio, que cuando se agrega un nuevo proyecto a la solución, genera una estructura de proyecto con una implementación mínima del servicio, nuevamente, para que los desarrolladores no tengan que hacer esta rutina. Además de esto, hicimos varios scripts para lanzar todo el sistema con un ligero movimiento de la mano (luego pensamos en el mismo despliegue rápido de un orquestador ligero del desarrollador).
El proceso de selección también fue bastante interesante. Tuvimos que decidir qué funcionalidad escribimos nosotros mismos y cuál sacamos "fuera de la caja" (hablando de herramientas existentes), pero, por supuesto, abstrayendo toda la interacción con ella, para que, si fuera necesario, fuera posible sustituir esta herramienta o biblioteca por otra implementación. Necesitábamos las siguientes herramientas: motor de búsqueda, motor de procesos de negocio (BPMN Engine), protocolo de descubrimiento de servicios (Service Discovery), planificador. Los criterios fueron diferentes: licencias, velocidad de trabajo, velocidad de inmersión del equipo de proyecto, etc. El resultado es la siguiente lista: Elasticsearch, Camunda, Consul, Hangfire.
Inmediatamente, dejaron de admitir al menos PostgreSQL y SQL Server, pero se centraron principalmente en PostgreSQL y la implementación en Linux. Software libre, ya sabes. Al respecto, sucedió una historia curiosa. Establecimos el soporte para SQL Server en las primeras etapas, pero realmente no esperábamos que algunos de nuestros clientes potenciales estuvieran interesados en implementar en Windows + SQL Server, por lo que pospusimos la prueba de esta configuración para más adelante (después de todo, ¡siempre se sabe de antemano qué entorno tiene el cliente!) ... Y luego, un día, haciendo otro banco de pruebas para un cliente potencial, ya estábamos listos para implementar AltLinux + PostgreSQL como de costumbre, pero de repente descubrimos que el cliente, sin embargo, cambió de opinión y decidió implementar en Windows + SQL Server, y tenemos dos días para hacer todo. preparar. Afortunadamente, el código olvidado y escrito durante mucho tiempo fue útil,quien nos brindó este soporte con mejoras menores, y logramos preparar todo a tiempo, y el sistema funcionó como si nada hubiera pasado (gloria a .NET Core).
Implementación de ideas comerciales
Abordamos la implementación con una lista preparada de etapas de trabajo, y la más importante de ellas fue obtener MVP (producto mínimo viable) en un futuro cercano. Casi desde las primeras iteraciones, comenzamos a trabajar con énfasis en obtener un prototipo lo más rápido posible con una parte visual que se pueda demostrar a los clientes (que eran nuestros líderes en un principio) periódicamente. Este enfoque, como era de esperar, contribuyó a repensar algunos de los conceptos previamente concebidos. Logré captar varias contradicciones y combatirlas de antemano. Se trata de diseñar una API web para la comunicación frontend y backend.
Constructor de objetos comerciales
Ya se mencionó anteriormente que una de las ideas clave del producto es la capacidad de crear una estructura de objeto comercial por parte de un usuario configurador. De hecho, comenzamos con la implementación del constructor de objetos comerciales. Las primeras versiones, por supuesto, eran más conceptuales, pero posteriormente nos dieron mucho que pensar. Los objetos de negocio que alguna vez fueron sin pretensiones con un par de campos simples se han convertido posteriormente en unidades multifuncionales de varios niveles con una amplia gama de todo tipo de configuraciones. Aprendimos a personalizar no solo campos simples, sino también campos con una opción de directorios jerárquicos, colecciones relacionadas de objetos con filtrado, etc.
El objeto de negocio generado por el ratón del configurador tiene suficientes metadatos para poder recopilar registros de búsqueda personalizados y diferentes formas de presentación.
El tema de la validación de objetos comerciales tampoco nos ha escapado. Rápidamente descubrimos que la validación no puede sino ir acompañada de la lógica empresarial que se requiere en la etapa de llenar el objeto empresarial con datos. “Si el“ campo 1 ”tiene“ valor 1 ”, entonces el“ campo 2 ”debe estar oculto” o “El campo 1 es la suma del campo 2 y el campo 3” son solo algunos de los ejemplos más simples que se pueden dar. Cuánto tiempo es corto, y ahora tenemos un motor de eventos en el que se puede configurar dicho comportamiento. Los eventos también se pueden configurar con el mouse. Ya se han implementado muchas opciones, incluidos cálculos complejos. Pero este es un tema para otra conversación. Escriba en los comentarios si resolvió un problema similar, sería interesante intercambiar sentimientos.
Diseñador de procesos de negocio
Como nos gusta repetir: "¿Quién necesita objetos comerciales sin procesos comerciales?"
resultados
Ha pasado año y medio desde el inicio del proyecto. El equipo se ha multiplicado por diez, la
Lo primero que parece genial es el hecho de que cuanta más funcionalidad hacemos, más ideas obtenemos. Parece que nos estamos moviendo no desde el principio del proyecto hasta su finalización, sino simplemente desde el principio y más allá; este es un aspecto importante. Después de muchos años de soportar soluciones listas para usar (y esto sucede muy a menudo en la vida de un especialista en TI), esta situación es muy motivadora.
Segundomega-sentimiento es ver a un equipo tan motivado y estar dentro de él. El proceso de creación de un nuevo producto no es solo una secuencia de tareas y etapas. Esta es, en primer lugar, la atmósfera. La atmósfera del hecho de que muy a menudo haces lo que nunca antes has hecho, aunque hayas participado en decenas de proyectos. Cada miembro del equipo lo respira y en algún momento se da cuenta de que salió de la zona de confort después del primer aliento. Y la tarea más difícil y principal es hacer que esta atmósfera sea fresca, cómoda e interesante. No podemos escondernos de errores, fechas límite, etc., pero la falta de un entorno de apoyo en el que todos nos encontremos puede ser mucho más destructiva.
Tratamos de prestar especial atención al proceso de desarrollo de nuestro producto. Este proceso no es estático. Sufre cambios, si es necesario, pero permite solucionar cómodamente sus problemas y ayudar a sus compañeros a hacerlo.
PD: Es difícil describir todo en detalle en un artículo, por lo que resultó ser más una descripción general. Realmente esperamos que haya encontrado algo interesante en él, y estaremos encantados de responder sus preguntas en los comentarios o describir algún aspecto de nuestro sistema con más detalle en un artículo separado.