2
Quelltextverwaltung - Webentwicklung
Moin,
ich habe eine Frage zu folgendem Thema.
Zwei eigentlich eigenständige Webentwickler sollen in der Zukunft gemeinsam an Projekten arbeiten.
Für die "saubere" Zusammenarbeit wurde nun die Einführung einer Quelltextverwaltung gewünscht.
Die Entwicklungsumgebungen unterstützten SVN, GIT, usw. Meine Frage geht eher in Richtung "doing".
Ich entschuldige mich schon einmal im vorraus, wenn ich die Fachbegriffe würfel. Man merkt, ich bin darin nicht firm.
Wir würden also gerne die Projekte in eigene Branches aufsplitten, wo die zwei Mitarbeiter Änderungen über das SVN/GIT einstellen können.
Nur gibt es auch die Möglichkeit, dass man eine Änderung dann auch direkt auf dem Webserver durchführen kann? Bzw. Änderungen, die getestet werden müssen,
auf einem Testwebserver ausgerollt werden. Wie geht man da vor?
Gibt es dafür evtl. irgendwo ein Tutorial?
Gruß
ich habe eine Frage zu folgendem Thema.
Zwei eigentlich eigenständige Webentwickler sollen in der Zukunft gemeinsam an Projekten arbeiten.
Für die "saubere" Zusammenarbeit wurde nun die Einführung einer Quelltextverwaltung gewünscht.
Die Entwicklungsumgebungen unterstützten SVN, GIT, usw. Meine Frage geht eher in Richtung "doing".
Ich entschuldige mich schon einmal im vorraus, wenn ich die Fachbegriffe würfel. Man merkt, ich bin darin nicht firm.
Wir würden also gerne die Projekte in eigene Branches aufsplitten, wo die zwei Mitarbeiter Änderungen über das SVN/GIT einstellen können.
Nur gibt es auch die Möglichkeit, dass man eine Änderung dann auch direkt auf dem Webserver durchführen kann? Bzw. Änderungen, die getestet werden müssen,
auf einem Testwebserver ausgerollt werden. Wie geht man da vor?
Gibt es dafür evtl. irgendwo ein Tutorial?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 433684
Url: https://administrator.de/forum/quelltextverwaltung-webentwicklung-433684.html
Ausgedruckt am: 26.12.2024 um 17:12 Uhr
2 Kommentare
Neuester Kommentar
Moin ...
na evtl. dort anfangen ... https://guides.github.com/activities/hello-world/
und im Bezug auf Webserver mal mit composer auseiandersetzen ... easy going ...
VG
Edit: BTW: Frag doch mal die Webentwickler die sollten das kennen
Zitat von @informatikkfm:
Nur gibt es auch die Möglichkeit, dass man eine Änderung dann auch direkt auf dem Webserver durchführen kann? Bzw. Änderungen, die getestet werden müssen,
auf einem Testwebserver ausgerollt werden. Wie geht man da vor?
Nur gibt es auch die Möglichkeit, dass man eine Änderung dann auch direkt auf dem Webserver durchführen kann? Bzw. Änderungen, die getestet werden müssen,
auf einem Testwebserver ausgerollt werden. Wie geht man da vor?
na evtl. dort anfangen ... https://guides.github.com/activities/hello-world/
und im Bezug auf Webserver mal mit composer auseiandersetzen ... easy going ...
VG
Edit: BTW: Frag doch mal die Webentwickler die sollten das kennen
Git ist zum Quasi-Standard geworden. SVN würde ich heutzutage nur noch für ältere Projekte einsetzen bei denen sich eine Migration nicht mehr lohnt. Oder wenn man ohnehin bereits SVN im Einsatz hat und es keine Notwendigkeit zum migrieren gibt.
Wenn ihr nach heutigem Stand entwickeln wollt, braucht ihr CI/CD. Sprich einen GitLab oder auch Jenkins, der entsprechend konfiguriert wird, dass er die jeweiligen Branches automatisch auf verschiedene Systeme deployt. Im einfachsten Falle wird master aufs Produktivsystem deployt und dann noch ein dev/quality auf ein gemeinsames Dev/Qualitätssystem. Damit hast du den Anwendungsfall der Ausführung auf dem Webserver abgedeckt: Der Entwickler pusht seinen Stand und die Software wird direkt aufs jeweilige System deployt. Im besten Falle laufen dann noch automatische Tests ab, um Qualität und Konventionen sicherzustellen.
Damit sich Entwickler nicht in die Quere kommen, nutzt man Feature Branches. Entwickler A legt sich z.B. einen Branch navbar-design an und arbeitet dort. Entwickler B erzeugt den admin-dashboard Branch. Beide entwickeln zunächst lokal und sollten natürlich auch dort testen. Im besten Falle nutzt ihr Docker, um relativ einfach eine konsistente Umgebung zu erhalten. Wenn die Entwickler einen testbaren Stand haben, wird er auf dev gepusht. Dort kann man dann auf einem gemeinsamen Testsystem die Funktion ausprobieren und auch mal dem PO/Chef zeigen. Ist der Stand final, gibts einen Merge Request auf master und das ganze geht damit Produktiv.
Das ist jetzt natürlich recht einfach und grundsätzlich gehalten. Man kann das je nach Anforderung auch aufsplitten. Beispielsweise in die bekannte 3-Systemlandschaft, dass man Dev/Quality/Prod hat. Macht grade bei größeren und kritischen Projekten Sinn. Bei zwei Entwickler gehts aber wohl eher um ein kleines Projekt, da dürften zwei Systeme reichen. Hängt aber natürlich immer an den konkreten Anforderungen ab.
Wenn ihr nach heutigem Stand entwickeln wollt, braucht ihr CI/CD. Sprich einen GitLab oder auch Jenkins, der entsprechend konfiguriert wird, dass er die jeweiligen Branches automatisch auf verschiedene Systeme deployt. Im einfachsten Falle wird master aufs Produktivsystem deployt und dann noch ein dev/quality auf ein gemeinsames Dev/Qualitätssystem. Damit hast du den Anwendungsfall der Ausführung auf dem Webserver abgedeckt: Der Entwickler pusht seinen Stand und die Software wird direkt aufs jeweilige System deployt. Im besten Falle laufen dann noch automatische Tests ab, um Qualität und Konventionen sicherzustellen.
Damit sich Entwickler nicht in die Quere kommen, nutzt man Feature Branches. Entwickler A legt sich z.B. einen Branch navbar-design an und arbeitet dort. Entwickler B erzeugt den admin-dashboard Branch. Beide entwickeln zunächst lokal und sollten natürlich auch dort testen. Im besten Falle nutzt ihr Docker, um relativ einfach eine konsistente Umgebung zu erhalten. Wenn die Entwickler einen testbaren Stand haben, wird er auf dev gepusht. Dort kann man dann auf einem gemeinsamen Testsystem die Funktion ausprobieren und auch mal dem PO/Chef zeigen. Ist der Stand final, gibts einen Merge Request auf master und das ganze geht damit Produktiv.
Das ist jetzt natürlich recht einfach und grundsätzlich gehalten. Man kann das je nach Anforderung auch aufsplitten. Beispielsweise in die bekannte 3-Systemlandschaft, dass man Dev/Quality/Prod hat. Macht grade bei größeren und kritischen Projekten Sinn. Bei zwei Entwickler gehts aber wohl eher um ein kleines Projekt, da dürften zwei Systeme reichen. Hängt aber natürlich immer an den konkreten Anforderungen ab.
