Ignition 8 Deployment Best Practices

Ignition Projekte werden im Dateisystem gespeichert, so ist es möglich, Versionskontrollwerkzeuge zu verwenden, um Änderungen an Projekten zu verfolgen, wie z. B. Git.

Einführung

Dieser Leitfaden richtet sich an Ignition-Benutzer, die ein skalierbares, flexibles, unternehmenstaugliches System einrichten wollen. Einige Benutzer gehen von einer anderen Architektur oder einem anderen Modell aus und bewegen sich in diese Richtung, und einige Benutzer werden sich vielleicht nie dafür entscheiden, alle Empfehlungen anzuwenden. Diese Richtlinien sind nicht als Alles-oder-Nichts-Vorschlag gedacht, und viele Installationen könnten von der Anwendung auch nur einer Teilmenge der hier enthaltenen Empfehlungen profitieren.

Inductive Automation empfiehlt für jedes unternehmensgerechte System dringend die Anwendung aller in diesem Dokument behandelten Techniken.

Der Workflow

Bereitstellungen sollten als Teil eines Entwicklungsworkflows behandelt werden, nicht als nachträglicher Einfall. Ihr Workflow umfasst normalerweise mindestens drei Umgebungen: Entwicklung, Test und Produktion. In diesem Fall könnte der Arbeitsablauf wie folgt aussehen:

Die Entwickler arbeiten an Bugs und Funktionen in einer Entwicklungsumgebung.
Sobald die Funktionen implementiert sind, werden sie mit dem Test-Branch zusammengeführt (Merged) und in der Testumgebung zur Qualitätssicherung und zum Testen bereitgestellt.
Nach Abschluss der Tests wird der Entwicklungs-Branch mit dem Produktions-Branch zusammengeführt und dann in der Produktionsumgebung bereitgestellt.

Bevor wir uns die einzelnen Umgebungen genauer ansehen, ist es wichtig, die Konfiguration von Ignition genauer zu betrachten, um die Bereitstellung besser zu verstehen.

Die Konfiguration von Ignition

Ignition ist eine serverbasierte Software und wird auf einem zentralen Server installiert. Das bedeutet, dass die gesamte Konfiguration von Ignition auf dem Server gespeichert ist. Installation, Lizenzierung, Konfiguration, Sicherung und Verwaltung erfolgen an einem Ort. Client-Anwendungen werden vom Ignition-Server heruntergeladen (Vision) oder sind natives HTML (Perspective) und werden daher automatisch aktualisiert, sobald neue Änderungen bereitgestellt werden. Auf diese Weise müssen wir uns nicht um die Installation, Lizenzierung oder Bereitstellung von Änderungen für einzelne Clients kümmern, insbesondere wenn wir Hunderte von Clients haben. Bei unserem Bereitstellungsmodell können wir uns ausschließlich auf den Server konzentrieren.

Wenn Sie in Ignition entwickeln, gibt es 4 Hauptbereiche für die Konfiguration:

Gataway-Konfiguration
Tags
Bilder
Projekte

Jeder dieser Bereiche wird auf dem Server anders gespeichert. Die Gateway-Sicherung enthält die Konfiguration für alle diese Bereiche, aber einige können auch einzeln behandelt werden. Es ist wichtig, die Unterschiede zu verstehen und zu wissen, wie wir bei der Implementierung von Änderungen mit ihnen umgehen.

Gateway-Konfiguration

Der Bereich Gateway-Konfiguration umfasst alle Einstellungen, Profile und Verbindungen, die Sie im Abschnitt Konfiguration auf der Gateway-Webseite bearbeiten. Hier werden die meisten Einstellungen vorgenommen, die das gesamte Gateway betreffen. Sie können Datenbank- und Geräteverbindungen, Benutzer und Rollen hinzufügen, die Alarmeinstellungen anpassen, Sicherheitseinstellungen vornehmen, einen Zeitplan für die automatische Durchführung von Backups erstellen und vieles mehr. Die Liste der Konfigurationsoptionen im linken Menü ändert sich je nachdem, welche Module auf Ihrem Gateway installiert sind.

Alle diese Einstellungen werden in der internen SQLite-Datenbank von Ignition gespeichert. Sie sind nur über die Benutzeroberfläche des Gateways zugänglich. Abgesehen von einer vollständigen Gateway-Sicherung können Sie diese Einstellungen nicht von Gateway zu Gateway exportieren oder importieren. Das EAM-Modul von Ignition unterstützt derzeit auch nicht das Verschieben dieser Einstellungen von Gateway zu Gateway. Dies macht die Arbeit bei der Entwicklung unserer Bereitstellungsstrategie schwierig, da alle Änderungen manuell vorgenommen werden müssen. Außerdem ist es schwierig, Änderungen zu verfolgen, da sich alles in einer SQLite-Datenbank befindet.

Gateway-Backups werden bei der Migration von Änderungen normalerweise nicht verwendet, da es sich um ein Alles-oder-Nichts-Verfahren handelt. Unterschiedliche Umgebungen haben oft separate Gateway-Konfigurationseinstellungen für Elemente wie Geräte, Datenbanken und Authentifizierung.

Wir empfehlen, einen Prozess einzuführen, den alle Entwickler befolgen, um Änderungen an diesen Einstellungen außerhalb von Ignition zu verfolgen und die Unterschiede in diesen Einstellungen innerhalb jeder Umgebung (Entwicklung, Test und Produktion) zu dokumentieren.

Bilder

Bilder wie PNGs, JPGs, GIFs und SVGs können in das Bildverwaltungstool hochgeladen und innerhalb von Vision oder Perspective verwendet werden. Das Bildverwaltungs-Tool, das über Werkzeuge > Bildverwaltung im Ignition Designer verfügbar ist, bietet eine Schnittstelle zum Hochladen, Herunterladen oder Auswählen von Bildern.

Diese Bilder werden in der internen SQLite-Datenbank von Ignition gespeichert und sind nicht Teil eines Ignition-Projekts. Vielmehr verweisen Projekte auf die Bilder.

Bilder können nicht über das EAM-Modul von Ignition von Gateway zu Gateway verschoben werden. Der Prozess ist manuell und erfordert die Verwendung des Bildverwaltungswerkzeugs im Ignition Designer. Es müssen auch weitere Schritte unternommen werden, um Änderungen an Bildern zu verfolgen.

Wir empfehlen, Bilder kontinuierlich in einen Ordner zu exportieren und den Ordner in eine Source-Control-Repository zu übertragen, um Änderungen zu verfolgen. Dieser Prozess kann nicht automatisch durchgeführt werden und erfordert einen manuellen Eingriff. Sie müssen Bilder über den Ignition Designer exportieren/importieren, wenn Sie Änderungen von der Entwicklung über die Tests bis zur Produktion bereitstellen.

Projekte

Projekte sind die Haupteinheit der Konfiguration in Ignition. Projekte enthalten alle entworfenen Elemente, die die eigentliche Arbeit leisten. Ihre Projekte können sowohl interaktive Elemente (wie Steuerelemente, Diagramme, Berichte, Eingabeformulare usw.) als auch dauerhafte Elemente (wie historische Logger, automatische Berichte usw.) enthalten.

In Ignition ist ein Projekt eine Konfigurationseinheit, die Folgendes enthält:

Vision Windows & Templates und Perspective Views: Bildschirme, mit denen Benutzer interagieren
Transaction Groups: Eine bidirektionale Verbindung zwischen Datenbanken und PLCs
Reports: PDF-Berichte zur Anzeige und Aufzeichnung von Daten
Skripte: Timer- und ereignisbasierte Skripte, die im gesamten System verwendet werden
Alarm-Notification-Pipelines: Pipelines, die Benutzer über Alarmzustände benachrichtigen
Allgemeine Einstellungen und Eigenschaften: Die Einstellungen, die den Zugriff, die Ressourcenverbindungen, das Layout, das Timing und vieles mehr steuern.
Und vieles mehr

Sie verwenden den Ignition Designer, um Projekte zu konfigurieren und zu erstellen. Die Projekte werden dann in der Runtime (Vision Clients oder Perspective Sessions) angezeigt. Sie können so viele Projekte erstellen, wie Sie möchten, und die Benutzer können problemlos zwischen Projekten wechseln oder mehrere Projekte gleichzeitig öffnen.

Projekte werden im Dateisystem als eine Reihe von Ordnern und Dateien gespeichert. Einige Dateien sind binär, während andere als reine Textdateien gespeichert sind. Die Projekte werden im Datenverzeichnis auf dem Ignition-Server gespeichert.

Linux

/var/lib/ignition/data/projects

Windows

C:\Program Files\Inductive Automation\Ignition\data\projects

Da Projekte im Dateisystem gespeichert werden, ist es möglich, Versionskontrollwerkzeuge außerhalb von Ignition zu verwenden, um Änderungen an Projekten zu verfolgen, wie z. B. Git. Änderungen im Ignition Designer werden im Dateisystem aktualisiert. Ignition überwacht auch das Dateisystem kontinuierlich auf Änderungen und liest die Änderungen automatisch ein.

Projekte können auch über eine Datei (.zip-Erweiterung) importiert und exportiert werden und mit EAM von Gateway zu Gateway verschoben werden.

Wir empfehlen die Verwendung eines externen Versionskontrollwerkzeugs, um Projektänderungen zu verfolgen, z. B. Git. Sie können den Projektordner in ein Repository verwandeln und Tools verwenden, um Änderungen von der Entwicklungs- über die Test- bis hin zur Produktionsumgebung außerhalb von Ignition bereitzustellen.

Change Track Summary

	Gateway Konfiguration	Tags	Images	Projekte
Änderungsverfolgung	Manuelle Dokumentation und Gateway Backup, dann zu Versionskontrolle commiten.	Tag Export, dann zu Versionskontrolle commiten.	Image Export, dann zu Versionskontrolle commiten.	Es ist kein export nötig. Änderungen im Projektverzeichnis können automatisch zu Versionskontrolle commited werden.
Backups	Gateway Backup	Gateway Backup	Gateway Backup	Gateway Backup

Bereitstellungsumgebungen

Nachdem wir nun eine gute Vorstellung davon haben, wie die Konfiguration von Ignition gespeichert wird und funktioniert, wollen wir uns die einzelnen Umgebungen genauer ansehen, um herauszufinden, welche die effizientesten Methoden für die Bereitstellung in jeder einzelnen Umgebung sind. In der nachstehenden Referenzarchitektur sehen Sie alle 3 separaten Ignition-Umgebungen (Entwicklung, Test und Produktion) zusammen mit dem EAM-Modul von Ignition und einem Versionskontrollsystem wie GitLab.

Umgebungen

Entwicklung

Die Entwicklungsumgebung (dev) ist die Umgebung, in der die aktive Entwicklung von Ignition stattfindet. Diese Umgebung ist die erste Stufe des Arbeitsablaufs. Hier arbeiten die Entwickler an Bugs und neuen Funktionen, bevor sie diese in der Produktionsumgebung einführen. Es ist sehr praktisch, einen separaten Projektzweig (Branch) in Ihrem Versionskontrollsystem mit dem Namen Entwicklung oder Development zu haben, um Ihre Entwicklungsumgebung zu repräsentieren.

Es gibt 2 Hauptrichtungen, wie man die Entwicklungsumgebung angehen kann: die Verwendung einer gemeinsamen Entwicklungsumgebung oder die Verwendung einzelner Workstations als eigene Entwicklungsumgebung. Bei einer gemeinsamen Entwicklungsumgebung haben Sie einen zentralen Ignition-Server, der der Entwicklung gewidmet ist und auf dem alle Entwickler arbeiten. Bei einer individuellen Entwicklungsumgebung hat jeder Entwickler Ignition auf seiner Arbeitsstation mit seinem eigenen Branch installiert. Jeder Ansatz hat seine Vor- und Nachteile. Ignition unterstützt die gleichzeitige Entwicklung und die meisten Kunden entscheiden sich für eine gemeinsame Entwicklungsumgebung, so dass auf den Arbeitsplätzen der einzelnen Entwickler nichts installiert werden muss. Sie können den Designer einfach vom Entwicklungsserver aus starten. Bei einer individuellen Entwicklungsumgebung muss der Ignition-Gateway auf jeder Arbeitsstation des Entwicklers separat konfiguriert werden. Unabhängig vom Ansatz müssen Änderungen in die Repository der Versionskontrolle übertragen und über den Workflow bereitgestellt werden.

Dies wirft natürlich einige Fragen auf, die geklärt werden müssen.

Müssen die Entwicklungs- und Testumgebungen lizenziert werden?
Nein. Sie können einfach die Testlizenz von Ignition für die Entwicklungs- und Testumgebungen verwenden. Einige Kunden entscheiden sich für den Kauf von Lizenzen für diese Umgebungen, um nicht alle 2 Stunden einen Reset durchführen zu müssen. Die Entscheidung liegt ganz bei Ihnen.

Was sind die Unterschiede in der Konfiguration von Ignition für die einzelnen Umgebungen?
Es ist äußerst wichtig, die Unterschiede zwischen Ignition und den einzelnen Umgebungen zu verstehen. Sie können nicht exakt identisch sein. Die Produktionsumgebung kommuniziert mit Live-Datenquellen wie Geräten, SQL-Datenbanken und mehr. Möglicherweise möchten Sie nicht, dass Ihre Entwicklungs- und Testumgebung mit denselben Live-Datenquellen verbunden sind. Möglicherweise haben Sie auch unterschiedliche Authentifizierungsquellen oder Berechtigungsmodelle für die Entwicklungs- und die Testumgebung. Hier ist eine kleine Liste der häufigsten Unterschiede:

Geräte oder SPS-Verbindungen: Verwendung der nativen Treiber von Ignition
OPC UA-Verbindungen: Direkte Verbindung zu Drittanbietern wie Kepware oder einer SPS
Datenbank-Verbindungen: Verbindung zu einer SQL-Datenbank wie MySQL oder MS SQL
Authentifizierungs-Profile: Unterschiedliche Authentifizierungsquellen oder insbesondere ein anderes Admin- oder Root-Passwort. Manchmal möchten Sie den Zugriff auf den Designer und das Gateway in der Produktionsumgebung sperren.
Profile für Alarmbenachrichtigungen: Verbindungen zu E-Mail, SMS oder Sprache
Redundanz-Einstellungen: Oftmals haben Sie Redundanz in der Produktionsumgebung und nicht in der Entwicklungs- oder Testumgebung.

Wir empfehlen, in beiden Umgebungen dieselben Verbindungen zu verwenden, jedoch mit unterschiedlichen IP-Adressen oder Einstellungen hinter den Kulissen. Auf diese Weise funktionieren alle Ressourcen, die auf die Kenntnis des Namens angewiesen sind, auch in den anderen Umgebungen. Sie können zum Beispiel für jede Umgebung eine eigene SQL-Datenbank haben. Alle 3 Ignition Gateways haben dieselbe Datenbankverbindung, verweisen aber auf ihre eigene SQL-Datenbank, die lokal oder remote sein kann. Screens oder „named Queries“, die diese Verbindung verwenden, funktionieren in allen Umgebungen, da sie die Verbindung namentlich referenzieren.

Dokumentieren Sie diese Unterschiede, um sicherzustellen, dass Sie keine Änderungen in der Produktion einführen, die auf ein Entwicklungs- oder Testsystem verweisen.

Wie simuliere ich echte Gerätedaten bei Entwicklung und Tests?
Dies ist eine sehr häufig gestellte Frage, da man in allen Umgebungen Zugang zu echten Daten haben möchte. Manchmal gibt es Einschränkungen oder Leistungsprobleme, die berücksichtigt werden müssen. Beispielsweise unterstützen einige SPS nicht mehr als eine Verbindung oder würden bei mehreren Ignition-Servern, die dieselben Tags mehrmals abfragen, überlastet werden. Es gibt mehrere Möglichkeiten, um Zugang zu echten Daten zu erhalten:

OPC UA: Sie können Ihre Entwicklungs- und Testumgebung über OPC UA mit Ihrer Produktionsumgebung verbinden. Die Entwicklungsumgebung würde denselben OPC-Servernamen haben, aber sie würde auf die Produktionsumgebung verweisen, anstatt auf sich selbst. Seien Sie vorsichtig, denn es ist möglich, dass sich Entwicklung und Tests auf die Produktion auswirken, insbesondere beim Schreiben auf Tags.
MQTT: Dies ist die empfohlene Methode, um Live-Daten an alle Umgebungen zu übermitteln. Sie können Ihre Produktionsumgebung alle Tag-Daten an einen zentralen MQTT-Server veröffentlichen lassen, indem Sie das MQTT-Übertragungsmodul von Ignition verwenden. Alle 3 Umgebungen können sich mit dem MQTT-Engine-Modul von Ignition anmelden und die Tags werden automatisch erkannt. Jede Umgebung kann sich anmelden, ohne die andere zu beeinflussen. Seien Sie auch hier vorsichtig, wenn Sie potenziell auf aktive PLCs schreiben. MQTT-Server haben ACLs (Zugriffskontrolllisten), die Sie definieren können, um die Entwicklungs- und Testumgebungen bei Bedarf schreibgeschützt zu machen.
Gateway-Netzwerk: Sie können Ihre Entwicklungs- und Testumgebungen über das Gateway-Netzwerk von Ignition mit Ihrer Produktionsumgebung verbinden und Remote-Tag-Providers einrichten. Die Entwicklungsumgebung würde denselben Tag-Provider-Namen haben, aber sie würde auf die Produktionsumgebung verweisen, anstatt lokal zu sein. Seien Sie auch hier vorsichtig, wenn Sie potenziell auf aktive SPSen schreiben. Das Gateway-Netzwerk von Ignition verfügt über Sicherheitsfunktionen auf Dienstebene, mit denen die Entwicklungs- und Testumgebungen bei Bedarf schreibgeschützt werden können. Diese Methode wird im Allgemeinen nicht empfohlen.
Geräte-Simulation:
- Programmierbarer Gerätesimulator: Dies ist vielleicht die beste Option, wenn Sie keine Live-SPS-Daten benötigen. Stattdessen können wir den programmierbaren Gerätesimulator von Ignition verwenden, um SPS-Daten zu simulieren. Mit dem Simulator können Sie jeden gewünschten Tag-Pfad sowie statische oder dynamische Werte definieren. Ihre Entwicklungs- und Testumgebungen verwenden den Simulator, während die Produktionsumgebung die echte SPS verwendet. Solange Sie den Namen des Geräts beibehalten, sind die Tags in allen Systemen identisch. Weitere Einzelheiten zum Simulator finden Sie in der Dokumentation: https://docs.inductiveautomation.com/display/DOC80/Programmable+Device+Simulator
- SFCs: Wenn Sie eine erweiterte Bausteinsimulation benötigen, bieten SFCs eine große Flexibilität. Der Programmable Device Simulator bietet konfigurierbare Signale, aber die Signale ändern sich nicht in Abhängigkeit von den Aktionen des Benutzers. SFCs, gepaart mit Memory-Tags, bieten eine großartige Möglichkeit, grundlegende SPS-Funktionen wie HOAs und Ventilzustände, Durchflüsse und mehr zu simulieren.
- SPS-Software-Simulator: Viele SPS-Hersteller bieten einen Soft-SPS/Emulator an, der ein echtes SPS-Programm ausführen kann. Wenn Ignition über OPC mit der Software verbunden werden kann, kann dies eine gute Option sein, um das echte SPS-Programm mit allen Tags in einem System laufen zu lassen, das völlig von der realen Anlage getrennt ist.
Zusätzliche PLCs: Wenn Sie ein System mit einer kleinen Anzahl von SPSen haben, kann es manchmal sinnvoll sein, getrennte physische SPSen für die Entwicklungs- und Test-Umgebungen zu haben, insbesondere wenn SPS-Programmierungsänderungen zur gleichen Zeit wie Ignition-Projektänderungen eingeführt werden können.

Was ist mit benutzerdefinierten SQL-Tabellen, die in jeder Umgebung synchronisiert werden sollen?
Wie wir bereits besprochen haben, hat jede Umgebung normalerweise ihre eigene SQL-Datenbank. Sie möchten nicht, dass die Entwicklungs- und Testumgebung mit der gleichen Datenbank wie die Produktionsumgebung arbeitet. Im Allgemeinen ist dies kein Problem für die in Ignition integrierten Verlaufs-, Alarm-, Prüfungs- und Transaktionsgruppen. Wenn Sie jedoch Ihre eigenen benutzerdefinierten Tabellen erstellen und Ignition mit diesen Tabellen verbinden, müssen wir darüber nachdenken, wie wir sicherstellen können, dass diese Tabellen (Struktur) und mögliche Daten in allen Umgebungen vorhanden sind. In der Regel wird dies von den Entwicklern manuell erledigt, indem sie in allen Umgebungen die gleichen DDL-Anweisungen (CREATE TABLE usw.) ausführen. In einigen Fällen gibt es Tools oder Replikationstechniken, die vom Datenbanksystem verwendet werden können, um diesen Prozess zu automatisieren. Sie müssen einen Plan ausarbeiten, um sicherzustellen, dass alle 3 Umgebungen dieselbe Struktur und möglicherweise dieselben Daten wie z. B. Lookup-Tabellen haben.

Testen

Sobald die Funktionen implementiert sind und als einigermaßen stabil angesehen werden, werden sie in den Testbranch zusammengeführt (gemerged) und dann in der Testumgebung bereitgestellt. Jetzt kommt die Qualitätssicherung ins Spiel: Die Tester gehen zu den Testservern und überprüfen, ob das Projekt wie vorgesehen funktioniert.

Es ist sehr praktisch, einen separaten Branch in Ihrem Versionsverwaltungssystem mit dem Namen Testing zu haben, um Ihre Testumgebung zu repräsentieren. Damit können die Entwickler mehrere Branches gleichzeitig auf demselben Server bereitstellen, indem sie einfach alles, was bereitgestellt werden muss, in den Testbranch zusammenführen. Außerdem hilft es den Testern zu verstehen, was genau sich im Moment auf den Testservern befindet, indem sie einfach einen Blick in den Testbranch werfen.

Produktion

Sobald die Funktion implementiert und getestet ist, kann sie in die Produktion überführt werden. Die Produktionsumgebung wird auch als Live-Umgebung bezeichnet, insbesondere bei Servern, da dies die Umgebung ist, mit der die Benutzer direkt interagieren.

Wir empfehlen, größere Versionen immer zu einem geplanten Zeitpunkt in die Produktion zu überführen, der dem gesamten Team bekannt ist.

Modul zur Unternehmensverwaltung

Das EAM-Modul bietet eine sichere und intuitive Möglichkeit, viele Ignition-Installationen von einem Standort aus zu verwalten. Es ist ideal für große Unternehmen, die mehrere Gateways über große geografische Entfernungen hinweg einsetzen, aber auch Unternehmen mit einigen Ignition Gateways in einer einzelnen Fabriketage können von seinen Möglichkeiten profitieren, die Leistung zu überwachen und die Sicherung und Wiederherstellung von einem zentralen Standort aus zu automatisieren.

Mit dem installierten EAM-Modul kann ein Ignition Gateway als zentrales Controller Gateway fungieren, das mit einer beliebigen Anzahl von Remote Agent Gateways verbunden ist, diese überwacht und verwaltet. Verwenden Sie das Controller Gateway, um viele administrative Aufgaben für Agent Gateways zu koordinieren und zu automatisieren, einschließlich

Überprüfung von Zustand und Diagnose
Zuweisen, Aktualisieren, Aktivieren und Deaktivieren von Lizenzen
Bereitstellen neuer und aktualisierter Module
Wiederherstellung im Katastrophenfall
Remote-Backups
Fern-Upgrade von Ignition

EAM-Controller-Gateway und bewährte Praktiken

Wir empfehlen, entweder ein dediziertes EAM-Controller-Gateway einzurichten oder die Entwicklungsumgebung als Controller zu verwenden. Es wird empfohlen, EAM für Status und Diagnose, Lizenzen, Backups und Disaster Recovery sowie Upgrades zu verwenden. EAM bietet die Möglichkeit, Projekte und Tags von einer Umgebung in eine andere zu verschieben. Sie können EAM verwenden, um Tags von einer Umgebung in eine andere zu verschieben, aber es wird nicht empfohlen, EAM zu verwenden, um Projekte zu verschieben, da dies am besten über ein Versionskontrollsystem gehandhabt wird.

Quellcode-Kontrollsystem

Ein Versionskontrollsystem ist ein Versionskontrollsystem, das dazu dient, Änderungen am Quellcode und anderen Textdateien während der Entwicklung einer Software wie Ignition zu verfolgen. Es ermöglicht dem Benutzer, alle früheren Versionen des ursprünglichen Quellcodes und die gespeicherten Änderungen abzurufen. Versionskontrollsysteme bieten viele Vorteile:

Mehrere Versionen des Codes beibehalten
Die Möglichkeit, zu jeder früheren Version zurückzukehren
Entwickler können parallel arbeiten
Rückverfolgbarkeit mit einem klaren Bild davon, wer, was, wann, wo und wie die Änderungen vorgenommen hat
Synchronisierung des Codes
Kopieren/Zusammenführen/Rückgängigmachen der Änderungen
Herausfinden der Unterschiede zwischen den Versionen
Vollständige Sicherung, ohne viel Platz zu beanspruchen
Überprüfung des Änderungsverlaufs
Geeignet sowohl für kleine als auch für große Projekte
Möglichkeit, den Code weltweit zu teilen und daran zu arbeiten

Es gibt viele Versionskontrollsysteme, und wir empfehlen, dasjenige zu verwenden, mit dem Sie am besten vertraut sind. GitLab und Git ist ein sehr beliebtes Open-Source-Kontrollsystem.

Versionskontrolle & Ignition

Wir empfehlen, alle Ignition-Ressourcen in einem Versionskontrollsystem zu speichern, einschließlich Projekte, Tag-Exporte, Bilder und Gateway-Backups. Projekte lassen sich am besten über ein Versionskontrollsystem verwalten, da sie im Dateisystem gespeichert sind. Es ist äußerst einfach, Projekte in ein Versionskontrollsystem zu verschieben und von dort zu holen. Es ist jedoch wichtig, einen Prozess für die Speicherung und Bereitstellung von Tags, Images und Gateway-Konfiguration zu definieren, da diese in der internen SQLite-Datenbank von Ignition und nicht in einzelnen Dateien gespeichert werden.

Der Einstieg in die Verwendung eines Versionskontrollsystems ist äußerst einfach. Wir empfehlen, ein Versionskontrollsystem auf einem dedizierten Server oder einer VM zu installieren oder ein bestehendes Versionskontrollsystem zu verwenden, das in Ihrem Unternehmen bereits eingerichtet ist. Richten Sie einfach ein Projekt im Versionskontrollsystem für jede einzelne Ignition-Produktionsumgebung ein.

Projektverzweigungen (Branchs)

Ein Zweig (Branch) ist eine Version des Arbeitsbaums eines Projekts. Sie erstellen einen Branch für jeden zusammenhängenden Satz von Änderungen, den Sie vornehmen. Auf diese Weise bleiben die einzelnen Änderungssätze voneinander getrennt, so dass die Änderungen parallel durchgeführt werden können, ohne sich gegenseitig zu beeinflussen.

Nachdem Sie Ihre Änderungen in einen Branch verschoben haben, können Sie:

eine Zusammenführungsanforderung (Mergerequest) erstellen, um Änderungen von einem Branch in einen anderen zusammenzuführen
eine Inline-Codeprüfung durchführen und Änderungen in der Vorschau anzeigen
Ihre Implementierung mit Ihrem Team besprechen

Da wir in unserem Arbeitsablauf 3 verschiedene Umgebungen haben, ist es empfehlenswert, für jedes Projekt 3 verschiedene Banchs einzurichten:

Master: Der Hauptzweig, der für die Produktion verwendet wird
Testen: Der Branch, der zum Testen verwendet wird. In diesem Branch findet keine Entwicklung statt, aber die Änderungen werden von der Entwicklung in den Testbranch für die Qualitätssicherung zusammengeführt.
Entwicklung: Der Branch, der für die aktive Entwicklung verwendet wird

Nachdem wir nun unser Projekt und unsere Branchs eingerichtet haben, müssen wir festlegen, wie wir unsere Änderungen an das Repository übergeben.

Übertragen und Bereitstellen von Änderungen

Die aktive Entwicklung findet in der Entwicklungsumgebung statt. Sobald die Funktionen implementiert sind und als einigermaßen stabil angesehen werden, ist es an der Zeit, sie in den Testbranch einzubinden und sie dann in der Testumgebung einzusetzen. Wir empfehlen, die gesamte Ignition-Konfiguration im Repository zu speichern. Gehen wir nun die einzelnen oben beschriebenen Konfigurationspunkte durch: Projekte, Tags, Bilder und Gateway-Konfiguration.

Projekte

Projekte werden im Dateisystem gespeichert, was die Übergabe an ein Versionskontrollsystem erleichtert. Machen Sie einfach den Ignition-Projektordner zum Repository. Sie finden den Projektordner auf dem Ignition-Server an diesem Ort:

Linux

/var/lib/ignition/data/projects

Windows

C:\Program Files\Inductive Automation\Ignition\data\projects

Wenn das Repository im Versionskontrollsystem leer ist, übertragen Sie einfach den vorhandenen Ordner in die Repository. Wenn auf dem Entwicklungssystem keine Projekte vorhanden sind, ziehen Sie einfach die Repository vom Server, um die Projekte hinzuzufügen.

Achten Sie darauf, dass Sie den Ordner .resources in Ihrem Projektarchiv ignorieren (Eintrag im .gitignore file). Sie möchten nicht, dass dieses Verzeichnis in das Repository übertragen wird, da es für jedes System einzigartig ist. Siehe das Beispiel unten.

Übertragen Sie die Änderungen aus der Entwicklungsumgebung in das Repository mit Hilfe der entsprechenden Tools (GUIs, Befehlszeilen-Tools wie git), während sie vorgenommen werden.

Wenn wir bereit sind, die Änderungen in der Testumgebung bereitzustellen, können wir die Änderungen aus der Entwicklungsumgebung in die Testumgebung zusammenführen und die Änderungen aus der Repository in den Projektordner auf dem Testserver ziehen.

Weitere Einzelheiten finden Sie im folgenden GitLab-Beispiel.

Bilder

Bilder werden in der internen SQLite-Datenbank von Ignition gespeichert, so dass sie nicht als Dateien existieren, die wir an die Repository übergeben können. Wir können jedoch Bilder in einen Ordner exportieren. Hier kann der Entwickler Bilder mit dem Bildverwaltungswerkzeug im Ignition Designer in einen Ordner innerhalb des Projektordners exportieren, wenn er bereit ist, seine Änderungen in das Projektarchiv zu übertragen. Stellen Sie sicher, dass Sie alle Bilder und Ordner im Bildverwaltungswerkzeug auswählen. Wir empfehlen, ein „.images“-Verzeichnis im Projektverzeichnis zu erstellen und die Bilder in dem neu erstellten Verzeichnis zu speichern:

<IGNITION INSTALL DIRECTORY>/data/projects/.images

Im Allgemeinen sollten Sie keine Ordner im Projektverzeichnis erstellen, da das Gateway davon ausgeht, dass jeder Ordner ein Projekt ist. Das Gateway ignoriert jedoch alle versteckten Verzeichnisse oder solche, die mit einem „.“ beginnen.

Wenn wir bereit sind, die Änderungen zum Testen bereitzustellen, können wir die Änderungen von der Entwicklung zum Testen zusammenführen und die Bilder im Designer auf den Testserver importieren.

Gateway-Konfiguration

Die Gateway-Konfiguration wird in der internen SQLite-Datenbank von Ignition gespeichert und verfügt über keine Export- und Importfunktionen. Aus diesem Grund empfehlen wir, die letzte Gateway-Sicherung (.gwbk) im Repository zu speichern. Hier kann der Entwickler ein Gateway-Backup in der Gateway-Konfigurationswebseite speichern, wenn er bereit ist, seine Änderungen in das Repository zu übertragen.

Wir empfehlen, ein weiteres verstecktes Verzeichnis im Projektverzeichnis anzulegen, um das letzte Gateway-Backup zu speichern, ähnlich wie bei der Speicherung von Bildern im vorherigen Abschnitt. Nennen Sie dieses neue Verzeichnis „.gateway_backups“:

<IGNITION INSTALL DIRECTORY>/data/projects/
.gateway_backups/Ignition-backup-XXXXXXXX-XXXX.gwbk

Wenn wir bereit sind, die Änderungen für den Testbetrieb bereitzustellen, können wir die Änderungen von der Entwicklung zum Testbetrieb zusammenführen und die erforderlichen Änderungen der Gateway-Konfiguration auf dem Testserver manuell vornehmen.

Definieren Sie Ihren Arbeitsablauf und Prozess

Sie müssen Ihren eigenen Arbeitsablauf und Prozess definieren, der von allen verstanden wird. Achten Sie darauf, dass Sie alle oben aufgeführten Fragen beantworten. Dokumentieren Sie den Prozess und stellen Sie jedem Entwickler einen Spickzettel zur Verfügung. Wir empfehlen außerdem, eine Checkliste für die Bereitstellung zu erstellen, um die Genauigkeit zu gewährleisten.

GitLab-Beispiel

GitLab installieren
Befolgen Sie die nachstehenden Anweisungen, um GitLab auf einem zentralen Server oder einer VM zu installieren:
https://about.gitlab.com/install/
Einrichten des Root-Passworts
Sie werden diesen Root-Benutzer bei der Verwendung von Git benutzen
Persönliches Zugriffstoken generieren
Befolgen Sie die nachstehenden Anweisungen, um ein Token für die automatische Veröffentlichung zu erstellen:
https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
Stellen Sie sicher, dass Sie alle Bereiche überprüfen.
Neues Projekt einrichten (Repository)
Erstellen Sie im Dashboard ein neues Projekt mit dem von Ihnen gewünschten Namen. Das Projekt wird standardmäßig leer sein.
Einrichten der Produktionsumgebung
Gehen wir davon aus, dass Ihre Produktionsumgebung bereits eingerichtet ist. Sie können einfach die Git-Befehlszeilentools installieren und Ihre Projekte im Repository veröffentlichen.Git-Befehlszeilen-Tools installieren
Windows
https://git-scm.com/download/win

Linux
```
sudo apt-get install git
```
Identifizieren Sie sich in Git
Führen Sie die folgenden Befehle aus:
```
git config --global user.name "IhrBenutzername"
git config --global user.email "your@email.addr"
```
Projekte im Repository veröffentlichen

Navigieren Sie zu dem folgenden Verzeichnis:
```
<IGNITION INSTALL DIRECTORY>/data/projects
```
Fügen Sie zunächst eine .gitignore-Datei hinzu, um das Verzeichnis .resources zu ignorieren.
```
nano .gitignore
```
Fügen Sie die folgende Zeile in die .gitignore-Datei ein:
```
.resources/
```
Speichern Sie die Datei. Führen Sie nun die folgenden Befehle aus, um die Repository zu initialisieren und zu übertragen:
```
git init
git remote add origin http(s)://root:TOKEN@URL/root/PROJECT.git
git add .
git commit -m "Initial commit"
git push -u origin master
```
Nach der ersten Übertragung setzen Sie den Branch für künftige Übertragungen auf master.
```
git branch --set-upstream-to=origin/master
```
Wir haben unsere Projekte nun erfolgreich übertragen. Außerdem müssen wir Tags, Bilder und die Gateway-Konfiguration exportieren und übertragen. Für Tags können wir die Tags aus dem Designer in eine tags.json-Datei exportieren. Für Bilder können wir das Bildverwaltungswerkzeug im Designer verwenden, um alle Bilder in einen Ordner namens „images“ zu exportieren. Für die Gateway-Konfiguration erstellen Sie einfach ein Gateway-Backup. Nehmen Sie alle Dateien und Ordner und speichern Sie sie im Verzeichnis „projects“. Sobald sie hinzugefügt wurden, verwenden Sie die folgenden Befehle, um sie in die Repository zu übertragen:
```
NOW=$(date +"%m-%d-%Y %H:%M:%S")
git add .
git commit -m "Designer save @ $NOW"
git push origin
```
Passen Sie das obige Skript für Windows an. Jetzt ist alles in der Repository gespeichert.
Entwicklungs- und Testbranch erstellen
Verwenden Sie die Weboberfläche, um einen Entwicklungs- und Testbranch aus dem Masterbranch zu erstellen. Alle Daten werden automatisch in den Hauptzweig übertragen. Folgen Sie diesen Anweisungen:
https://docs.gitlab.com/ee/gitlab-basics/create-branch.html
Einrichten von Entwicklung und Testing
Installieren Sie Ignition auf speziellen Entwicklungs- und Testmaschinen oder VMs. Befolgen Sie die obigen Anweisungen zur Installation von Git. Sobald Git installiert ist, navigieren Sie zum folgenden Verzeichnis:
```
<IGNITION INSTALL DIRECTORY>/data
```
Entfernen Sie den Ordner projects, der bereits existiert. Er ist leer, da es sich um eine Neuinstallation handelt. Nach dem Entfernen führen Sie die folgenden Befehle in diesem Verzeichnis aus:
```
git clone http(s)://root:TOKEN@URL/root/PROJECT.git projects
```
Navigieren Sie nun in den neu erstellten Ordner projects. Führen Sie die folgenden Befehle aus, um in den Entwicklungs- oder Testbranch zu wechseln:
```
git checkout development 
git branch --set-upstream-to=origin/development
```
Ersetzen Sie „development“ oben mit „testing“ für den Testbranch auf dem Testing-Server.
Zum Schluss müssen wir sicherstellen, dass die Tags und Bilder in den Designer importiert werden. Sie können entweder EAM zum Importieren von Tags verwenden oder manuell in den Designer importieren. Außerdem müssen wir alle Gateway-Konfigurationen, wie z. B. das Erstellen von Datenbank- oder Geräteverbindungen, das Einrichten von Authentifizierungsprofilen usw., manuell einbinden. Leider ist dies ein manueller Schritt, aber wichtig, um Änderungen in diesen Bereichen zu verfolgen.
Automatisches Übertragen von Änderungen aus der Entwicklung
Nachdem wir nun die Entwicklungsumgebung eingerichtet haben und die Projekte aus dem Entwicklungsbranch gezogen wurden, müssen wir Ignition so einrichten, dass Änderungen automatisch übertragen werden, wenn ein Entwickler im Ignition Designer auf Speichern drückt. Zunächst müssen wir ein Batch-/Shell-Skript im Datenverzeichnis mit dem Namen „git-auto-commit.sh“ oder „git-auto-commit.bat“ erstellen, z. B. unter Linux:
```
/var/lib/ignition/data/git-auto-commit.sh
```
Die Datei wird die folgenden Zeilen enthalten:
```
cd /var/lib/ignition/data/projects 
NOW=$(date +"%m-%d-%Y %H:%M:%S") 
git add . 
git commit -m "Designer save @ $NOW" 
git push origin
```
Passen Sie das obige Skript für Windows an. Stellen Sie sicher, dass die Datei über Ausführungsberechtigungen verfügt. Als nächstes müssen wir dieses Skript jedes Mal aufrufen, wenn ein Entwickler im Designer auf „Speichern“ drückt. Öffnen Sie den Ignition Designer und wählen Sie Projekt > Gateway-Ereignisse > Aktualisieren. Weitere Einzelheiten finden Sie in der Dokumentation:
https://docs.inductiveautomation.com/display/DOC80/Gateway+Event+Scripts#GatewayEventScripts-UpdateScript

Fügen Sie das folgende Skript hinzu:
```
import time
time.sleep(5)
system.util.execute(["/var/lib/ignition/data/git-auto-commit.sh"])
```
Das Skript ruft das Batch/Shell-Skript auf und überträgt die Änderungen bei jedem Speichern an das Repository. Speichern Sie das Projekt und überprüfen Sie das Repository in GitLab, um die Übertragung zu sehen.
Automatisches Übertragen von Tags
Es kann praktisch sein, Tags automatisch zu exportieren und sie als Teil des Speichervorgangs in der Repository zu speichern. Passen Sie dazu einfach das Skript Gateway Event Update wie folgt an:
```
import time
filePath = "/var/lib/ignition/data/projects/tags.json" 
system.tag.exportTags(filePath=filePath, tagPaths=["[default]"]) 
time.sleep(5) 
system.util.execute(["/var/lib/ignition/data/git-auto-commit.sh"])
```
Passen Sie die Tag-Pfade so an, dass sie alle Tag-Provider enthalten, die Sie exportieren möchten. Die Tags werden exportiert und bei jedem Speichervorgang in einer Datei namens tags.json innerhalb des Projektverzeichnisses gespeichert. Die Übergabe erfolgt nach dem Export, so dass die Datei in die Repository übertragen wird.
Bereitstellung von Änderungen
Sobald wir mit der Entwicklung fertig sind, müssen wir die Änderungen in der Testumgebung bereitstellen. Zunächst müssen wir die Änderungen aus dem Entwicklungsbarnch in den Testbranch in GitLab zusammenführen. Öffnen Sie die Benutzeroberfläche und erstellen Sie einen Mergerequest vom Entwicklungsbranch zum Testbranch. Standardmäßig wird der Master-Branch ausgewählt. Ändern Sie diesen in den Testbranch. Deaktivieren Sie das Kontrollkästchen „Source branch löschen“, damit der Entwicklungsbranch nicht entfernt wird. Weitere Einzelheiten finden Sie in der Dokumentation von GitLab:https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.htmlSobald der Mergerequest erstellt ist, müssen Sie die Anforderung genehmigen und die Änderungen tatsächlich in den Testbranch zusammenführen. Sobald die Änderungen zusammengeführt sind, müssen wir unsere Änderungen in Ignition auf dem Testserver bereitstellen.
1. Bereitstellen von Projekten
  Für Projekte müssen wir nur die Änderungen aus der Repository ziehen. Führen Sie den folgenden Befehl auf dem Testserver aus:
```
git pull
```
  Sobald die Änderungen heruntergeladen sind, aktualisiert Ignition automatisch die Projektressourcen. Die Clients werden automatisch aktualisiert. Wenn Sie den Ignition Designer bereits geöffnet hatten, müssen Sie auf Datei > Projekt aktualisieren klicken, um die Änderungen vom Server zu übernehmen.
2. Bereitstellen von Tags
  Die tags.json-Exportdatei wird aus dem vorherigen Schritt übernommen. Sie können die Tags entweder manuell in die Testumgebung importieren oder EAM verwenden, um Tag-Änderungen bereitzustellen.
3. Bereitstellen von Bildern
  Die Bilder werden aus der Repository des vorherigen Schritts gezogen. Sie müssen die Bilder manuell in das Image Management Tool im Ignition Designer importieren.
4. Bereitstellen der Gateway-Konfiguration
  Sie müssen alle Änderungen an der Gateway-Konfiguration manuell auf die Testumgebung anwenden. Dazu gehören das Ändern von Einstellungen, das Hinzufügen von Datenbankverbindungen, das Hinzufügen von Geräteverbindungen und vieles mehr. Dies ist wohl der schwierigste Teil der Bereitstellung von Änderungen von der Entwicklungs- zur Test- und von der Test- zur Produktionsumgebung. Stellen Sie die Gateway-Sicherung NICHT wieder her, wenn Sie die Test- oder Produktionsumgebung einsetzen, da es in jeder Umgebung Unterschiede gibt.

Ignition 8 Deployment Best Practices

Einführung

Der Workflow

Die Konfiguration von Ignition

Gateway-Konfiguration

Tags

Bilder

Projekte

Linux

Windows

Change Track Summary

Bereitstellungsumgebungen

Umgebungen

Entwicklung

Testen

Produktion

Modul zur Unternehmensverwaltung

EAM-Controller-Gateway und bewährte Praktiken

Quellcode-Kontrollsystem

Versionskontrolle & Ignition

Projektverzweigungen (Branchs)

Übertragen und Bereitstellen von Änderungen

Projekte

Tags

Bilder

Gateway-Konfiguration

Definieren Sie Ihren Arbeitsablauf und Prozess

GitLab-Beispiel

WIR FREUEN UNS AUF SIE

© MPI Technologies AG