Chez NORBIT, nous traitons des solutions SRM . Aujourd'hui, nous allons vous parler d'un projet spécial pour notre équipe - le développement de la plate-forme NBT BPMS. Nous n'avons pas simplement créé une solution commerciale pour le client, mais développé notre propre produit à partir de zéro - tout cela implique une approche complètement différente de la conception, du développement, de la gestion d'équipe, de l'organisation des processus de livraison des changements et de la planification des versions.
En général, l'article ne concerne pas seulement le magnifique KDPV. Vous apprendrez également:
- sur notre expérience dans la conception d'architecture de microservices (le choix des outils, les approches d'utilisation de ces outils, à savoir l'abstraction de leur utilisation);
- sur le développement d'un concepteur d'objets métiers et l'implémentation d'un concepteur de processus métiers dans la solution pour assurer l'approche de développement Low-code;
- sur la façon dont nous avons organisé le travail sur le projet et sauvé les développeurs de certains aspects routiniers ou distrayants lors du travail sur le système (interactions interservices abstraites, génération automatique de code, atmosphère d'équipe);
- et sur ce que meme nous a aidé dans les moments difficiles.
Notre division de la société NORBIT est principalement engagée dans l'automatisation des processus d'approvisionnement, pour lesquels elle crée différents types de solutions sur la plate-forme .Net.
Le développement de telles solutions a commencé avec ASP.NET WebForms, puis de nouvelles versions de ces solutions ont été créées sur la base d'ASP.NET MVC. En plus du développement sur .NET, nous avons eu et avons encore d'autres projets et solutions, mais néanmoins, le développement sur .NET représente environ 80% de tous les projets du département.
Les limitations des formulaires Web ASP.NET et ASP.NET MVC suggèrent que pour que les solutions fonctionnent sur ces plates-formes, le déploiement sur un système d'exploitation de la famille Windows Server était nécessaire, et du côté de la base de données (base de données), un volume de logique a été implémenté qui ne permettait pas une transition rapide et sans douleur sur un SGBD autre que MS SQL Server. Cela ne prévoyait aucun obstacle ni aucune difficulté avant le début de la transition massive vers les logiciels nationaux.
À partir de 2014-2015, le marché informatique a commencé à évoluer très sérieusement vers la substitution des importations, et le problème du déploiement de nos systèmes sur des systèmes d'exploitation et des SGBD qui répondraient aux nouvelles exigences était assez aigu. En fait, c'est devenu la question numéro 1que nous devions résoudre pour que nos solutions puissent couvrir les besoins des clients potentiels sur le long terme.
Dans le même temps, ayant de fortes compétences et une équipe assez importante de développeurs .NET, il ne semblait pas rationnel de commencer à développer un nouveau noyau multiplateforme non sur .NET. La sortie de la plateforme open source .NET Core a été la bienvenue pour nous, notamment en raison de sa compatibilité avec les systèmes d'exploitation tels que Windows, Linux et macOS.
La question numéro 2 , que nous devions résoudre, était que la plupart des solutions précédemment créées supposaient une programmation obligatoire pour ajouter des attributs d'objets métier ou modifier les processus métier dans le système.
Il est associé à deux aspects.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
Et la question numéro 3 , à laquelle nous sommes confrontés depuis de nombreuses années, est l'imperfection des architectures des systèmes en cours de création, qui ne permet pas de réécrire rapidement une partie sans avoir besoin de réécrire des modules individuels, ou crée un seuil d'entrée suffisamment élevé pour les programmeurs, analystes et testeurs lors de la connexion à projets.
Il y avait beaucoup plus de questions et de problèmes à l'entrée du projet, qui seront discutés plus tard. Mais ces trois (importation de substitution et open-source, Low-code, seuil d'entrée bas et taux d'immersion rapide des nouveaux membres de l'équipe), nous considérons les principaux que nous avons dû résoudre.
Conception
La réflexion sur ces questions nous a conduit à réaliser que nous avons besoin d'une sorte de constructeur avec lequel les analystes peuvent «jouer» et concevoir un système (objets métier et processus métiers) en fonction des besoins du client. Cela semble audacieux, mais c'est beaucoup plus intéressant que d'écrire un autre système pour un client. En fait, nous avons décidé de fabriquer notre produit sous la forme d'un constructeur et de le développer.
Nous n'avons certainement rien proposé de révolutionnaire, et il existe pas mal de produits similaires sur le marché, mais il était fondamentalement important pour nous de résoudre nos questions accumulées, d'autant plus que, pour les raisons exposées précédemment, il nous était difficile, pour le moins dire, de suivre la voie de la refactorisation des systèmes existants.
Au stade de la conception, nous avons dû repenser le fait que nous ne savons pas toujours à l'avance qui est notre client potentiel, grand ou petit, exigeant ou fidèle, quels processus métier il dispose, quel type d'infrastructure. Certaines des exigences du futur système ont commencé à émerger d'elles-mêmes: vous avez besoin d'évolutivité, vous avez besoin de multiplate-forme, vous avez besoin d'une personnalisation flexible et rapide des objets métier / processus métier, d'une interface, probablement un «wagon et un petit chariot» d'intégrations. C'est devenu effrayant, très effrayant.
Mais, comme le dit l'un de nos chefs d'équipe, «l'éléphant doit être mangé petit à petit, en commençant par le pied». A ce stade, nous nous sommes fixé deux tâches: le choix d'une architecture de microservice et le choix des outils. Oui, juste microservice tout de suite (Martin Fowler recommande MonolithFirst , mais nous avons décidé de lui désobéir), car avec les monolithes, nous sommes depuis longtemps sur "vous" et il est temps d'accepter le défi de passer à autre chose. Mais sérieusement, l'exigence d'une mise à l'échelle horizontale du système suffit à elle seule à notre avis.
Choix de l'architecture et des outils
Lors de la conception de l'architecture, nous avons poursuivi plusieurs objectifs:
- abstraction des outils utilisés afin de pouvoir remplacer à tout moment un outil inadapté par un autre;
- ( , );
- , .
Notre équipe étant spécialisée dans les technologies Microsoft, .NET Core version 2.1 a été choisie comme plateforme d'implémentation. Au moment où le développement de notre produit a commencé, cette version était LTS (support à long terme), et pour nous c'était un critère important, car certains systèmes d'exploitation nationaux (sur lesquels nous pourrions potentiellement déployer le système) ne supportent que les versions .NET Core LTS ...
Ils ont décidé de créer Frontend en React + TypeScript, car il est facile à apprendre. Nous avons décidé de promouvoir l'approche full stack des développeurs.
Nous avons décidé de rendre la communication interservice synchrone, parce que nos chaînes d'appels étaient censées être courtes et que la communication interservices est toujours abstraite. Un service appelle un autre service via un proxy abstrait. Et il peut contenir n'importe quelle logique. Dans notre cas, il s'agit d'un appel à un autre service via http via Service Discovery. Une telle conception nous a permis, d'une part, de simplifier la vie des développeurs (ils peuvent simplement utiliser l'interface de service pour l'appeler, mais en fait, dans le conteneur de services ASP.NET Core, l'implémentation enregistrée de cette interface est le même Proxy), et d'autre part - pour fournir automatiquement une mise à l'échelle horizontale du système, puisque nous demandons toujours à Service Discovery comment appeler un service, ce qui, à son tour, peut donner l'une des instances en cours d'exécution de ce service.
À un moment donné, la structure du service est devenue standard et nous avons créé des extensions pour Visual Studio, qui, lorsqu'un nouveau projet est ajouté à la solution, génère une structure de projet avec une implémentation de service minimale, encore une fois, afin que les développeurs n'aient pas à faire cette routine. En plus de cela, nous avons fait plusieurs scripts pour lancer l'ensemble du système avec un léger mouvement de la main (plus tard, nous avons pensé au même déploiement rapide d'un orchestrateur léger du développeur).
Le processus de sélection était également très intéressant. Nous avons dû décider - quelle fonctionnalité nous écrivons nous-mêmes, et ce que nous prenons «hors de la boîte» (en parlant d'outils existants), mais, bien sûr, en faisant abstraction de toute interaction avec elle, de sorte que, si nécessaire, il soit possible de remplacer cet outil ou bibliothèque par une autre implémentation. Nous avions besoin des outils suivants: moteur de recherche, moteur de processus métier (BPMN Engine), protocole de découverte de service (Service Discovery), planificateur. Les critères étaient différents: licences, rapidité de travail, vitesse d'immersion de l'équipe projet, etc. Le résultat est la liste suivante: Elasticsearch, Camunda, Consul, Hangfire.
Nous avons immédiatement mis en place un support pour au moins PostgreSQL et SQL Server, mais nous nous sommes principalement concentrés sur PostgreSQL et le déploiement sous Linux. Logiciel gratuit, vous savez. À cet égard, une histoire curieuse s'est produite. Nous avons mis en place la prise en charge de SQL Server au début, mais nous ne nous attendions pas particulièrement à ce que certains de nos clients potentiels soient intéressés par le déploiement sur Windows + SQL Server, nous avons donc reporté le test de cette configuration à plus tard (après tout, on sait toujours à l'avance quel environnement le client a?!) ... Et puis un jour, en faisant un autre banc d'essai pour un client potentiel, nous étions déjà prêts à déployer AltLinux + PostgreSQL comme d'habitude, mais du coup nous découvrons que le client a quand même changé d'avis et a décidé de déployer sur Windows + SQL Server, et nous avons deux jours pour tout faire préparer. Heureusement, le code longtemps écrit et oublié s'est avéré utile,qui nous a fourni ce support avec des améliorations mineures, et nous avons réussi à tout préparer à temps, et le système a fonctionné comme si de rien n'était (gloire à .NET Core).
Mise en œuvre d'idées commerciales
Nous avons abordé la mise en œuvre avec une liste préparée des étapes de travail, et la plus importante d'entre elles était d'obtenir MVP (produit minimum viable) dans un proche avenir. Presque dès les premières itérations, nous avons commencé à travailler en mettant l'accent sur l'obtention d'un prototype le plus rapidement possible avec une partie visuelle qui peut être présentée périodiquement aux clients (qui étaient nos leaders au début). Cette approche, comme prévu, a contribué à repenser certains des concepts précédemment conçus. J'ai réussi à attraper plusieurs contradictions et à les combattre à l'avance. Il s'agit de concevoir une API Web pour la communication frontend et backend.
Constructeur d'objet métier
Il a déjà été mentionné ci-dessus que l'une des idées clés du produit est la possibilité de créer une structure d'objet métier par un utilisateur configurateur. Nous avons en fait commencé par l'implémentation du constructeur d'objets métier. Les premières versions, bien sûr, étaient plus conceptuelles, mais elles nous ont ensuite donné matière à réflexion. Les objets métier autrefois sans prétention avec quelques champs simples ont ensuite évolué en unités multifonctionnelles à plusieurs niveaux avec une large gamme de toutes sortes de paramètres. Nous avons appris à personnaliser non seulement des champs simples, mais également des champs avec un choix parmi des répertoires hiérarchiques, des collections d'objets connexes avec filtrage, etc.
L'objet métier généré par la souris du configurateur a suffisamment de métadonnées pour compiler des registres de recherche personnalisés et différents formulaires de présentation.
La question de la validation des objets métier ne nous a pas non plus épargnés. Nous avons rapidement découvert que la validation ne peut qu'être accompagnée de la logique métier requise au stade du remplissage de l'objet métier avec des données. «Si le« champ 1 »a la« valeur 1 », alors« le champ 2 »doit être masqué» ou «le champ 1 est la somme du champ 2 et du champ 3» ne sont que quelques exemples parmi les plus simples que l'on puisse donner. Combien de temps est-il court, et nous avons maintenant un moteur d'événements dans lequel un tel comportement peut être configuré. Les événements peuvent également être configurés avec la souris. De nombreuses options ont déjà été implémentées, y compris des calculs complexes. Mais c'est un sujet pour une autre conversation. Veuillez écrire dans les commentaires si vous avez résolu un problème similaire, il serait intéressant d'échanger des sentiments.
Concepteur de processus métier
Comme nous aimons le répéter: "Qui a besoin d'objets métier sans processus métier?"
résultats
Un an et demi s'est écoulé depuis le début du projet. L'équipe a décuplé, le
La première chose qui semble méga-cool est le fait que plus nous créons de fonctionnalités, plus nous obtenons d'idées. On a l'impression que nous n'allons pas du début du projet à son achèvement, mais simplement du début et plus loin - c'est un aspect important. Après de nombreuses années à supporter des solutions toutes faites (et cela arrive très souvent dans la vie d'un informaticien), cet état de fait est très motivant.
SecondeLe méga-sentiment est de regarder une équipe aussi motivée et d'être à l'intérieur. Le processus de création d'un nouveau produit n'est pas seulement une séquence de tâches et d'étapes. C'est, tout d'abord, l'atmosphère. L'atmosphère du fait que vous faites très souvent ce que vous n'avez jamais fait auparavant, même si vous avez participé à des dizaines de projets. Chaque membre de l'équipe le respire et se rend compte à un moment donné qu'il a quitté la zone de confort après la première respiration. Et la tâche la plus difficile et principale est de rendre cette atmosphère fraîche, confortable et intéressante. Nous ne pouvons pas nous cacher des bogues, des délais, etc., mais l'absence d'un environnement favorable dans lequel nous nous trouvons tous peut être beaucoup plus destructrice.
Nous essayons d'accorder une attention particulière au processus de développement de notre produit. Ce processus n'est pas statique. Il subit des changements, si nécessaire, mais il permet de résoudre confortablement ses problèmes et d'aider ses collègues à le faire.
PS Il est difficile de tout décrire en détail dans un seul article, il s'est donc avéré être plus global. Nous espérons vraiment que vous y avez trouvé quelque chose d'intéressant, et nous serons heureux de répondre à vos questions dans les commentaires ou de décrire certains aspects de notre système plus en détail dans un article séparé.