D
Deleted member 11740
Guest
Ich hätte das Wort Backup erst gar nicht erwähnen sollen.
Ernstgemeinte Frage: Vertrauen ist keine Lösung?Wäre das nicht eine gute Lösung?
git würde sich meiner Meinung nach auch für den Deployment-Prozess super anbieten.Dann noch eine kurze Frage: Neue Funktionen wurden entwickelt, branches wurde mit dem master gemerged etc. Wie kommt nun die neue Version der Webseite auf die Produktivserver? Auch mit git, oder die entsprechenden Daten downloaden und per FTP uploaden?
Ganz ehrlich: Wenn du deinen Entwicklern nicht trauen kannst, dann hast du doch sowieso verloren, oder? Die Entwickler liefern das KnowHow mit ihren Köpfen. Und natürlich können sie das jederzeit irgendwo hin tragen, ob du den Quelltext jetzt umständlich schützt oder auch nicht. Außerdem macht das echt schlechte Stimmung, wenn die Entwickler nicht an den Code rankommen und dadurch nicht debuggen können.Warum das Ganze? Ich tue mich mit dem Gedanken schwer, das gesamte Projekt aus der Hand zu geben. Jeder Entwickler wäre mit dem git-Clone dazu fähig, das Projekt selbst zu hosten.
Mit einem vernünftigen Deployment-Tool. Sieh dir mal Ansible (http://www.ansible.com/home) an, das macht im Moment einen wirklich guten Eindruck.Dann noch eine kurze Frage: Neue Funktionen wurden entwickelt, branches wurde mit dem master gemerged etc. Wie kommt nun die neue Version der Webseite auf die Produktivserver?
Achtung: Du verwechselst continuous integration und automatische Tests mit Deployment. Mit Jenkins kann man so weit ich weiß nicht deployen und selbst wenn, würde ich das nicht machen, da der Fokus von Jenkins auf Testing liegt.Alternativ eines der vielen Deploy-Tools, die es so gibt - irgendeines wurde schon genannt, dann gäbe es da noch jenkins, hudson, ...
[...] daß man automatisiert Tests und Test-Deploys laufen lassen kann, ein sauberes Versionsmanagement auch auf Seiten der erstellten Builds hat, Logs, ...
Und wenn die Vertrauensbasis dermaßen wackelig ist, dann schließ mit deinen Entwicklern eine schriftliche Vereinbarung, in der genau fixiert wird, wer die Rechte am Code hat. Wenn dann die Codebasis oder Teile davon woanders auftauchen bzw. verwendet werden, dann hast du zumindest eine rechtliche Handhabe, um dagegen vorgehen zu können (Ob das dann sinnvoll ist oder nicht, sei mal dahingestellt...).Ganz ehrlich: Wenn du deinen Entwicklern nicht trauen kannst, dann hast du doch sowieso verloren, oder? Die Entwickler liefern das KnowHow mit ihren Köpfen. Und natürlich können sie das jederzeit irgendwo hin tragen, ob du den Quelltext jetzt umständlich schützt oder auch nicht. Außerdem macht das echt schlechte Stimmung, wenn die Entwickler nicht an den Code rankommen und dadurch nicht debuggen können.
Alderon said:Wo wir beim Thema sind: von welcher Programmiersprache sprechen wir eigentlich?
parkbank said:Ernstgemeinte Frage: Vertrauen ist keine Lösung?
nexus said:Und wenn die Vertrauensbasis dermaßen wackelig ist, dann schließ mit deinen Entwicklern eine schriftliche Vereinbarung, in der genau fixiert wird, wer die Rechte am Code hat.
Ja, sonst könnte ich auch nicht arbeiten. Wie soll ich sinnvoll einen Bug fixen, der durch komplexe Interaktion mit weiterem Code entsteht, ohne den Code lesen und verstehen zu können?Hier scheinen ja auch einige im Team zu entwicklen: Hat wirklich jeder von euch Zugriff auf alles? Wie handhaben das denn die anderen Unternehmen?
Okay. Ihr lasst also lokal auf der Entwickler-Maschine gar keine Tests laufen, bevor ihr Code ins Repo pusht? Oder habt ihr Binaries, die ihr zum Testen nehmt?Dadurch daß eben alles gekapselt ist durch die Build-Umgebung mit automatischen Builds, Tests usw. kommt der Entwickler auch gar nicht in Kontakt mit dem anderen Code - er kennt die API und entwickelt dagegen.
marce said:Aber ja - grundlegend laufen auf den Entwickler-PCs (eigentlich) keine Testumgebungen.