{}const=>[]async()letfn</>var
Entwicklung1C

CI/CD für 1C: So stoppen Sie das manuelle Aktualisieren von Konfigurationen und automatisieren Releases

In diesem Artikel erfahren Sie, wie Sie eine CI/CD-Pipeline von Grund auf neu erstellen, auch wenn Sie noch nie mit Git und Automatisierung gearbeitet haben. Sie erfahren, welche Tools Sie verwenden sollten, wie Sie automatische Tests und Bereitstellungen einrichten und wie Sie häufige Fehler vermeiden können. Sind Sie bereit, auf die nächste Entwicklungsstufe zu gelangen?

К

Kodik

Autor

11 Min. Lesezeit

Einführung: Warum benötigt 1C CI/CD?

Wenn Sie mit der 1C-Plattform arbeiten, sind Sie wahrscheinlich auf eine Situation gestoßen, in der nach einem weiteren Update etwas in der Kampfdatenbank kaputt geht und die Änderungen nicht schnell rückgängig gemacht werden können. Oder wenn ein Entwicklungsteam an einer Konfiguration arbeitet und der Code eines Programmierers die Änderungen eines anderen überschreibt. Kommt Ihnen das bekannt vor?

CI/CD (Continuous Integration / Continuous Delivery) wurde speziell zur Lösung solcher Probleme entwickelt. Dabei handelt es sich um eine Reihe von Praktiken, die den Prozess der Softwareentwicklung, -prüfung und -bereitstellung automatisieren. Obwohl diese Ansätze in der Webentwicklung längst zum Standard geworden sind, gewinnen sie in der 1C-Welt erst jetzt an Popularität. Und das ist verständlich: Das 1C-Ökosystem ist spezifisch, arbeitet mit eigenen Konfigurationsformaten und erfordert einen besonderen Ansatz bei der Versionskontrolle.

In diesem Artikel werden wir uns ansehen, wie man eine einfache, aber effektive CI/CD-Pipeline für 1C erstellt, die Routinevorgänge automatisiert und Ihre Arbeit vorhersehbarer und sicherer macht.

🔥 100.000+ Schüler sind bereits bei uns

Genug Theorie gelesen?
Zeit zu coden!

Kodik — eine App, in der du durch Praxis programmieren lernst. KI-Mentor, interaktive Lektionen, echte Projekte.

🤖 KI 24/7
🎓 Zertifikate
💰 Kostenlos
🚀 Jetzt starten
Heute beigetreten

Was ist CI/CD in einfachen Worten?

Continuous Integration (kontinuierliche Integration) bedeutet, dass alle Änderungen im Code regelmäßig in einem gemeinsamen Entwicklungszweig zusammengefasst werden und das System automatisch prüft, ob diese Änderungen etwas Wichtiges beschädigt haben. Stellen Sie sich vor, dass der Roboter jedes Mal, wenn Sie Konfigurationsänderungen speichern, automatisch die Syntax überprüft, Tests ausführt und Sie benachrichtigt, wenn etwas schief gelaufen ist.

Continuous Delivery (kontinuierliche Bereitstellung) ist der nächste Schritt, wenn Ihr Code automatisch für die Bereitstellung auf einem Test- oder Produktionsserver vorbereitet wird. Anstatt die Konfiguration manuell zu exportieren, Dateien zu kopieren und Datenbanken zu aktualisieren, erfolgt der gesamte Prozess automatisch auf Knopfdruck oder sogar ohne Ihr Zutun.

Zu berücksichtigende Besonderheiten von 1C

Die 1C-Plattform verfügt über eine Reihe von Funktionen, die die Implementierung von CI/CD etwas komplizierter machen als bei der herkömmlichen Webentwicklung. Erstens werden 1C-Konfigurationen in Binärdateien (.cf) gespeichert, deren Versionierung mit herkömmlichen Git-Tools schwierig ist. Zweitens erfordert die Arbeit mit 1C eine installierte Plattform, was die Einrichtung automatisierter Umgebungen erschwert. Drittens hat 1C seine eigenen Besonderheiten mit Objektsperren, Monopolmodus und Datenbankaktualisierungsfunktionen.

All diese Schwierigkeiten sind jedoch lösbar. Es gibt ein Format zum Hochladen von Konfigurationen in XML, das perfekt für Git geeignet ist. Die 1C-Plattform kann im Thin-Client-Modus oder sogar ohne GUI ausgeführt werden, wodurch sie in automatisierten Szenarien verwendet werden kann. Und für die Lösung spezifischer Probleme wurden mehrere Open-Source-Tools für 1C entwickelt, auf die wir später noch näher eingehen werden.

Automatisierungstools

Um eine CI/CD-Pipeline für 1C zu erstellen, benötigen Sie mehrere Tools. Beginnen wir mit dem Versionskontrollsystem – hier ist die Wahl offensichtlich: Git. Dies ist der Industriestandard und eignet sich ideal für die Arbeit mit 1C, wenn das Speicherformat der Konfigurationen richtig eingestellt ist.

Das wichtigste Tool ist OneScript, ein 1C-Sprachinterpreter, der außerhalb der 1C-Plattform funktioniert. Es ermöglicht das Schreiben von Skripten in einer vertrauten Sprache und das Ausführen verschiedener Operationen mit Konfigurationen. Auf Basis von OneScript wurden nützliche Tools wie vanessa-automation für automatisierte Tests und gitsync für die Synchronisierung mit Git entwickelt.

Für den CI/CD-Server können beliebte Lösungen verwendet werden: GitLab CI, Jenkins, GitHub Actions oder sogar TeamCity. Die Wahl hängt von Ihren Präferenzen und der Infrastruktur Ihres Unternehmens ab. Für Anfänger empfehle ich GitLab CI oder GitHub Actions, da sie kostenlose Hosting-Lösungen bieten und einfach über YAML-Dateien konfiguriert werden können.

Sie benötigen auch ein Tool, um mit Konfigurationen über die Befehlszeile zu arbeiten. Hier können Sie die Standardfunktionen der 1C-Plattform (Konfigurator im /C-Modus) oder spezielle Dienstprogramme wie v8unpack zum Entpacken von Konfigurationen in XML verwenden.

Einrichten der grundlegenden Projektstruktur

Der erste Schritt zur Automatisierung ist die richtige Organisation des Projekts. Anstatt .cf-Binärdateien in Git zu speichern, müssen Sie die Konfiguration im XML-Format hochladen. Erstellen Sie dazu im Stammverzeichnis Ihres Projekts einen Ordner src, in den der Quellcode der Konfiguration als separate XML-Dateien für jedes Metadatenobjekt hochgeladen wird.

Die Struktur eines typischen 1C-Projekts in Git könnte wie folgt aussehen: Der Stammordner enthält das Verzeichnis src mit der hochgeladenen Konfiguration, den Ordner tests mit automatischen Tests, den Ordner scripts mit Dienstskripten zum Erstellen und Bereitstellen sowie Konfigurationsdateien für das CI/CD-System, z. B. .gitlab-ci.yml oder .github/workflows/main.yml.

Es ist wichtig, Dateien, die nicht versioniert werden müssen, zu .gitignore hinzuzufügen: temporäre 1C-Dateien mit der Erweiterung .tmp, .1CV8-Sperrdateien, Ordner mit Cache und Protokollen. Es ist auch nicht ratsam, die Informationsdatenbanken selbst im Repository zu speichern - nur den Quellcode der Konfigurationen.

Erstellen der ersten Pipeline

Erstellen wir eine einfache CI/CD-Pipeline, die bei jedem Commit grundlegende Überprüfungen durchführt. Als Beispiel verwenden wir GitLab CI, aber die Logik gilt auch für andere Systeme.

Erstellen Sie eine .gitlab-ci.yml-Datei im Stammverzeichnis des Projekts und definieren Sie mehrere Schritte: Syntaxprüfung, Konfigurationserstellung, Testausführung und Bereitstellung. In der ersten Phase prüft die Pipeline die Konfigurationssyntax. Dies ist ein schneller Vorgang, mit dem Sie offensichtliche Fehler wie offene Klammern oder falsche Variablennamen erkennen können.

Sie können den 1C-Konfigurator im Befehlszeilenmodus verwenden, um die Syntax zu überprüfen. Erstellen Sie ein Skript, das die Konfiguration aus XML-Dateien in eine leere Informationsdatenbank lädt und eine Konfigurationsprüfung ausführt. Wenn der Konfigurator Fehler findet, sollte das Skript mit einem Rückgabecode ungleich Null enden und die Pipeline stoppen.

Der zweite Schritt ist die Konfigurationserstellung. Hier wird aus XML-Dateien eine vollständige cf-Datei zusammengestellt, die für die Bereitstellung verwendet werden kann. Diese Datei wird als Pipeline-Artefakt gespeichert und kann in den nächsten Schritten verwendet oder manuell heruntergeladen werden.

Der dritte Schritt ist der Start automatischer Tests. Wenn Sie ein Test-Framework wie Vanessa-Automation oder ADD verwenden, werden alle geschriebenen Tests hier ausgeführt. Die Tests werden auf einer temporären Informationsdatenbank durchgeführt, die speziell für diese Phase erstellt und nach Abschluss gelöscht wird.

Die letzte Phase ist die Bereitstellung. Diese Phase kann nur für bestimmte Zweige (z. B. Master oder Release) ausgeführt werden und aktualisiert die Test- oder Produktionsdatenbank. Es ist wichtig, diesen Schritt so zu implementieren, dass bei Problemen schnell auf die vorherige Version zurückgegangen werden kann.

Testautomatisierung

Einer der Hauptwerte von CI/CD ist das automatische Testen. Für 1C gibt es mehrere Frameworks, mit denen Sie automatische Tests schreiben können. Das beliebteste ist Vanessa-Automation, das den BDD-Stil (Behavior Driven Development) des Schreibens von Tests unterstützt.

BDD-Tests werden in natürlicher Sprache im Gherkin-Format geschrieben: gegeben (Given), wenn (When), dann (Then). Zum Beispiel könnte der Test so aussehen: Wenn ich das Formular zum Erstellen eines Dokuments geöffnet habe, wenn ich das Feld "Gegenpartei" mit dem Wert "OOO Roga i Kopita" ausgefüllt habe und auf die Schaltfläche "Speichern" geklickt habe, sollte das Dokument ohne Fehler gespeichert werden. Diese Szenarien sind nicht nur für Programmierer, sondern auch für Analysten oder Tester verständlich.

Jedes dieser Szenarien ist mit der Implementierung in der eingebetteten 1C-Sprache verbunden, die Aktionen ausführt und die Ergebnisse überprüft. Es ist wichtig, kritische Geschäftsprozesse mit Tests abzudecken: Dokumentenverwaltung, Registerberechnung, Berichterstellung. Schon eine kleine Anzahl solcher Tests erhöht die Stabilität der Entwicklung erheblich.

Verzweigungs- und Freigabestrategien

Für einen effektiven CI/CD-Betrieb benötigen Sie die richtige Verzweigungsstrategie in Git. Für Teams, die mit 1C arbeiten, eignet sich der vereinfachte Git Flow gut: Der Hauptzweig master (oder main) enthält stabilen Code, der für die Bereitstellung in der Produktion bereit ist, der Zweig develop wird verwendet, um neue Funktionen zu integrieren, und für jede Aufgabe werden separate Feature-Zweige erstellt.

Wenn ein Entwickler mit der Arbeit an einer neuen Aufgabe beginnt, erstellt er einen Zweig von develop mit einem klaren Namen wie feature/add-inventory-report. Nach Abschluss der Arbeit wird eine Merge Request (oder Pull Request) erstellt, die automatisch die CI-Pipeline startet. Wenn alle Prüfungen erfolgreich waren und die Code-Review abgeschlossen ist, wird der Zweig in develop zusammengeführt.

Um eine Version aus develop zu erstellen, wird ein release -Zweig erstellt, auf dem die endgültigen Überprüfungen und Fehlerkorrekturen durchgeführt werden. Nach erfolgreichen Tests wird der Release-Branch mit dem Master zusammengeführt, mit einem Versionsnummer-Tag versehen und die Bereitstellung auf dem Produktionssystem wird automatisch gestartet.

Bereitstellung und Rollback von Änderungen

Der Prozess der Bereitstellung der 1C-Konfiguration hat seine eigenen Nuancen. Man kann Dateien nicht einfach ersetzen - man muss die Informationsdatenbank korrekt aktualisieren, Änderungen in der Datenstruktur verarbeiten und die Kompatibilität überprüfen. Um diesen Prozess zu automatisieren, werden Skripte verwendet, die die Datenbank über eine COM-Verbindung oder im /C-Modus aktualisieren.

Es ist von entscheidender Bedeutung, vor dem Aktualisieren eine Sicherungskopie der Datenbank zu erstellen. Im Bereitstellungsskript sollte der erste Schritt darin bestehen, ein Backup zu erstellen, das mit einem Zeitstempel und einer Versionsnummer gespeichert wird. Wenn nach dem Update etwas schief gelaufen ist, können Sie mit diesem Backup schnell auf die vorherige Version zurücksetzen.

Nach dem Aktualisieren der Konfiguration wird empfohlen, Smoke-Tests auszuführen - eine kleine Reihe von Tests, mit denen die Leistung der Hauptfunktionen des Systems schnell überprüft wird. Sie können beispielsweise versuchen, das Hauptformular zu öffnen, ein einfaches Dokument zu erstellen und eine Standardberechnung durchzuführen. Wenn die Smoke-Tests fehlschlagen, sollte die Bereitstellung als fehlgeschlagen betrachtet und ein automatischer Rollback durchgeführt werden.

Überwachung und Benachrichtigungen

Ein wichtiger Bestandteil jeder CI/CD-Pipeline ist das Benachrichtigungssystem. Entwickler sollten sofort wissen, ob ihr Commit den Build beschädigt hat oder die Tests nicht bestanden hat. Die meisten CI/CD-Systeme sind in Messenger wie Telegram, Slack oder Unternehmenssysteme integriert.

Konfigurieren Sie Benachrichtigungen so, dass sie informativ sind, aber nicht gespamt werden. Beispielsweise können Sie Nachrichten nur senden, wenn Tests fehlschlagen oder die Produktion erfolgreich bereitgestellt wird. Die Benachrichtigung sollte grundlegende Informationen enthalten: welcher Zweig, wer der Autor des Commits ist, welche Pipeline-Phase ausgefallen ist, ein Link zu detaillierten Protokollen.

Es ist auch hilfreich, Metriken zu sammeln: wie lange es dauert, die Pipeline vollständig auszuführen, wie oft Tests fehlschlagen, wie lange es vom Commit bis zur Bereitstellung in der Produktion dauert. Diese Daten helfen, Engpässe zu identifizieren und Entwicklungsprozesse zu verbessern.

Praktische Tipps für Anfänger

Fangen Sie klein an. Versuchen Sie nicht, sofort ein perfektes CI/CD mit allen möglichen Überprüfungen zu erstellen. Beginnen Sie mit der grundlegenden Syntaxprüfung und der automatischen Konfigurationserstellung. Wenn es stabil läuft, fügen Sie einige einfache Tests hinzu. Automatisieren Sie dann die Bereitstellung auf einem Testserver. Und erst wenn die gesamte Kette ausgearbeitet ist, fahren Sie mit der automatischen Bereitstellung für die Produktion fort.

Dokumentieren Sie Prozesse. Erstellen Sie eine README-Datei im Stammverzeichnis des Projekts, in der Sie beschreiben, wie Ihr CI/CD funktioniert, welche Befehle für die lokale Entwicklung ausgeführt werden müssen und wie Releases erstellt werden. Dies ist besonders wichtig, wenn das Team mehrere Entwickler hat oder wenn das Projekt an ein anderes Team übergeben wird.

Ignorieren Sie keine fehlgeschlagenen Tests. Wenn die Pipeline rot anzeigt, sollte dies die oberste Priorität sein. Die „rote“ Pipeline normalisiert die Situation, wenn die Tests nicht bestanden werden, und im Laufe der Zeit hört das Team auf, darauf zu achten. Die Regel ist einfach: Wenn der Test fehlgeschlagen ist, müssen Sie entweder den Code oder den Test korrigieren, aber die Pipeline sollte wieder grün werden.

Nehmen Sie sich Zeit, um Ihr Team zu schulen. Die Einführung von CI/CD verändert Entwicklungsprozesse, und nicht alle Entwickler sind möglicherweise darauf vorbereitet. Halten Sie mehrere Besprechungen ab, in denen Sie erklären, warum dies erforderlich ist, wie es funktioniert, und Beispiele zeigen. Es ist besser, ein paar Stunden mit Schulungen zu verbringen, als monatelang mit Widerstand gegen Veränderungen zu kämpfen.

Typische Probleme und ihre Lösungen

Eines der häufigsten Probleme ist die langsame Pipeline. Die vollständige Erstellung und Prüfung der 1C-Konfiguration kann mehrere Minuten dauern. Verwenden Sie Caching, um den Prozess zu beschleunigen: Speichern Sie die erstellten Konfigurationen und Datenbanken zwischen den Pipeline-Ausführungen. Unterteilen Sie die Tests in schnelle Smoke-Tests, die immer ausgeführt werden, und einen vollständigen Testsatz, der nur für wichtige Zweige ausgeführt wird.

Ein weiteres Problem sind Konflikte beim Zusammenführen von XML-Konfigurationsdateien. Git löst Konflikte in XML nicht immer korrekt, insbesondere wenn zwei Entwickler dasselbe Metadatenobjekt geändert haben. Die Lösung besteht darin, spezielle Tools zum Zusammenführen von 1C-Konfigurationen zu verwenden, z. B. gitsync oder EDT (1C: Enterprise Development Tools), die die Metadatenstruktur verstehen.

Manchmal gibt es Probleme mit 1C-Lizenzen auf dem CI-Server. Für automatisierte Prozesse sind Lizenzen erforderlich, die eine Ausführung ohne GUI ermöglichen. Besprechen Sie mit Ihrem Lizenzmanager, welche Optionen für Ihre Konfiguration verfügbar sind. Alternativ können Sie die Demoversionen der Plattform zum Testen verwenden, obwohl dies seine Einschränkungen hat.

Befund

Der Aufbau von CI/CD für 1C ist kein schneller Prozess, aber die Zeitinvestition zahlt sich um ein Vielfaches aus. Die Automatisierung beseitigt Routine, reduziert Fehler und macht den Entwicklungsprozess vorhersehbarer und professioneller. Ihr Team kann häufiger und zuverlässiger Updates veröffentlichen, und die Qualität des Codes wird unweigerlich steigen.

Fangen Sie mit etwas Einfachem an: Richten Sie Git für die Speicherung von Konfigurationen ein, fügen Sie eine grundlegende Syntaxprüfung zu CI hinzu, schreiben Sie die ersten automatisierten Tests. Erweitern Sie die Funktionalität der Pipeline schrittweise, indem Sie neue Prüfungen hinzufügen und mehr Prozesse automatisieren. Und denken Sie daran: Das Hauptziel von CI/CD sind nicht komplexe Technologien, sondern die Verbesserung der Qualität der Entwicklung und des Lebens der Entwickler.

Möchten Sie mehr erfahren?

Auf der Bildungsplattform können Sie moderne Ansätze für die Entwicklung, Prozessautomatisierung, CI/CD und viele andere Technologien studieren Kodik. Wir erstellen praktische Kurse für Entwickler aller Niveaus — von Anfängern bis zu erfahrenen Fachkräften.

Und wir haben auch einen coolen Telegram-Kanal mit einer freundlichen Community, in der Sie technische Fragen diskutieren, Erfahrungen austauschen und Gleichgesinnte finden können. Machen Sie mit! 🚀

🎯Hör auf zu zögern

Artikel gefallen?
Zeit zum Üben!

Bei Kodik liest du nicht nur — du schreibst sofort Code. Theorie + Praxis = echte Skills.

Sofortige Praxis
🧠KI erklärt Code
🏆Zertifikat

Keine Registrierung • Keine Karte