L'expérience de développement accumulée sur des projets grands et complexes se concrétise dans des outils et des pratiques d'ingénierie utiles, qui doivent enrichir les processus de développement, en les repensant à nouveau. C'est la reconnaissance de la valeur de l'expérience acquise en tant qu'artefact, le désir de se développer, qui nous a amenés à comprendre la nécessité de mettre en œuvre des outils et des pratiques dans les processus actuels. Et nous avons lancé une révision radicale des approches de conception de solutions et du processus de développement dans son ensemble. Cela n'a aucun sens de décrire les limites et les lacunes typiques de l'approche "classique" du développement d'équipe dans le monde 1C. Beaucoup a déjà été dit à ce sujet. Je ne décrirai que les schémas qui nous ont permis de rendre ces lacunes petites et presque pas effrayantes.
Alors faites connaissance, le
stand de développement intégré!Principes généraux d'architecture
En concevant l'architecture du stand, nous avons cherché à couvrir l'ensemble du cycle de vie des solutions mises en œuvre sur les projets, à mettre en œuvre l'expérience acquise, à standardiser les processus et à automatiser la routine. Dans le même temps, il était nécessaire de disposer du potentiel de développement, de maintenir la capacité d'évolutivité et la simplicité maximale, en termes de service, de développement et d'expérience utilisateur. Des outils et des techniques qui se sont révélés efficaces dans la pratique devraient être ajoutés au processus. Et tous inutiles, interférant avec le travail doivent être supprimés.
Le processus
Le cycle de vie de toute solution reste pratiquement inchangé en fonction de l'échelle et de la complexité du projet. Il comprend: l'analyse, la conception, le développement, les tests, la mise en œuvre, la maintenance, le déclassement. Pour obtenir une efficacité maximale, chacun de ces processus doit être vérifié et coordonné avec les processus précédents et suivants, combinés en une sorte de convoyeur automatisé, qui peut être reproduit pour un nombre illimité de projets. La tâche a été résolue par la mise en œuvre du système sous la forme de microservices connectés via des API exportées dans des conteneurs isolés, qui peuvent être déployés à la fois dans le service cloud et dans le réseau local de l'entreprise.
Voici à quoi ressemble notre pile implémentant le processus:
Nous avons essayé de minimiser l'utilisation de services payants avec un code source fermé, ce qui a eu une incidence positive sur le coût de possession. Presque tous les services sont open source et fonctionnent sous Linux.
Le processus est conçu de manière à tirer le meilleur parti de chaque membre de l'équipe de développement, et la normalisation et l'automatisation éliminent la complexité et la routine inutiles.
Conception (services de conception d'applications)
L'une des étapes les plus importantes au début d'un projet est la conception d'une future solution basée sur une analyse des besoins. La tâche principale est de décrire l'architecture de la future solution aussi clairement que possible, sans ambiguïté et rapidement, en termes compréhensibles à la fois pour le développeur / ingénieur et le consultant. Décrire les métadonnées, les algorithmes des processus opérationnels mis en œuvre. Dans le même temps, je souhaitais maximiser l'utilisation de modèles prêts à l'emploi et rapidement personnalisables pour des conditions spécifiques qui peuvent être adaptées aux données d'entrée et obtenir la documentation du projet à la sortie.
Nous avons implémenté la configuration «1C: DSS» comme une interface unique pour la conception de solutions appliquées, retravaillé de manière significative le concept de description des processus et fonctions métier, ainsi que la conception de TP (FDR). Ils ont également automatisé les processus de génération de documentation grâce à l'intégration avec la fonctionnalité 1C: DO et les microservices pour générer des documents au format docx.
"1C: DPR". Modification des informations sur le projet:
"1C: DPR". Rapport de processus:
"1C: DPR". Modification des métadonnées d'objet:
"1C: DPR". Modification d'un diagramme de processus métier:
Soit dit en passant, nous pouvons visualiser la relation entre les processus métier et les objets dans le système, créer une liste d'améliorations en fonction des exigences enregistrées et obtenir automatiquement la documentation du projet, ce qui simplifie le processus de gestion des changements. Ainsi, pour planifier le processus de développement en détail, pour voir la complexité, la connectivité des tâches, pour déterminer plus précisément le calendrier et la procédure de leur mise en œuvre.
Bien sûr, on ne peut pas dire que le processus de conception a radicalement changé, mais l'unification des approches organisationnelles et l'automatisation de nombreuses fonctions contribuent déjà à la qualité des projets.
Développement (intégration continue, services d'inspection et de test)
Nous avons essayé de nous concentrer sur la possibilité d'un contrôle qualité complet, continu et automatisé du code développé afin de garantir la conformité avec la norme établie dans CROC. De plus, même si nous engageons des équipes de développement tierces, les méthodes, outils et standards de développement peuvent différer sensiblement de ceux que nous avons adoptés.
Sur le stand, chaque développeur valide démarre automatiquement la procédure d'analyse de la configuration dans le répertoire et la structure de fichiers via le service Gitsync. Les modifications résultantes sont indexées et placées dans le référentiel Git. Dans notre cas, il s'agit du service Gitlab. Le message de validation est généré automatiquement à partir du texte de commentaire entré lorsque les modifications ont été publiées dans le référentiel de configuration, et l'auteur de la validation dans le système de contrôle de version est mappé à l'utilisateur du référentiel de configuration. Pendant l'analyse du texte du commentaire, nous pouvons obtenir des informations sur la tâche de développement et les coûts de main-d'œuvre, les transmettre au système de suivi des tâches, par exemple, Jira. Cela donne une image complète de l'histoire du développement. Par exemple, nous pouvons trouver l'auteur par une ligne de code, et les commentaires intelligents sur les validations vous permettent de contrôler automatiquement le statut des tâches et d'évaluer le code par rapport aux tâches directement dans les tâches elles-mêmes.
Gitlab Il est maintenant possible de commenter n'importe quelle ligne du code placé par le commit:
Gitlab Effectuer une "révision du code" avec mise en évidence de la syntaxe:
Gitlab Obtenez une image claire des changements de code dans le nouveau commit:
Après chaque validation, la procédure d'inspection statique du code par le service SonarQube démarre automatiquement dans le référentiel. La conformité du code de validation BSL avec un ensemble de règles (profil de qualité) décrivant la norme de développement du code est vérifiée. La procédure est effectuée à la fois pour le code de la configuration en cours d'élaboration et pour les mécanismes externes: extensions, rapports et processus externes, et, en principe, tout autre code de projet, même dans d'autres langues.
SonarQube:
Chaque vérification met à jour les informations des métriques de qualité de la base de code suivie, telles que:
- dette technique - main-d'œuvre totale requise pour corriger les erreurs identifiées;
- seuil de qualité - les indicateurs maximaux admissibles d'erreurs, de vulnérabilités et d'autres lacunes du code, une fois atteint, la publication de la version est considérée comme impossible;
- duplication de code - le nombre de lignes de code qui sont répétées plusieurs fois dans le cadre de la configuration développée;
- complexité cyclomatique et cognitive - algorithmes avec un grand nombre de branches qui compliquent le support et le raffinement du code.
Les métriques collectées à la suite de la vérification donnent une représentation visuelle de l'état actuel de la base de code du projet, permettent d'évaluer la qualité, d'identifier les risques et de corriger rapidement les erreurs.
Le profil de qualité peut être étendu avec ses propres ensembles de règles via XPath, et également en raison de la publication de nouvelles règles dans le cadre de sa propre implémentation du plugin 1C. Cela vous permet de gérer de manière flexible les exigences de qualité, en fonction des réalités d'une solution particulière.
Démarrage automatisé des processus d'analyse de la configuration, inspection du code, tests automatisés, etc. Lance le service d'intégration continue (service Jenkins). Le nombre et la nature de ces chaînes de montage peuvent être modifiés en fonction des spécificités d'un projet.
Malgré la relative complexité du processus décrit, tous les mécanismes de convoyage qui exécutent la routine sont cachés dans le service cloud. Et le développeur s'occupe de l'interface familière du configurateur, et peut également développer ses compétences en utilisant des outils plus avancés. Par exemple, git, un référentiel pour les mécanismes externes en collaboration avec des éditeurs de code tiers et SonarLint, SourceTree, etc.
Dans le cas général, le développeur connecte la base d'informations au service de stockage de configuration 1C, écrit le code et le place dans ce service, lançant ainsi le processus qui lui est caché sur le stand. Si, à la suite de la vérification d'une validation, des lacunes sont identifiées dans le code, le développeur reçoit une notification par e-mail (ou message chatbot) avec un lien vers la description de l'erreur et des recommandations pour la correction et l'évaluation temporaire des coûts de main-d'œuvre dans l'interface de service SonarQube. Après avoir corrigé l'erreur, un nouveau commit se produit et le processus se répète, les tâches éditées se ferment automatiquement ... la dette technique diminue. Par la même logique, un processus de test automatisé est construit, où chaque validation initie le lancement du déploiement de l'environnement de test, connecte les tests nécessaires à partir de la bibliothèque de tests. Et après l'exécution, les informations sur les erreurs lors des tests, ainsi que sur la couverture du code avec les tests, sont agrégées.
Il est difficile de surestimer l'effet d'une vérification continue et complète du code, suivie d'un test automatisé des fonctionnalités développées. Cela vous permet de vous débarrasser des conséquences de grande envergure, de rendre les étapes de développement transparentes et, couplées à des processus correctement construits, d'évaluer objectivement les qualifications des développeurs, ce qui élimine les risques de dépendance vis-à-vis des entrepreneurs. En estimant les paramètres de la base de code actuelle, nous pouvons rapidement identifier et atténuer les risques émergents, corriger les défauts de conception et répondre aux exigences changeantes en temps opportun.
L'organisation modulaire de l'architecture du stand vous permet d'intégrer de nouveaux modules dans le processus, de reproduire la solution pour le nombre de projets requis. Schématiquement, cela ressemble à ceci:
Test (service de test continu)
J'ai déjà parlé du service de test continu, qui est intégré dans le pipeline du processus de développement. À l'heure actuelle, une série d'essais de tests de fumée et de tests unitaires a été mise en œuvre sur le stand. La fonctionnalité des autotests est implémentée à l'aide du cadre xUnitFor1C.
Le lancement des processus de test, ainsi que l'inspection du code, est lié à l'événement commit dans le référentiel du projet. Pour les tests unitaires, cela signifie développer un test en parallèle avec le développement de fonctionnalités. Immédiatement avant leur mise en œuvre, la dernière configuration est automatiquement déployée dans la base d'informations de test préparée. Ensuite, le client est lancé, qui exécute des scripts de test pour la fonctionnalité déjà implémentée. L'intégration étroite des services de tests automatisés avec le plugin BSL SonarQube vous permet de calculer un paramètre tel que la couverture du code avec les tests. Le résultat de l'exécution du test est un rapport qui est téléchargé vers le système d'analyse et de visualisation des tests ReportPortal. Ce service est un portail de rapports dans lequel les données sur les essais (statistiques et résultats) sont agrégées, une formation de base du système sur la catégorisation des chutes est effectuée et une détermination automatique des causes. Tous les paramètres des tests sont disponibles dans une interface Web pratique avec différentes cartes pour les graphiques, les graphiques (widgets). Pour étendre les fonctions du portail, vous pouvez utiliser vos propres extensions.
Un service de test automatisé est une autre étape qui réduit les risques d'entrer dans un code de version qui rompt les fonctionnalités précédemment implémentées ou fonctionne avec des erreurs.
ReportPortal. Tableau de bord:
ReportPortal. Échecs des tests:
ReportPortal. Types de défauts:
ReportPortal. Modification des types de défauts:
Développement
En évaluant les résultats du travail effectué, nous voyons que d'après le plan déjà mis en œuvre, quelles idées fonctionnent déjà avec succès, qui doivent encore être mises en œuvre.
Parmi les projets à venir, le développement du stand est la création d'un portail de gestion des services du stand. L'interface web du portail vous permettra de travailler avec des applications de connexion de projets au stand, avec une calculatrice du coût des prestations, avec leur déploiement automatisé sur demande pour le projet. En conséquence, le gestionnaire peut immédiatement obtenir un calcul du coût des services sélectionnés et estimer les coûts, déterminer les développeurs du projet.
Nous prévoyons d'intégrer le portail à une solution cloud pour l'exploitation de systèmes 1C. Cela permettra de déployer rapidement des solutions standard répliquées en conjonction avec des services de développement mis en œuvre sur le stand pour une migration plus efficace des systèmes clients vers le cloud CROC.
Nous prévoyons également d'intégrer le portail de gestion au service de gestion de configuration automatisée (déploiement, configuration, suppression). Cela réduira le temps de déploiement, simplifiera la configuration et la maintenance du système. Et pour augmenter le niveau de sécurité, nous allons introduire un service d'authentification pass-through pour tous les services du stand afin d'utiliser le même compte dans chacun d'eux.
Si nous considérons l'ensemble du processus du point de vue de l'historique du cycle complet du développement de la solution, le pipeline créé nous permettra de collecter et d'agréger un grand nombre de métriques diverses à la fois par des artefacts de projet et par des spécialistes qui y ont participé. Une telle rétrospective détaillée contribuera à l'accumulation et à la réutilisation de l'expérience dans la résolution de problèmes complexes, pour former des équipes de développeurs performants pour un travail plus efficace et coordonné.UPD À la demande des commentaires, ajoutez une liste de produits open source que nous utilisons, avec des liens.