Die bei großen und komplexen Projekten gesammelten Entwicklungserfahrungen sind in nützlichen Tools und Konstruktionspraktiken enthalten, die die Entwicklungsprozesse bereichern und erneut überdenken müssen. Es war die Anerkennung des Wertes der erworbenen Erfahrung als Artefakt, der Wunsch zu entwickeln, der uns dazu brachte, die Notwendigkeit zu verstehen, Werkzeuge und Praktiken in aktuellen Prozessen zu implementieren. Und wir haben eine radikale Überprüfung der Ansätze zur Entwicklung von Lösungen und des gesamten Entwicklungsprozesses eingeleitet. Es macht keinen Sinn, die typischen Einschränkungen und Mängel des "klassischen" Ansatzes zur Teamentwicklung in der 1C-Welt zu beschreiben. Zu diesem Thema wurde bereits viel gesagt. Ich werde nur die Muster beschreiben, die es uns ermöglichten, diese Mängel klein und fast nicht beängstigend zu machen.
Machen Sie sich also mit dem
integrierten Entwicklungsstand vertraut
!Allgemeine Prinzipien der Architektur
Bei der Gestaltung der Standarchitektur haben wir versucht, den gesamten Lebenszyklus der in den Projekten implementierten Lösungen abzudecken, die gesammelten Erfahrungen umzusetzen, Prozesse zu standardisieren und die Routine zu automatisieren. Gleichzeitig war es notwendig, das Entwicklungspotential zu legen, um die Skalierbarkeit und maximale Einfachheit in Bezug auf Service, Entwicklung und Benutzererfahrung aufrechtzuerhalten. Werkzeuge und Techniken, die sich in der Praxis als wirksam erwiesen haben, sollten dem Prozess hinzugefügt werden. Und alles Nutzlose, das die Arbeit stört, muss beseitigt werden.
Der Prozess
Der Lebenszyklus einer Lösung bleibt je nach Umfang und Komplexität des Projekts praktisch unverändert. Es umfasst: Analyse, Design, Entwicklung, Test, Implementierung, Wartung, Stilllegung. Um maximale Effizienz zu erzielen, sollte jeder dieser Prozesse überprüft und mit früheren und nachfolgenden Prozessen koordiniert werden. Dies sollte zu einer Art automatisiertem Förderer kombiniert werden, der für eine unbegrenzte Anzahl von Projekten repliziert werden kann. Die Aufgabe wurde durch die Implementierung des Systems in Form von Microservices gelöst, die über exportierte APIs in isolierten Containern verbunden sind und sowohl im Cloud-Service als auch im lokalen Netzwerk des Unternehmens bereitgestellt werden können.
So sieht unser Stack aus, der den Prozess implementiert:
Wir haben versucht, die Nutzung kostenpflichtiger Dienste mit geschlossenem Quellcode zu minimieren, was sich positiv auf die Betriebskosten auswirkte. Fast alle Dienste sind Open Source und laufen unter Linux.
Der Prozess ist so konzipiert, dass wir jedes Mitglied des Entwicklungsteams optimal nutzen können. Durch Standardisierung und Automatisierung werden unnötige Komplexität und Routine vermieden.
Design (Application Design Services)
Eine der wichtigsten Phasen zu Beginn eines Projekts ist der Entwurf einer zukünftigen Lösung auf der Grundlage einer Anforderungsanalyse. Die Hauptaufgabe besteht darin, die Architektur der zukünftigen Lösung so klar wie möglich, eindeutig und schnell zu beschreiben, sowohl für den Entwickler / Ingenieur als auch für den Berater verständlich. Beschreiben von Metadaten und Algorithmen implementierter Geschäftsprozesse. Gleichzeitig wollte ich die Verwendung von vorgefertigten, schnell anpassbaren Vorlagen für bestimmte Bedingungen maximieren, die an die Eingabedaten angepasst werden können, und am Ausgang Projektdokumentation erhalten.
Wir haben die Konfiguration „1C: DSS“ als eine einzige Schnittstelle für den Entwurf angewandter Lösungen implementiert, das Konzept der Beschreibung von Geschäftsprozessen und -funktionen sowie den Entwurf von TP (FDR) erheblich überarbeitet. Sie automatisierten auch die Prozesse der Dokumentationserstellung durch Integration in die 1C: DO-Funktionalität und Microservices zum Generieren von Dokumenten im docx-Format.
"1C: DPR". Projektinformationen bearbeiten:
"1C: DPR". Prozessbericht:
"1C: DPR". Bearbeiten von Objektmetadaten:
"1C: DPR". Bearbeiten eines Geschäftsprozessdiagramms:
Übrigens können wir die Beziehung zwischen Geschäftsprozessen und Objekten im System visualisieren, eine Liste von Verbesserungen basierend auf registrierten Anforderungen erstellen und die Projektdokumentation automatisch abrufen, was den Änderungsmanagementprozess vereinfacht. Um den Entwicklungsprozess im Detail zu planen, die Komplexität und die Verbundenheit der Aufgaben zu erkennen und den Zeitpunkt und das Verfahren für ihre Implementierung genauer zu bestimmen.
Natürlich kann nicht gesagt werden, dass sich der Entwurfsprozess dramatisch geändert hat, aber die Vereinheitlichung der organisatorischen Ansätze und die Automatisierung vieler Funktionen tragen bereits zur Qualität der Projekte bei.
Entwicklung (kontinuierliche Integration, Inspektion und Prüfung)
Wir haben versucht, uns auf die Möglichkeit einer umfassenden, kontinuierlichen und automatisierten Qualitätskontrolle des entwickelten Codes zu konzentrieren, um die Einhaltung des in CROC festgelegten Standards zu gewährleisten. Selbst wenn wir Entwicklungsteams von Drittanbietern beauftragen, können sich die Methoden, Werkzeuge und Entwicklungsstandards erheblich von den von uns übernommenen unterscheiden.
Am Stand startet jedes Entwickler-Commit automatisch die Prozedur zum Parsen der Konfiguration in das Verzeichnis und die Dateistruktur über den Gitsync-Dienst. Die resultierenden Änderungen werden indiziert und in das Git-Repository gestellt. In unserem Fall ist dies der Gitlab-Dienst. Die Festschreibungsnachricht wird automatisch aus dem Kommentartext generiert, der eingegeben wurde, als die Änderungen im Konfigurationsrepository veröffentlicht wurden, und der Autor des Festschreibens im Versionskontrollsystem wird dem Benutzer des Konfigurationsrepositorys zugeordnet. Während des Parsens aus dem Kommentartext können wir Informationen über die Entwicklungsaufgabe und die Arbeitskosten abrufen und diese an das Aufgabenverfolgungssystem weitergeben, z. B. Jira. Dies gibt ein umfassendes Bild der Entwicklungsgeschichte. Zum Beispiel können wir den Autor anhand einer Codezeile finden, und mit intelligenten Kommentaren zu Commits können Sie den Status von Aufgaben automatisch steuern und den Code in Bezug auf Aufgaben direkt in den Aufgaben selbst auswerten.
Gitlab Jetzt ist es möglich, eine beliebige Zeile des vom Commit platzierten Codes zu kommentieren:
Gitlab Führen Sie "Code Review" mit Syntaxhervorhebung durch:
Gitlab Machen Sie sich ein klares Bild von den Codeänderungen im neuen Commit:
Nach jedem Commit wird die Prozedur für die Überprüfung des statischen Codes durch den SonarQube-Dienst automatisch im Repository gestartet. Der BSL-Festschreibungscode wird auf Übereinstimmung mit einer Reihe von Regeln (Qualitätsprofil) überprüft, die den Codeentwicklungsstandard beschreiben. Das Verfahren wird sowohl für den Code der zu entwickelnden Konfiguration als auch für externe Mechanismen durchgeführt: Erweiterungen, externe Berichte und Prozesse sowie im Prinzip jeden anderen Projektcode, auch in anderen Sprachen.
SonarQube:
Bei jeder Überprüfung werden die Informationen der Qualitätsmetriken für die nachverfolgte Codebasis aktualisiert, z.
- technische Schulden - Gesamtarbeit, die erforderlich ist, um festgestellte Fehler zu korrigieren;
- Qualitätsschwelle - die maximal zulässigen Indikatoren für Fehler, Schwachstellen und andere Mängel des Codes, bei deren Erreichen die Veröffentlichung der Veröffentlichung als unmöglich angesehen wird;
- Codeduplizierung - die Anzahl der Codezeilen, die im Rahmen der entwickelten Konfiguration viele Male wiederholt werden;
- zyklomatische und kognitive Komplexität - Algorithmen mit einer großen Anzahl von Zweigen, die die Unterstützung und Verfeinerung des Codes erschweren.
Die als Ergebnis der Überprüfung gesammelten Metriken geben eine visuelle Darstellung des aktuellen Status der Codebasis des Projekts, ermöglichen die Bewertung der Qualität, die Identifizierung von Risiken und die schnelle Korrektur von Fehlern.
Das Qualitätsprofil kann über XPath mit eigenen Regelsätzen erweitert werden, und dies ist auch auf die Veröffentlichung neuer Regeln im Rahmen der eigenen Implementierung des 1C-Plugins zurückzuführen. Auf diese Weise können Sie Qualitätsanforderungen flexibel verwalten, basierend auf den Realitäten einer bestimmten Lösung.
Automatischer Start von Konfigurationsanalyseprozessen, Codeüberprüfung, automatisierten Tests usw. Startet den Continuous Integration Service (Jenkins Service). Die Anzahl und Art solcher Montagelinien kann gemäß den Besonderheiten eines Projekts geändert werden.
Trotz der relativen Komplexität des beschriebenen Prozesses sind alle Fördermechanismen, die die Routine ausführen, im Cloud-Service verborgen. Der Entwickler befasst sich mit der vertrauten Oberfläche des Konfigurators und kann seine Fähigkeiten auch mit fortgeschritteneren Tools entwickeln. Zum Beispiel git, ein Repository für externe Mechanismen in Verbindung mit Code-Editoren von Drittanbietern und SonarLint, SourceTree usw.
Im allgemeinen Fall verbindet der Entwickler die Informationsbasis mit dem 1C-Konfigurationsspeicherdienst, schreibt den Code und platziert ihn in diesem Dienst, wodurch der vor ihm verborgene Prozess am Stand gestartet wird. Wenn infolge der Überprüfung eines Commits Mängel im Code festgestellt werden, erhält der Entwickler eine E-Mail-Benachrichtigung (oder Chatbot-Nachricht) mit einem Link zur Fehlerbeschreibung und Empfehlungen zur Korrektur und vorübergehenden Bewertung der Arbeitskosten in der SonarQube-Serviceschnittstelle. Nachdem der Fehler behoben wurde, tritt ein neues Commit auf und der Prozess wird wiederholt. Bearbeitete Aufgaben werden automatisch geschlossen. Die technische Verschuldung nimmt ab. Nach der gleichen Logik wird ein automatisierter Testprozess erstellt, bei dem jedes Commit den Start der Bereitstellung der Testumgebung initiiert und die erforderlichen Tests aus der Testbibliothek verbindet. Nach dem Ausführen werden Informationen zu Fehlern während des Testens sowie zur Codeabdeckung bei Tests zusammengefasst.
Es ist schwierig, den Effekt einer kontinuierlichen, umfassenden Codeüberprüfung zu überschätzen, gefolgt von einem automatisierten Testen der entwickelten Funktionalität. Auf diese Weise können Sie weitreichende Konsequenzen beseitigen, die Entwicklungsphasen transparent machen und in Verbindung mit ordnungsgemäß erstellten Prozessen die Qualifikationen der Entwickler objektiv bewerten, wodurch das Risiko einer Abhängigkeit von Auftragnehmern beseitigt wird. Durch die Schätzung der Parameter der aktuellen Codebasis können wir neu auftretende Risiken schnell identifizieren und mindern, Konstruktionsfehler korrigieren und rechtzeitig auf sich ändernde Anforderungen reagieren.
Die modulare Organisation der Standarchitektur ermöglicht es Ihnen, neue Module in den Prozess einzubetten und die Lösung für die erforderliche Anzahl von Projekten zu replizieren. Schematisch sieht es so aus:
Testen (kontinuierlicher Testservice)
Ich habe bereits über den kontinuierlichen Testdienst gesprochen, der in die Pipeline des Entwicklungsprozesses integriert ist. Derzeit wurde am Stand ein Testlauf mit Rauch- und Unit-Tests durchgeführt. Die Funktionalität von Autotests wird mithilfe des xUnitFor1C-Frameworks implementiert.
Der Start von Testprozessen sowie die Codeprüfung sind an das Festschreibungsereignis im Projektrepository gebunden. Für Unit-Tests bedeutet dies, einen Test parallel zur Entwicklung der Funktionalität zu entwickeln. Unmittelbar vor ihrer Implementierung wird die neueste Konfiguration automatisch in der vorbereiteten Testinformationsbasis bereitgestellt. Anschließend wird der Client gestartet, der Testskripte für die bereits implementierte Funktionalität ausführt. Durch die enge Integration automatisierter Testdienste in das BSL SonarQube-Plugin können Sie Parameter wie die Codeabdeckung mit Tests berechnen. Das Ergebnis des Testlaufs ist ein Bericht, der in das Testanalyse- und Visualisierungssystem ReportPortal hochgeladen wird. Dieser Service ist ein Berichtsportal, in dem Daten zu Testläufen (Statistiken und Ergebnisse) aggregiert, eine Grundschulung des Systems zur Kategorisierung von Stürzen durchgeführt und die Ursachen automatisch weiter ermittelt werden. Alle Parameter von Testläufen sind in einer praktischen Weboberfläche mit verschiedenen Karten für Grafiken, Diagramme (Widgets) verfügbar. Um die Funktionen des Portals zu erweitern, können Sie Ihre eigenen Erweiterungen verwenden.
Ein automatisierter Testdienst ist ein weiterer Schritt, der das Risiko verringert, in einen Release-Code zu gelangen, der zuvor implementierte Funktionen beeinträchtigt oder mit Fehlern arbeitet.
ReportPortal. Dashboard:
ReportPortal. Fehlgeschlagene Testläufe:
ReportPortal. Arten von Mängeln:
ReportPortal. Bearbeiten von Fehlertypen:
Entwicklung
Wenn wir die Ergebnisse der geleisteten Arbeit bewerten, sehen wir aus dem bereits umgesetzten Plan, welche Ideen bereits erfolgreich funktionieren und welche noch umgesetzt werden müssen.
Von den Plänen für die nahe Zukunft ist die Entwicklung des Standes die Schaffung eines Portalservice-Verwaltungsportals. Über die Weboberfläche des Portals können Sie mit Anwendungen zum Verbinden von Projekten mit dem Stand arbeiten, mit einem Taschenrechner für die Kosten von Diensten, deren automatische Bereitstellung auf Anfrage für das Projekt erfolgt. Auf diese Weise kann der Manager sofort eine Berechnung der Kosten der ausgewählten Services erhalten und die Kosten schätzen sowie die Entwickler für das Projekt ermitteln.
Wir planen, das Portal in eine Cloud-Lösung für den Betrieb von 1C-Systemen zu integrieren. Dies wird dazu beitragen, replizierte Standardlösungen in Verbindung mit am Stand implementierten Entwicklungsservices für eine effizientere Migration von Kundensystemen in die CROC-Cloud schnell bereitzustellen.
Wir planen auch die Integration des Verwaltungsportals in den automatisierten Konfigurationsverwaltungsdienst (Bereitstellung, Konfiguration, Löschung). Dies verkürzt die Bereitstellungszeit und vereinfacht die Einrichtung und Wartung des Systems. Um das Sicherheitsniveau zu erhöhen, werden wir einen Pass-Through-Authentifizierungsdienst für alle Dienste des Standes einführen, um in allen das gleiche Konto zu verwenden.
Wenn wir den gesamten Prozess unter dem Gesichtspunkt des Verlaufs des gesamten Zyklus der Lösungsentwicklung betrachten, können wir mit der erstellten Pipeline eine große Anzahl verschiedener Metriken sowohl nach Projektartefakten als auch nach daran beteiligten Spezialisten erfassen und aggregieren. Eine solch detaillierte Retrospektive wird dazu beitragen, Erfahrungen bei der Lösung komplexer Probleme zu sammeln und wiederzuverwenden, um Teams erfolgreicher Entwickler für eine effizientere und koordiniertere Arbeit zu bilden.UPD Fügen Sie auf Anfrage der Kommentare eine Liste der von uns verwendeten Open Source-Produkte mit Links hinzu.