nicht angemeldet
gitlab
Rolf B
AugeHallo,
ich hätte da eine kurze Frage bezüglich gitlab.
Gitlab ist u.a. ja ein Verwaltungstool. Ist da eventuell möglich, unter GitLab auch den Code, den man hochgeladen hat, zum laufen zu bringen, damit die Beteiligten einfach darauf zugreifen und sehen, wie z.B. eine Webseite bis dahin läuft und aussieht? Gibt es sonst eine Möglichkeit, dies zu tun.
LG
-
Hallo Lowterm,
mit GitLab kenne ich mich nicht aus. Grundsätzlich ist das aber ein CI/CD Tool und du solltest im Stande sein, nach einem Checkin automatisch ein Deployment des aktuellen Standes auf einen Webserver ausführen zu lassen. Das sollte über die Pipelines machbar sein.
Bei Github weiß ich, dass es Github Pages gibt, womit man einen eingecheckten Stand darstellen kann. Wie das dort genau geht, habe ich noch nicht ausprobiert.
Rolf
--
sumpsi - posui - obstruxi-
mit GitLab kenne ich mich nicht aus. Grundsätzlich ist das aber ein CI/CD Tool und du solltest im Stande sein, nach einem Checkin automatisch ein Deployment des aktuellen Standes auf einen Webserver ausführen zu lassen. Das sollte über die Pipelines machbar sein.
Auch wenn Du dich damit nicht auskennst, hast Du da m.E. den Nagel auf den Kopf getroffen. Deployment von Projekt X auf Server Y. Dann auf Server Y gucken.
-
Halo Rolf,
danke für deine Antwort.
Grundsätzlich ist das aber ein CI/CD Tool und du solltest im Stande sein, nach einem Checkin automatisch ein Deployment des aktuellen Standes auf einen Webserver ausführen zu lassen.
Leider habe ich nicht ganz verstanden. Du meinst, nach einem Checkin des Projektes dieses auf einem Server meiner Wahl vor Ort zu installieren? Das ist ja klar, das man dies auf einem Server machen kann.
Das ist vielleicht etwas weit hergeholt. Ich meinte aber, ob man das hochgeladene Projekt direkt bei gitlab deployen könnte.
Gruß
-
Das ist vielleicht etwas weit hergeholt. Ich meinte aber, ob man das hochgeladene Projekt direkt bei gitlab deployen könnte.
Hinweis: Wenn ich hier von Server spreche, meine ich nicht zwangsläufig Blech. Anno 2022 schon mal gar nicht mehr. Der Begriff Instanz von Auge trifft es besser.
Du deployst vom Gitlab-Server auf den Server, auf dem das Projekt laufen/getestet/gestaged werden soll. Hintergrund: Du willst den Gitlab-Server nicht mit sämtlichen Abhängigkeiten vollmüllen, den Dein Projekt zum Rennen braucht.
Aus ähnlichen Erwägungen heraus stellt man z.B. auch getrennte Mailserver, Datenbankserver, Webserver usw... bereit, statt allen Bombast auf einem System zu realisieren.
Theoretisch kann das auch auf dem Gitlab-Server passieren, dann aber virtualisiert/gedockert oder so.
Sonst hast Du auf dem Gitlab-System potentiell einen großen Wust an Inkompatibilitäten. Deine Web-Applikation muss nicht mit dem Gitlab-Setup können, umgekehrt genauso.
Beispiel: Gitlab verwendet Nginx als Webserver. Du womöglich den Apache. Gitlab mag PostgreSQL, Du womöglich Mysql/MariaDB. Usw, usw....
-
Hallo,
danke. Der Hintergrund ist der. Der Kunde will jederzeit Zugriff auf die Entwicklung haben und möchte jederzeit den Stand der Webseite sehen und herumklicken können. Aus Sicherheitsgründen kann dies aber nicht auf dem Firmenserver gestattet werden, weil sonst viele Rechte zu vergeben sind.
Eine Überlegung war eben, gitlab dafür einzusetzen, weil das komplette Projekt ist da ja bereits vorhanden und kann da theoretisch auch laufen. Aus Mangel an Erfahrung weiß ich aber nicht genau, wie das gehen soll, denn jeder Server muss ja die Programmiersprachen, mit denen das Projekt geschrieben ist unterstützen können. Daher versehe nicht ganz, wie das Vorhaben ohne weiteres bei gitlab funktionieren soll.
Gruß
-
danke. Der Hintergrund ist der. Der Kunde will jederzeit Zugriff auf die Entwicklung haben und möchte jederzeit den Stand der Webseite sehen und herumklicken können. Aus Sicherheitsgründen kann dies aber nicht auf dem Firmenserver gestattet werden, weil sonst viele Rechte zu vergeben sind.
Ein nachvollziehbares und gängiges Szenario.
Eine Überlegung war eben, gitlab dafür einzusetzen, weil das komplette Projekt ist da ja bereits vorhanden und kann da theoretisch auch laufen. Aus Mangel an Erfahrung weiß ich aber nicht genau, wie das gehen soll, denn jeder Server muss ja die Programmiersprachen, mit denen das Projekt geschrieben ist unterstützen können. Daher versehe nicht ganz, wie das Vorhaben ohne weiteres bei gitlab funktionieren soll.
Das ist genau der Punkt. Wie Rolf eingangs schon sagte: bring Dein Gitlab-Setup dazu, automatisch via Pipelines auf Deinen Testserver(Testinstanz) zu deployen. So ein Testsystem gibt es für ca. 5 Euro/Monat, z.B. bei Hetzner.
Da kann Dein Kunde dann gucken, meckern, Du änderst was, commitest und Gitlab deployed erneut für Dich... der Kunde kann erneut gucken und meckern.. usw...
Das ist m.E. ein gängiger Workflow.
-
Hallo Lowterm,
es soll ja auch gar nicht bei gitlab funktionieren.
Der Vorschlag ist doch, einen von gitlab unabhängigen DevTest Server aufzusetzen und im gitlab eine Deployment-Pipeline einzurichten, die den aktuellen Development-Branch dorthin deployed.
Diese Deployment-Pipeline kann durch einen Checkin getriggert werden (zumindest geht das bei Github oder Azure Devops so), aber es könnte auch sinnvoll sein, das nur auf Knopfdruck zu machen, wenn man den Kunden auf dem DevTest Server nicht bei jedem Checkin aus der Kurve schießen möchte.
Habt ihr schon eine Deployment-Pipeline für den Fachtest- oder Produktionsserver? Dann müsst ihr das einfach nur für den DevTest Server klonen. Wenn nicht, okay, dann müsst ihr euch einlesen, wie man das mit gitlab macht.
Ob der DevTest Server auf eigenem Blech läuft oder auf der gleichen Maschine wie der gitlab-Server, ist euch überlassen. Bei einer gemeinsamen Maschine gibt's weniger Aufwand für die Remote-Kommunikation, aber dann braucht ihr entweder ein Feature auf der Maschine, das Port Sharing[1] unterstützt - oder der DevTest Server muss auf einen eigenen Port lauschen.
Ich rotze hier zwar einen Berg an Fachbegriffen raus, aber das heißt nicht, dass ich auch nur die Spur einer Ahnung hätte, wie man das mit gitlab und Linux macht. Ich kenne sowas nur von Azure Devops (ehemals Team Foundation Server) mit Windows Server und dem IIS.
Rolf
--
sumpsi - posui - obstruxi
das bedeutet 2 Dienste, die auf den gleichen Port lauschen und bei denen an Hand des Hostnamens unterschieden wird, an wen von beiden es geht. Bei Windows Server geht das, ich würde wetten, dass Microsoft das von Linux abgeguckt hat. Wenn nicht, müsste man im nginx von GitLab ein passendes Forwarding für den DevTest Server einrichten. ↩︎
-
Ich rotze hier zwar einen Berg an Fachbegriffen raus, aber das heißt nicht, dass ich auch nur die Spur einer Ahnung hätte, wie man das mit gitlab und Linux macht. Ich kenne sowas nur von Azure Devops (ehemals Team Foundation Server) mit Windows Server und dem IIS.
Mir geht das mit der Microsoft-Welt genauso unwissend. Unter Gitlab/Linux läuft es dennoch verblüffend ähnlich. Bei Microsoft würde ich nur irgendwelche mir komisch vorkommenden XML erwarten, um so eine Config aufzusetzen ;-)
-
Hallo Mitleser,
XML
fast. Bei DevOps hast Du die Wahl zwischen Klickibunti oder YAML.
Rolf
--
sumpsi - posui - obstruxi
-
-
Hallo
Bei einer gemeinsamen Maschine gibt's weniger Aufwand für die Remote-Kommunikation, aber dann braucht ihr entweder ein Feature auf der Maschine, das Port Sharing unterstützt - oder der DevTest Server muss auf einen eigenen Port lauschen.
das bedeutet 2 Dienste, die auf den gleichen Port lauschen und bei denen an Hand des Hostnamens unterschieden wird, an wen von beiden es geht. Bei Windows Server geht das, ich würde wetten, dass Microsoft das von Linux abgeguckt hat. Wenn nicht, müsste man im nginx von GitLab ein passendes Forwarding für den DevTest Server einrichten.
Wenn die Gitlab-Instanz und der Testserver auf der selben Maschine laufen und ohne zusätzliche Portangaben durch die Nutzer einzeln erreichbar sein sollen, hülfe beispielsweise die Benutzung verschiedener Subdomains und die Vorschaltung eines Reverse-Proxies vor das Konstrukt zur zielgerichteten Weiterleitung der jeweiligen Anfragen. Dazu kann man beispielsweise auch einen NginX oder einen Apachen benutzen.
Tschö, Auge
--
200 ist das neue 35.
-
-
-
Hallo
Grundsätzlich ist das aber ein CI/CD Tool und du solltest im Stande sein, nach einem Checkin automatisch ein Deployment des aktuellen Standes auf einen Webserver ausführen zu lassen.
Leider habe ich nicht ganz verstanden. Du meinst, nach einem Checkin des Projektes dieses auf einem Server meiner Wahl vor Ort zu installieren? Das ist ja klar, das man dies auf einem Server machen kann.
Nein, das war nicht gemeint. Mit einem in einem Gitlab-Repository definierten CI/CD kannst du mit einem Commit oder Tag (oder welchem Trigger auch immer) eine Abfolge von Aktionen ausführen. Dazu gehört zum Beispiel auch, einen Release/Stand auf einem Server zu installieren.
Das ist vielleicht etwas weit hergeholt. Ich meinte aber, ob man das hochgeladene Projekt direkt bei gitlab deployen könnte.
Jein, durch Gitlab, nicht unbedingt bei Gitlab/der Gitlab-Instanz.
Tschö, Auge
--
200 ist das neue 35.
-
-