So integrieren Sie die Versionskontrolle (Git) in ein großes Lotus Notes-Projekt
Wir unterhalten eine große Website basierend auf Lotus Notes, die auf Domino Server 8.5.3 läuft. Kürzlich hatten wir die Nase voll von der fehlenden Kontrolle über die Quellen in unserem Projekt, also dachten wir, wir würden versuchen, die Dinge ein wenig aufzumischen. Aber wie macht man das richtig?
Aus verschiedenen Gründen, auf die ich hier nicht eingehen werde, können wir unsere Anwendungen nicht lokal auf den Entwicklungs-PCs ausführen. Wir können sie nur auf den Entwicklungs-, Staging- und Produktionsservern ausführen. (Lokaler Domino-Server, der auf den Entwicklungs-PCs ausgeführt wird, ist leider keine Option.)
Diese Abbildung zeigt die aktuelle Situation:
In Produktion (und Staging) gibt es mehrere Websites, die alle die gleiche Funktionalität haben. Sie sind im Grunde die gleiche Website mit dem gleichen Design, aber mit unterschiedlichem Inhalt. Jede Site besteht aus einer Reihe von Notes Datenbanken (News, Archive, Discussion etc.). Das Design dieser Datenbanken ist für alle Sites gleich, daher erben alle ihr Design von den gleichen Mastervorlagen (NewsTemplate, ArchiveTemplate, DiscussionTemplate usw.).
Ein Satz Replikate der Master-Vorlagen befindet sich auf dem Entwicklungsserver. Wenn wir neue Funktionen bereitstellen, werden die erforderlichen Codeänderungen zu den Vorlagen auf dem Dev hinzugefügt. Server (mehr dazu unten). Anschließend werden diese Vorlagen zum Testen auf den Staging-Server und schließlich auf den Produktionsserver repliziert. Dieser Teil funktioniert ganz gut.
Die Probleme können im unteren Teil der Abbildung gefunden werden. Wir sind derzeit zwei Entwickler, und wir arbeiten beide in der gleichen Reihe von Entwicklern. Datenbanken (News, Archiv, Diskussion etc.) auf dem Dev. Server. Natürlich stolpern wir ständig über die Arbeit der anderen, was ziemlich frustrierend ist. Wenn es Zeit für die Bereitstellung ist, wird der Code, der bereitgestellt werden soll, selektiv aus dem Dev-Satz kopiert / eingefügt. Datenbanken zum Dev. Vorlagen. Dies geschieht manuell und somit ist das Risiko von Fehlern hoch. Wir können das Design der Templates nicht einfach durch das des Entwicklers ersetzen. Datenbanken, weil der Entwickler. Datenbanken enthalten jederzeit Code, der gerade entwickelt wird. Daher müssen wir sehr sorgfältig darauf achten, nur Code zu verwenden, der "fertig" ist. Auch haben wir keine Änderungsgeschichte. Dies ist eine schreckliche, schreckliche, schreckliche (fügen Sie so viele schreckliche wie Sie für richtig halten) Weg, Software-Entwicklung zu tun, und wir wissen es.
Nun, mit Git, lokalen Replikaten, Datenbankkopien oder was auch immer, was wäre der beste Weg, um ein schlankeres Entwicklungs- und Implementierungsschema zu erreichen?
1 Antwort
Diese Abbildung zeigt eine mögliche Lösung des Problems:
Wie erklärt hier , jeder Entwickler sollte seine eigene COPY (nicht Replik) der Datenbank / Vorlage (oder in unserem Fall von Vorlagen) zu entwickeln. Also auf jedem Entwickler. PC gibt es eine Reihe von Vorlagen, und jede Vorlage wird mit einem On-Disk-Projekt synchronisiert. Die Gruppe von Projekten auf der Festplatte wird mit Git unter Versionskontrolle stehen.
Der Entwickler kann die Anwendung nicht lokal ausführen, daher benötigt er eine Reihe von Testdatenbanken auf dem Entwickler. Server. Es wird ein solches Set für jeden Entwickler geben. Die Testdatenbanken übernehmen ihren Entwurf von den Vorlagen auf dem Entwickler. PC. Um also seine Codeänderungen zu testen, muss der Entwickler das Design seiner bestimmten Testdatenbanken mit dem seiner Templates aktualisieren (die sich auf seinem PC befinden).
Der Workflow für jeden Entwickler ist wie folgt:
- Nehmen Sie Codeänderungen in den Vorlagensätzen auf dem eigenen PC des Entwicklers vor. Testen Sie kontinuierlich, indem Sie das Design der Testdatenbanken auf dem Dev aktualisieren. Server. Sync mit On-Disk-Projekten, Commit und Branch "nach Belieben".
-
Wenn der Entwickler bereit ist, zum Remote-Git-Repo zu wechseln:
a) Ziehen Sie Änderungen von Remote-Git Repo.
c) Drücken Sie die Änderungen zum Remote-Git Repo. Synchronisieren Sie Datenbanken mit Projekten auf der Festplatte.
d) Wenn derzeit im Zweig entwickeln : Ersetzen Sie das Design des Vorlagensatzes auf dem Entwickler. Server mit dem Design aus der Reihe von Vorlagen auf dem Dev. PC. Dadurch wird sichergestellt, dass der Zweig develop des Remote-Git-Repos immer mit den Vorlagen auf dem Entwickler übereinstimmt. Server, obwohl keine direkte Verbindung zwischen ihnen besteht.
-
Von hier aus können Änderungen in die Staging- und Produktionsumgebung implementiert werden, indem die Vorlagen vom Entwickler repliziert werden. Server. Vor der Bereitstellung in der Produktion sollte der Zweig develop mit dem Zweig master zusammengeführt werden, sodass master immer die aktuelle Produktionsversion widerspiegelt.
>
Wenn jemand Kommentare, Ergänzungen oder Einwände hat, würde ich sie gerne hören.
Bearbeiten: Um die Rückkopplungsschleife in Punkt 1 oben zu verkürzen, kann die Entwicklung direkt in den Testdatenbanken auf dem Entwickler durchgeführt werden. Server. Dadurch müssen Sie das Design der Testdatenbanken nicht jedes Mal aktualisieren, wenn Sie Ihre Änderungen testen müssen. Sie müssen jedoch darauf achten, alle Änderungen zurück auf das Entwicklungsprogramm zu kopieren. Vorlagen in regelmäßigen Abständen, um Ihren Code sicher zu halten und das Git Repo aktualisiert zu halten. Dies kann ziemlich schnell durch einen elementweisen Vergleich der Datenbank und der Vorlage erfolgen . Dies dient auch als eine Gelegenheit, Ihre Änderungen zu überprüfen, bevor Sie ein Commit machen, was eine sehr gute Gewohnheit ist.
Eine weitere Option zum Kopieren der Änderungen in die Vorlage besteht darin, die Testdatenbank auf dem Entwickler zu erstellen. Server eine Master-Vorlage und vorübergehend die Vorlage auf dem Dev festlegen. PC, um das Design von dieser Mastervorlage zu erben. Dann können die Änderungen mit "Refresh Design" auf dem Dev kopiert werden. PC Vorlage, nach der Sie die Vererbung wieder entfernen können.
Tags und Links git version-control deployment lotus-notes