1. #1
    AFU
    AFU ist offline
    U-Labs Routinier
    Avatar von AFU
    Registriert seit
    19.11.2011
    Beiträge
    354
    Thanked 72 Times in 59 Posts

    Standard Versionsverwaltung für C# und bash

    Hallo,

    ich suche nach einer Möglichkeit, um möglichst bequem C#/bash verwalten zu können.
    Bitte um Info, welches REPO (zb git) bzw. welche Tools aus eurer Erfahrung heraus für die Versionsverwaltung geeignet sind.
    Gerne auch in Bezug auf Cloud vs Non-Cloud.

  2. #2
    Projektleitung
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    4.058
    Thanked 8.488 Times in 2.531 Posts
    Blog Entries
    5

    Standard AW: Versionsverwaltung für C# und bash

    Erst mal würde ich grundsätzlich differenzieren zwischen
    1. Versionsverwaltungssystem
    2. Einem dazu passenden Server zur zentralen Speicherung
    3. Dem Ort, wo das gehostet wird (On-Prem/Cloud)

    1. Versionsverwaltung
    Git hat sich als verteilte Versionverwaltung für die meisten textbasierten Formate durchgesetzt. Egal ob C#, Python, Go, Bash oder Konfigurationsdateien von Ansible für Infrastructure-as-Code. Die Offenheit, dezentrale Versionierung mit Branching/Merging und Performance sind die Stärken von Git. Es wurde ursprünglich für den Linux Kernel entwickelt, da reden wir beim 4er Kernel von über 25 Mio. Codezeilen. Das coole daran ist: Es kann in einem lokalen 1-Personen Repo genau so gut genutzt werden wie im Team mit 5, 50 oder 100 Leuten.

    Dementsprechend brauchst du Punkt 2 und 3 gar nicht zwingend, wenn nur du an dem Projekt arbeitest. Dennoch empfiehlt es sich auch dort, schon alleine als Mini-Sicherung. Ganz abgesehen von CI/CD. Hast du Git bereits genutzt und Probleme festgestellt, oder aus welchem Grunde suchst du Alternativen? Viele aktiv gewartete gibt es da in meinen Augen nicht, die auf Augenhöhe liegen bzw. sogar Vorteile gegenüber Git aufweisen: Subversion und TFS (neumodisch Azure DevOps Server) sind nach Git mit weitem Abstand die am häufigst genutzten Alternativen (Quelle: Stack Overflow Developer-Umfrage von 2018).

    Beide sind aber nicht dezentral, was ich spätestens im Team als großen Nachteil sehe: Du commitest was fehlerhaftes, die Software geht kaputt und 10 andere Entwickler im Team können nicht mehr arbeiten. Oder du bist unterwegs, hast kein Netz, kannst nicht arbeiten. Mit Git sind beide Konstellationen kein Problem (vernünftige Struktur vorausgesetzt natürlich).

    Dazu kommt beim TFS, dass es proprietäre Software ist, die zudem nur auf Windows läuft. Wenn proprietäre Software in Frage kommt, hast du immerhin noch entsprechende Lizenzkosten für TFS (mittlerweile Freemium, ab 5 Usern kostets), einen MSSQL Server (mit Einschränkungen für kleinere Projekte kostenfrei) sowie einen Windows-Server. Einen IIS fürs Web-UI braucht der auch noch und somit ebenfalls entsprechende User-CALs, wenn man alles richtig Lizenzieren will. Kurzum: Es wird wie bei MS üblich kompliziert und spätestens mit ein paar Usern auch sehr schnell sehr teuer. Alternativ gibt es das ganze natürlich auch in der Cloud, mit den üblichen Risiken und Einschränkungen (Internetverbindung, keine Kontrolle, Datenschutz, Kosten etc). Wenn da Azure mal wieder abraucht, ist halt Pause.

    Dann gibts noch Mercurial, das recht ähnlich zu Git ist. Hab es vor 2 oder 3 Jahren mal genutzt, mein Eindruck: Großteils gleich, ein paar Detailunterschiede, in denen Git führend war. Besitzt aber eine vergleichsweise geringe Verbreitung, sehe keinen Grund, das Git vorzuziehen. Ansonsten unterscheiden sich die Systeme generell etwas im Detail, das würde den Rahmen aber bei weitem sprengen und ist in deiner Situation großteils auch sicher irrelevant.

    Zusammenfassend kann man sagen: Git ist da nicht umsonst zum quasi Standard geworden. Ich nutze das seit Jahren mit verschiedenen Stacks und Frameworks ohne Probleme. Einziger Nachteil den man fairerweise sagen muss: Es ist für Anfänger anfangs etwas komplex. Hat man das Konzept aber mal verstanden, ist es ein tolles Werkzeug. Das lohnt sich, weil Git eben so universell einsetzbar ist und auch breit genutzt wird. Wenn du z.B. an einem OS Projekt mitwirken möchtest oder sogar selbst deine Projekte OS stellst, bist du direkt "drin" und musst nicht umlernen.

    2. Server
    Wie schon oben angesprochen, brauchst du den nur bei zentralen Versionsverwaltungen wie z.B. TFS zwingend. Nutzt du Git oder ein anderes dezentrales System, ist der optional (abgesehen von Teamarbeit). Bei Git hast du da wieder den Vorteil, dass es eine recht große Auswahl an offenen Systemen gibt: Von Gogs, dass selbst auf einem 3er Raspberry brauchbar läuft, bis hin zu GitLab, was mittlerweile noch 99 andere Tools (vor allem CI/CD) vereint. Beide hab ich im Einsatz, für ihren Zweck ebenfalls tolle Projekte. Gogs (Gitea ist btw recht ähnlich) kann man recht einfach zum Laufen bringen, besitzt aber durchaus aus Features für mittelgroße Umgebungen wie z.B. LDAP-Authentifizierung. Und ein paar grundlegende Tools wie Tickets oder Wiki. Für den Einstieg, grade bei begrenzten Ressourcen, keine schlechte Wahl.

    An GitLab wiederum wird das Gesamtpaket interessant. Das Hosting von Git-Repos ist da nur eine Komponente von vielen. GitLab kann von CI/CD, Tickets, Zeitverwaltung, Integration diverser Tools wie Mattermost, Kanban-Board, diverse Auswertungen bis hin zur Docker/Kubernetes Integration nahezu alles, was man heutzutage zur professionellen Verwaltung des Lebenszykluses von Software braucht, plus diverse Spielereien die je nach Anwendungsfall durchaus nützlich sein können.

    Wobei das nicht heißt, dass man dafür zwingend GitLab braucht. Du kannst an Gogs beispielsweise auch einen Jenkins und je nach Level auch diverse weitere Tools wie z.B. SonarQube dran hängen, die am Ende das selbe Ziel verfolgen. Ist halt auch immer die Frage, was genau gemacht werden soll und was dafür Sinn macht. Wenn es wirklich nur um ein paar Skripte und Codezeilen geht, ist so eine Umgebung sicher overkill. Da reicht auch ein kleines Gogs, evtl. nicht mal CI/CD. Für U-Labs will ich das definitiv nicht mehr von Hand machen wollen. Da wird bei einem Push automatisch ein Docker-Image gebaut, aufs entsprechende System deployt, Configs ausgetauscht usw. Alleine schon die Tests sind bei so einem Projekt mittel- bis langfristig nicht mehr händisch Händelbar, zumindest nicht für eine vernünftige Softwarequalität.

    3. Hosting
    Grundsätzlich gibt es viele Versionsverwaltungssysteme sowohl On Prem als auch irgendwo in der Cloud. Bei Git hat man sogar die Auswahl zwischen verschiedenen Plattformen (z.B. GitHub und GitLab). Im Prinzip hängt das von 4 Faktoren ab - nämlich was man sich hinsichtlich Unabhängigkeit, Erreichbarkeit, Sicherheit/Datenschutz und ggf. auch Wartungsaufwand vorstellt. Grundsätzlich würde ich mir die Frage stellen, ob OS entwickelt wird oder noch closed. Wenn OS, macht ein gehosteter Dienst (v.a. GitHub/GitLab) am meisten Sinn: Da ist die Community und du findest am ehesten andere Entwickler, die am Projekt mitwirken. Klar kann man auch das selbst hosten. Dann muss jeder sich auf dem System anmelden, macht imho wenig Sinn. Sicherheit und Datenschutz ist da dann auch zweitrangig, wenn der Quellcode frei verfügbar ist.

    Entwickelst du proprietär, sieht es schon anders aus. Da stellt sich eher die umgekehrte Frage: Warum sollte das auf fremden Servern gehostet werden? Du wirst abhängig und verlierst die Kontrolle. Als Vorteil musst du dich dabei um nichts kümmern. Der Aufwand einer selbst gehosteten Instanz ist keine Mammut-Aufgabe. Natürlich sollte man dafür grundlegende administrative Fähigkeiten beherrschen. Sonst ist es am Ende sinnvoller, das professionell betreuen zu lassen und dafür ggf. ein paar Euro zu bezahlen. Die Dimension hängt wieder von Größe und Zielgruppe ab. Für was kleineres reicht evtl. auch ein kleiner Raspberry, der bei dir zuhause nebenbei läuft und nicht viel mehr kostet als ein paar Euro Strom im Jahr.

    Ein Vorteil an Git ist, dass du damit nicht auf ewig gebunden bist. Du kannst auch im Nachhinein dein Projekt z.B. von einem lokalen Gogs auf GitHub legen. So lange du Best Practices befolgst und z.B. keine sensiblen gültigen Zugangsdaten in der Historie hast, ist das problemlos möglich. Es ist also nicht so, dass du dich auf ewig festlegen musst.
    Wenn du noch ganz am Anfang stehst, evtl wenig bis gar keine Erfahrung mit Git hast und dein Projekt nichts sensibles beinhaltet: Dann würde ich an deiner Stelle für den schnellen Start einfach mal ein GitHub-Repo anlegen. Die privaten Repos sind dort mittlerweile auch kostenfrei, sodass du hier für den Anfang recht schnell und preiswert beginnen kannst. So kannst du anfangen erste Erfahrungen zu sammeln und dir dann später über was eigenes/umfangreicheres Gedanken machen.


  3. The Following 3 Users Say Thank You to DMW007 For This Useful Post:

    AFU (07.09.2019), Negok (17.09.2019), raspberry (09.09.2019)

  4. #3
    AFU
    AFU ist offline
    U-Labs Routinier
    Avatar von AFU
    Registriert seit
    19.11.2011
    Beiträge
    354
    Thanked 72 Times in 59 Posts

    Standard AW: Versionsverwaltung für C# und bash

    Also ich habe bis her mit SVN gearbeitet, das Prinzip ist mir klar. GIT hat ein lokales Repo, das ist ganz anders, soviel habe ich schon festgestellt.
    Ich brauche das nur Repo nur für mich, weder OS noch proprietär, nennen wir es Hobby.
    Ich möchte nicht, dass der Code bei Git Public ist. Nennen wir es ein eigenes Repo, unabhängig von Cloud-Diensten wir gitlab oder github. Ich hätte gerne eine Variante, wo die Versionierung als Cloud-Speicher über Dropbox läuft.
    Warum Dropbox? Da ich den Code von zuhause und von der Firma aus bearbeiten möchte.

  5. #4
    Projektleitung
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    4.058
    Thanked 8.488 Times in 2.531 Posts
    Blog Entries
    5

    Standard AW: Versionsverwaltung für C# und bash

    Dropbox würde ich heutzutage grundsätzlich keine Daten mehr anvertrauen, unabhängig davon. Die Begründung, keine Cloud-Dienste nutzen zu wollen aber dann die Daten in Dropbox zu legen, widerspricht sich zudem. Letztendlich sind das ja beides nichts anderes als Cloud-Anbieter, nur eben der eine mit Fokus auf Dateien, der andere auf Softwareprojekte. Ob die nun auf GitHub oder Dropbox legen, spielt abgesehen von der Usability am Ende keine Rolle. Beide liegen in den USA und sind damit den vergleichsweise schlechten Datenschutzbedingungen sowie der Willkür der US-Regierung (National Security Letter, Gag Order, Cloud Act usw) ausgesetzt. In beide würde ich daher bestenfalls öffentliche Dinge ablegen.

    Aber du hast scheinbar das Prinzip der verteilten Versionsverwaltung noch nicht ganz verstanden. Der Sinn dahinter ist ja, dass der Code eben nicht mehr übers Dateisystem geteilt werden muss. Das verursacht z.B. Probleme beim Überschreiben von Konflikt-Dateien. Bei einem Cloud-Account der nur von einer Person genutzt wird, ist das weniger kritisch wie bei einem Netzlaufwerk mit 5 Entwicklern. Dennoch kann dir auch da was verloren gehen. Reicht ja schon, wenn die Synchronisation mal nicht funktioniert und du währenddessen lokale Änderungen vornimmst. Oder vergisst auf PC B zu speichern, auf PC A was änderst und dann später auf B speicherst. Rein technisch könntest du durchaus ein lokales Git-Repo anlegen und das in irgend eine Cloud legen. Ist aber eben aus diesen Gründen nicht zu empfehlen, weil es schlicht das falsche System ist.

    Für den Zweck ist Punkt 2 aus meinem obigen Beitrag da: Du hast entweder ein selbstgehostetes Gogs, Gitlab, XY oder ein Repo bei einem Fremdanbieter wie GitHub, GitLab etc .Auch wenn OS auf GitHub bevorzugt wird, kannst du das Repo auf Wunsch auch Privat stellen. Alle deine Clients pushen ihren Code dort hin - egal ob Privater PC, Laptop, Geschäfts-PC etc. Durch Pullen stellst du sicher, dass jeweils der aktuelle Stand vorhanden ist. Solltest du doch mal widersprüchliche Änderungen haben, gibt es einen Merge-Konflikt. Da entscheidest du dann im Zweifel selbst, welche Version ins Server-Repo gepusht werden soll.

    Bei der Mischung von Privat und geschäftlichem Code wäre ich aber vorsichtig: Was du während der Arbeitszeit erstellst (Anwendungen, Skripte etc) ist Eigentum des AG. Wenn du das außerhalb der Arbeit nutzen möchtest, sollte das vorher mit dem Chef entsprechend vereinbart werden, um Probleme zu vermeiden.


  6. The Following 3 Users Say Thank You to DMW007 For This Useful Post:

    AFU (07.09.2019), Darkfield (08.09.2019), raspberry (09.09.2019)

Ähnliche Themen

  1. bash: lsb_release: command not found
    Von TomatenKetchup im Forum Server-Administration
    Antworten: 2
    Letzter Beitrag: 24.12.2013, 19:27
  2. Bash TS3-Server Skript (start/stop/restart)
    Von Snees im Forum Shellprogrammierung
    Antworten: 0
    Letzter Beitrag: 06.07.2013, 16:18
  3. [Bash] Crawl Nicks
    Von Ta1lor im Forum Shellprogrammierung
    Antworten: 0
    Letzter Beitrag: 10.02.2012, 21:24
  4. [Bash] Vbulletin Login
    Von Ta1lor im Forum Showroom
    Antworten: 0
    Letzter Beitrag: 18.10.2011, 18:01
  5. [Bash] Bukkit update
    Von Ta1lor im Forum Showroom
    Antworten: 0
    Letzter Beitrag: 16.10.2011, 21:05
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191