Arbeiten im Team

[Captnemo]

Hi,

dieses Thema ist für mich absolutes Neuland, da ich bisher entweder immer nur allein an einem Projekt gearbeitet habe, oder es so war, dass ein Projekt in unterschiedliche Teilprojekt zerlegt wurde.

Jetzt ergibt sich aber das Problem, dass verschiedene Programmierer, an verschiedenen Standorten zu verschiedenen Zeiten am gleichen Projekt arbeiten müssen. Daraus ergeben sich folgende Notwendigkeiten:

- Der Quellcode muss irgendwo gehostet werden (hier würde sich ein eigener FTP-Server anbieten)
- Wenn ein Programmiere arbeitet, oder mit der Arbeit beginnt, sollte er einen Hinweis erhalten, wenn andere bereits am Projekt arbeiten, oder mit der Arbeit beginnen
- Änderungen im Quellcode sollte zusammenfließen. Heißt, wenn 2 Leute in der gleichen Datei Veränderungen vorgenommen haben, sollten beide Änderungen erhalten bleiben. (Sicherlich gibt es auch Konflikte, die dann gelöst werden müssen)
- Man sollte eine Datei "sperren" können, so dass andere sehen können, dass an dieser Datei gerade umfangreiche Änderungen vorgenommen werden.
- Und das wichtigste, das ganze sollte sich in Delphi (am besten XE7) integrieren lassen

Möglicherweise würden wir uns dafür auch was eigenes Programmieren, aber ich denke es müsste dafür doch schon gute, intelligente Lösungen geben (die auch bedienbar sind). Wäre auch schön wenn's dann nicht soviel kostet.

Bitte nicht gleich steinigen, wie gesagt, das ist für mich Neuland (So wie das Internet für unsere Bundeskanzlerin) und ich habe noch keine genauen Vorstellungen, wie ich das am Besten löse und welche Problem ich damit noch bekomme.

[Union]

Da würde sich die Einrichtung eines zentralen SVN Servers anbieten.

[Captnemo]

Ja, aber welchen sollte man sich genauer anschauen?
Gibt es irgendwo deutschsprachige Anleitungen, wie man das in Delphi integrieren kann (oder läuft sowas immer außerhalb der IDE ab), und welche Möglichkeiten man alles hat (bezogen auf meine Punkte im ersten post)?

[Klaus01]

Hallo Dieter,

einige Deiner Punkte werden in dem SVN-Buch behandelt.

Grüße
Klaus

[Captnemo]

Kennt jemand VisualSVN? Taugt das was? Kann ich dass direkt mit Delphi-Versionskontrollsystem verwenden, oder benötigt man dazu noch einen SVN-Client oder irgendwas für die IDE?

[Lemmy]

Hast Du noch nie mit Versionskontrollsystemen (SVN, Git,...) gearbeitet? Wie schaut das in deinem Team aus? Gibt es da welche die schon mit einem System gearbeitet haben?

VisualSVN habe ich noch nie benutzt, die SVN-Integration in Delphi bisher nur sehr wenig, bisher habe ich http://tortoisesvn.net/ verwendet, bin inzwishen aber auf git umgestiegen.

zu den restlichen Punkten: Vergiss deinen ftp-Server wieder ganz schnell.

Zitat:

Wenn ein Programmiere arbeitet, oder mit der Arbeit beginnt, sollte er einen Hinweis erhalten, wenn andere bereits am Projekt arbeiten, oder mit der Arbeit beginnen

Dazu gibt es eine Projektplanung und Absprachen an die man sich halten könnte - kleine gemeinsame Änderungen an Dateien kann das Versionskontrollsystem matchen bzw. einen KOnflikt aufzeigen. Für die sonstige Zusammenarbeit sind direkte KOmmunikation (z.B. Jabber-Messanger) und wie schon angesprochen eine Projektplanung sinnvoll... Ich nutze inzwischen für mich Redmine und das aus der Box (http://www.turnkeylinux.org/redmine) d.h. wenn Du einen ESXi-Server irgend wo laufen hast, dann kannst Du das Teil ohne großen Aufwand nutzen. Projekt anlegen, Repository anlegen und los gehts. Im enthaltenen Wiki lässt sich alles dokumentieren und dient als Dokumentationsablage für die gemeinsame Entwicklung, im Ticketsystem das ganze sauber in Arbeitspakete zerlegen und umsetzen. Und per Tags in den Beschreibungen zu den commits kannst Du auf Tickets verweisen oder diese schließen, so dass man später auch darüber Änderungen gut verfolgen kann.

Grüße

[mkinzler]

VisualSVN ist eine SVN Server und sollte daher direkt aus der IDE ansprechbar sein.

[Sherlock]

Bevor das hier ausartet: SVN würde ich eben nicht empfehlen. Versuch es mit einem der modernen verteilten VCS, also sowas wie mercurial oder git. Gerade in Teams, wo eventuell gleichzeitig an den gleichen Units gearbeitet wird spielen die DVCS ihre Stärken locker flockig aus. Zur Vertiefung kannst Du hier im Forum schon nach entsprechenden Threads bezüglich Einführung in mercurial oder git suchen.

Sherlock

[jobo]

Hab auch keine guten Erfahrungen mit SVN, besonders wenn ein Teilnehmer nicht richtig breitbandmäßig unterwegs ist bzw. das Repo sehr groß wird. (Ergibt korrupte Repo DB, blöd)
("sehr groß" bedeutet leider auch, dass SVN (oder andere) gern mal für nicht-source-code genutzt wird, dafür sind die Tools nicht gemacht)
Lieber git. Geht notfalls nackig per Command line oder auch mit Oberfläche (die können dann kosten). Für Tickets >Trac, das kann >git integrieren mit Commit Historie, Diff usw. Für Chat >openfire und >Pidgin oder so.
Ein Chat ist praktisch, wenn man aus der Ferne ein Push/Pull, branch, .. abstimmen will. Bei kleinen Arbeitspaketen aber glaub ich gar nicht so dramatisch. (oder auch mal ein Stück Source Code, XML oder einen Bilderwitz rumschickt..)
Eine AllinOne Lösung ist sicher praktisch, hab vor 2 Jahren noch etwas gebastelt, bis es wie gewünscht zusammen lief.

[TheMiller]

Moin!

War für mich auch Neuland. Ich mache es jetzt seit einiger Zeit so:

Ich habe mir einen virtuellen Server gemietet (bei 1und1). Dort habe ich alle Zugänge gesperrt (ssh, ftp, web etc.pp.) und nur noch für das VPN-Netz freigegeben. D.h., wenn ich mit VPN mit dem Server verbunden bin, kann ich per ssh, web, etc. auf ihn zugreifen.

Dort habe ich virtuelle Hosts angelegt, einen für GitLab (kostenfreier, offener Clone von GitHub (Versionsverwaltungssystem)). Dann pro WebProjekt einen eigenen virtuellen Host (http://meineDomain1.vpnonly). Die Config wird durch OpenVPN an meinen Windows-Client weitergegeben, sodass Windows weiß, dass es bei Eingabe dieser Domain auf den virtuellen Server routen muss.

D.h., dass ich beim Programmieren mit VPN Verbunden bin um die aktuellen Quelltexte als lokale Arbeitskopie auszuchecken. Dann programmiere ich - egal ob Delphi oder Webprogrammierung. Für Web hab ich natürlich eine portable XAMPP-Installation, mit eigenen lokalen VHosts zum Testen.

Während des Programmierens muss ich nicht mit dem Server per VPN verbunden sein. Nur dann, wenn ich mit mit der Arbeit (oder einem Teil) fertig bin. Dann "committe" und "pushe" ich die Änderungen an den GitLab-Server (virtuellen Server). Andere Programmierer können diese Daten wieder auschecken oder sie werden bei ihnen automatisch geladen. Je nachdem.

Installiert werden muss auf dem virtuellen Server: Apache, MySQL, GitLab, GitLabShell etc., OpenVPN, RSync (zur Datensicherung). Das war's eigentlich schon. Der Server ist günstig zu haben, da nicht viele Ressourcen benötigt werden.

GitLab dient auch gut als "Datensicherung" der Quelltexte. Nichtsdestotrotz solltest du die Daten über VPN nachts oder wann auch immer regelmäßig mit RSync mit einem PC in deinem Netzwerk synchronisieren. Ein Image des Servers wäre aber noch besser. Das machen aber die meisten Hoster schon ab Werk, je nach Vertrag. Bei meinen 7€-Vertrag habe ich eine automatische IMage-Sicherung dabei.

Ich hoffe, ich konnte dir ein wenig helfen!

[vagtler]

Wenn es nicht mehr als 5 Benutzer sind, bietet sich auch https://bitbucket.org/plans/ an, wo ich ein Git-Hosting mit privaten Repositories kostenfrei erhalte.

[Perlsau]

Da hätt ich doch mal eine Frage, die mich immer wieder mal kurz beschäftigt, obwohl ich selber ja nur lokal als einziger an meinen Projekten arbeite:

Wie wird das mit GIT gehandhabt, wenn zwei oder mehr Entwickler dieselbe Unit bearbeiten? Sperren, wie Captnemo das oben andeutet, ist ja mit GIT nicht möglich, weil man ja offline am lokalen Repository arbeitet. Das kann (oder muß) doch zu Konflikten führen, wenn die Bearbeitung derselben Pas-Datei vorher nicht genau abgesprochen wurde. Sollte man das zeitgleiche Bearbeiten derselben Datei durch verschiedene Programmierer dann nicht eher vermeiden?

[TheMiller]

Der Vorteil gegenüber einer eigenen privaten Lösung ist der, dass die Quelltexte keinem anderen Unternehmen in Amerika und Co. anvertraut werden. Natürlich muss der eigene Server dann relativ sicher sein. Es empfiehlt sich dann auch, keine Domain dafür zu registrieren, sondern es bei der Standard-Hostindomain "[e-mail]" (wie auch immer) zu belassen.

Lokal brauchst du dann übrigens einen GitClient zB SourceTree. Sehr und und kostenlos.

[TheMiller]

Git führt die Dateien per Diff zusammen. Bei Konflikten kann man alles selbst bestimmen, welche Version übernommen wird. In der Regel kommt es aber nicht zu Problemen, da diff beide Dateien zu einer zusammenführt.

[Perlsau]

Zitat:

Zitat von DJ-SPM (Beitrag 1292465)

Git führt die Dateien per Diff zusammen. Bei Konflikten kann man alles selbst bestimmen, welche Version übernommen wird. In der Regel kommt es aber nicht zu Problemen, da diff beide Dateien zu einer zusammenführt.

Ich meinte auch nicht Konflikte beim Committen, sondern für das Projekt selbst: Wenn sich z.B. der eine Entwickler auf einen Methode bezieht, deren Parameter der andere Programmierer geändert hat, dann läßt sich das Projekt doch gar nicht mehr kompilieren.

[TheMiller]

Das liegt ja in der Natur der Sache. Da muss man halt entweder feste Bereiche definieren, wer wo programmieren darf, die anderen im Wiki benachrichtigen oder eben neue Methoden via overload deklarieren.

[Perlsau]

Okay, danke für die Bestätigung, so hab ich mir das auch zusammengereimt, wollte es aber mangels eigener Erfahrung mal von jemand anderem hören/lesen :thumb:

[Neutral General]

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.
Ich weiß nicht wie das bei GIT ist aber in SVN kann man auch Dateien blockieren. Diese können dann solange nicht von anderen commited werden solange die Datei blockiert ist.
Ansonsten kann GIT/SVN meistens die Arbeit der beiden Personen mergen, wenn sie nicht wirklich an exakt der gleichen Stelle Sachen hinzugefügt/geändert haben.

Und ein wenig Absprache sollte/muss sowieso vorhanden sein. Wenn jeder nur sein Ding durchzieht ohne Absprache wird das natürlich nichts.

[Lemmy]

Zitat:

Zitat von Neutral General (Beitrag 1292469)

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.

Arbeiten an einer Unit sind unproblematisch (zumindest mit git und co) - abreiten mehrere an der selben Zeile kann das kein VCS richtig zusammen bringen.

Eine Sperre in git kann es nciht geben, da es keinen zentralen Server gibt, der das regeln könnte - lokale Arbeitsbranches könnten damit eh nicht "erschlagen" werden.

[jobo]

Zitat:

Zitat von Perlsau (Beitrag 1292466)

Wenn sich z.B. der eine Entwickler auf einen Methode bezieht, deren Parameter der andere Programmierer geändert hat, dann läßt sich das Projekt doch gar nicht mehr kompilieren.

Der Austausch der geänderten (commited) Dateien erfolgt erstmal nicht automatisch. Wenn irgendein Entwickler irgendeinen (auch speziellen) Stand vom Github oder so (auch dem eigenen Source Server) gezogen hat, kann er jahrelang dagegen arbeiten, weil er selbst gegen eine lokale Kopie arbeitet. Was andere Entwickler machen, interessiert also nicht direkt.
Erst wenn man Aktualisierungen (z.B. die neueste) oder ein bestimmten Stand oder Branch anfordert, wird das lokale Repository geändert.
Man muss sich mit der Arbeitsweise etwas umgewöhnen. Vor Jahren, habe ich immer Zwischenstände in anderen Verzeichnissen gesichert und all sowas (oder die Krise gekriegt mit VSS). Das muss man so nicht mehr machen. Man kann Schritt für Schritt committen, hochladen, runterladen, "vor- und zurückspulen" oder Branches anlegen, wenn man neue Interfaceversionen beginnt.
Im Prinzip arbeitet man immer mit 2 Source "Versionierern", dem (entfernten) Server und dem lokalen Abbild. Beide halten immer alle Versionen, zumindest der Server und man bestimmt, welche Variante im Projektverzeichnis bearbeitet wird oder auf den Server geschrieben wird.

[Neutral General]

Zitat:

Zitat von Lemmy (Beitrag 1292471)

Zitat:

Zitat von Neutral General (Beitrag 1292469)

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.

Arbeiten an einer Unit sind unproblematisch (zumindest mit git und co) - abreiten mehrere an der selben Zeile kann das kein VCS richtig zusammen bringen.

hab ich doch gesagt ;)

Zitat:

Zitat von Neutral General

Ansonsten kann GIT/SVN meistens die Arbeit der beiden Personen mergen, wenn sie nicht wirklich an exakt der gleichen Stelle Sachen hinzugefügt/geändert haben.

[TheMiller]

Zitat:

Zitat von Neutral General

hab ich doch gesagt ;)

Ich auch :lol:

[Lemmy]

Zitat:

Zitat von Neutral General (Beitrag 1292473)

Zitat:

Zitat von Lemmy (Beitrag 1292471)

Zitat:

Zitat von Neutral General (Beitrag 1292469)

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.

Arbeiten an einer Unit sind unproblematisch (zumindest mit git und co) - abreiten mehrere an der selben Zeile kann das kein VCS richtig zusammen bringen.

hab ich doch gesagt ;)

mit der Einschränkung, dass bei meinem "und co" kein SVN (mehr) enthalten ist. ;-)

[vagtler]

Zitat:

Zitat von DJ-SPM (Beitrag 1292464)

Der Vorteil gegenüber einer eigenen privaten Lösung ist der, dass die Quelltexte keinem anderen Unternehmen in Amerika und Co. anvertraut werden. Natürlich muss der eigene Server dann relativ sicher sein. [...]

"German Angst"?

Und Du glaubst wirklich, dass ein von Dir selbst betriebener Server es sicherheitstechnisch auch nur annähernd mit einem darauf spezialisierten Unternehmen, das genau davon lebt aufnehmen kann?

Aber natürlich sind Deine weltverändernden, bahnbrechenden Geheimalgorithmen auf einem virtuellen deutschen Massenhoster-Server sicherer.

http://programmers.stackexchange.com...ub-or-bitbucke

Zitat:

[...] Es empfiehlt sich dann auch, keine Domain dafür zu registrieren, sondern es bei der Standard-Hostindomain "[e-mail]" (wie auch immer) zu belassen. [...]

Klar, das Fehlen einer Domain für einen Server macht den Server selbst sicherer.

Zitat:

[...] Lokal brauchst du dann übrigens einen GitClient zB SourceTree. Sehr und und kostenlos.

VORSICHT! SourceTree ist von den Machern von BitBucket. Wie kannst Du sicher sein, dass die nicht ganz klammheimlich Deinen Quellcode mitlesen? Sind doch ein Unternehmen aus "Amerika und Co."(Australien zähle ich jetzt mal zu Co.).

[Perlsau]

Zitat:

Zitat von vagtler (Beitrag 1292485)

"German Angst"?

Begründete Angst, und nicht nur in Germany:

• Ehemaliger NSA-Technikchef bestätigt amerikanische Industriespionage
• Industriespionage mit NSA-Daten möglich
• Vorsprung durch Spionage
• USA betreiben ohne Zweifel Wirtschaftsspionage
• Edward Snowden wirft NSA Industriespionage vor
• Studie Industriespionage 2014 (96 Seiten)
• USA saugen bei deutschen Unternehmen Know-How ab
• Ja, meine Freunde, wir spionieren euch aus

Google liefert ungefähr 22.700 Ergebnisse für nsa+industriespionage – alles "Verschwörungstheorie"?

[vagtler]

Zitat:

Zitat von Perlsau (Beitrag 1292491)

[...] Begründete Angst, und nicht nur in Germany: [...]

Nö. Bitte nochmal lesen. Ich rede nicht von (begründeter oder unbegründeter) Angst vor Industriespionage. Ich rede von der Angst vor dem Mitlesen des ach so wahnsinnig geheimen Quellcodes, der für sich gesehen so gut wie keinen Wert hat: http://articles.marco.org/260

Das ist übrigens auch ein Grund, warum manche Unternehmen ihren Kunden vollständigen Zugriff auf den Quellcode ihrer Produkte gewähren. Atlassian z.B. ist ein Beispiel dafür.

Wieso glauben viele - vor allem deutsche? - Unternehmen eigentlich, dass das Vermögen im Quellcode liegt? Der Mitarbeiter, der sein Wissen gegen Cash viel effektiver an den Mitbewerber weitergeben könnte, der wird nicht so umhegt und gepflegt.

[Lemmy]

Zitat:

Zitat von vagtler (Beitrag 1292495)

Zitat:

Zitat von Perlsau (Beitrag 1292491)

[...] Begründete Angst, und nicht nur in Germany: [...]

Nö. Bitte nochmal lesen. Ich rede nicht von (begründeter oder unbegründeter) Angst vor Industriespionage. Ich rede von der Angst vor dem Mitlesen des ach so wahnsinnig geheimen Quellcodes, der für sich gesehen so gut wie keinen Wert hat: http://articles.marco.org/260

vor dem Mitlesen hätte ich jetzt auch keine so große Angst (beim Quellcode), allerdings schon eher, dass sich jemand die Sourcen besorgt und damit zu meinem Auftraggeber marschiert und der mich in Grund und Boden verklagt... Und dann kannst Du lange und breit erklären, dass der Quellcode für sich keinen großen Wert hat - wird niemanden interessieren...

[vagtler]

Klar kann man jedes Horrorszenario herbeidiskutieren. Ich bleibe aber dabei: ich halte ein Git-Hosting bei darauf spezialisierten (und vor allem davon lebenden) Anbietern nicht per se für unsicherer als auf einem virtuellen Server eines Massenhosters.

Ich kann mich an einen Fall bei einem unserer (früheren) Provider erinnern, wo auf Grund einer Fehlkonfiguration alle Ressourcen (also auch Festplatten) für alle Guests eines Hosts sichtbar waren. Der Fehler wurde erst nach Monaten bemerkt.

Oder wie viele VPN- oder SSH.Credentials mittels - natürlich unverschlüsselter - Email versendet werden.

Oder wie viele Festplatten in Firmen-Notebooks unverschlüsselt sind.

In unserer Firma kommen im Jahr ca. 5 Notebooks mit sensiblen Daten verlustig. Wenn die Daten darauf nicht hinreichend verschlüsselt wären, dann würde ich nervös werden. Aber doch nicht, weil ich meine Quellcodes auf BitBucket hoste.

[Perlsau]

Zitat:

Zitat von vagtler (Beitrag 1292506)

Aber doch nicht, weil ich meine Quellcodes auf BitBucket hoste.

Nehmen wir mal an, du entwickelst in jahrelanger Kleinarbeit eine Anwendung bis zur Marktreife und hoffst nun, Käufer zu finden, um davon leben zu können, verfügst aber nicht über ausreichende Mittel, um im großen Stil dafür zu werben. Inzwischen hat eine darauf spezialisierte Firma die Marktreife deines Produkts erkannt, sich die Sourcen via illegalem NSA-Kontakt* besorgt, das Ding kompiliert und via aufwendiger Produktreklame zigtausendfach verkauft, und zwar zu einem geringeren Preis, als du es auf deiner Firmenhomepage anbietest. Du kannst jetzt nicht einmal mehr beweisen, daß es sich um deine Sourcen handelt.

* Es ist bekannt, daß die NSA regelmäßig amerikanische Firmen dazu zwingt, Daten oder Keys an die NSA herauszugeben, und im Prinzp keine amerikanische Firma davor geschützt ist. Es wird auch vermutet, daß zahlreiche amerikanische Softwareprodukte über "Hintertüren" verfügen, um amerikanische Industriespionage zu ermöglichen.

[JasonDX]

Zitat:

Zitat von vagtler (Beitrag 1292506)

Klar kann man jedes Horrorszenario herbeidiskutieren. Ich bleibe aber dabei: ich halte ein Git-Hosting bei darauf spezialisierten (und vor allem davon lebenden) Anbietern nicht per se für unsicherer als auf einem virtuellen Server eines Massenhosters.

Wenn man einen Anbieter zum hosten nimmt, dann ist immer besser, einen darauf spezialisierten Anbieter zu nehmen. Aus den von dir genannten Gründen. Aber: sobald du etwas bei einem Anbieter hostest, hast du im Bezug zu geschütztem Zugriff lediglich die Sicherheit, dass min. eine staatliche Institution Zugriff darauf hat. Woauchimmer der Server steht, das Land hat mit höchster Wahrscheinlichkeit die Möglichkeit, an die Daten dort zu kommen. Das beschränkt sich nicht nur auf die USA. Ich würde sensible Daten weder dort, noch in Russland, China, Korea oder Deutschland horten.
Ob sich der Aufwand für einen privaten Server bei Quellcode lohnt, hängt davon ab, was die Anwendung machen soll, bzw. wie hoch das Risiko für Angriffe ist. Kurz gesagt muss der Aufwand für einen erfolgreichen Angriff größer sein als der Nutzen davon.

Edit:

Zitat:

Zitat von Perlsau (Beitrag 1292513)

* Es ist bekannt, daß die NSA regelmäßig amerikanische Firmen dazu zwingt, Daten oder Keys an die NSA herauszugeben, und im Prinzp keine amerikanische Firma davor geschützt ist. Es wird auch vermutet, daß zahlreiche amerikanische Softwareprodukte über "Hintertüren" verfügen, um amerikanische Industriespionage zu ermöglichen.

Es wird auch gemunkelt, dass im Bezug auf Zugriff von Daten bei Hostern die Deutschen nicht besser sind... Wenn du auf dem Level von Vorsicht bist, ist ein Online-Hoster raus aus der Diskussion.

[Neutral General]

Wenn ich wirklich etwas entwickel was ich später verkaufen möchte dann würde ich den Code auch niemals auf fremden Servern hosten. Schon gar nicht wenn Leute meinen Source sehen/runterladen können. Da ist ein eigener SVN/GIT Server auf einem (V-)Server wahrscheinlich sicherer, oder man baut sich lokal ein kleines System im Heimnetzwerk.

[vagtler]

Zitat:

Zitat von Perlsau (Beitrag 1292513)

[...] Inzwischen hat eine darauf spezialisierte Firma die Marktreife deines Produkts erkannt, sich die Sourcen via illegalem NSA-Kontakt* besorgt, [...]

Mal abgesehen davon, dass die NSA bestimmt leichter an die Daten eines virtuellen Servers eines deutschen Massenhosters als eines australischen, darauf spezialisierten Produkthosters kommt.

Zitat:

[...] das Ding kompiliert und via aufwendiger Produktreklame zigtausendfach verkauft, [...] Du kannst jetzt nicht einmal mehr beweisen, daß es sich um deine Sourcen handelt. [...]

Sollte sich der Sachverhalt derart darstellen, dann kann die Schöpfungshöhe nicht gewaltig gewesen sein (keine Patente oder sonstige Schutzmaßnahmen vorhanden). Und dann stelle ich mir die Frage, ob jemand sich dann wirklich die fragwürdige Mühe macht, sich auf illegalem Wege Deine Quellen zu besorgen (was immer ein gewisses Risiko birgt und auch nicht ganz billig sein dürfte) oder er die fragliche Funktionalität nicht in einem Niedriglohnland einfach neu entwickeln lässt.

Zitat:

[...]* Es ist bekannt, daß die NSA [...]

Nur um das noch einmal zu betonen: wir reden hier von Australien.

Zitat:

Zitat von JasonDX (Beitrag 1292516)

[...] Wenn du auf dem Level von Vorsicht bist, ist ein Online-Hoster raus aus der Diskussion.

Mein Reden. Wenn sicher, dann bitte nicht bei einem Online-Hoster.

Zitat:

Zitat von Neutral General (Beitrag 1292517)

Wenn ich wirklich etwas entwickel was ich später verkaufen möchte dann würde ich den Code auch niemals auf fremden Servern hosten. [...]

Warum nicht? Hierzulande hosten ganze Versicherungsunternehmen sensibelste Vertragsdaten in von fremden (amerikanischen!) Firmen betriebenen Rechenzentren... http://www.cio.de/a/allianz-riesen-o...an-ibm,2948015

Zitat:

[...] Schon gar nicht wenn Leute meinen Source sehen/runterladen können. [...]

Naja, irgend jemand muss ja mit dem Source auch arbeiten, oder nicht?

Zitat:

[...] Da ist ein eigener SVN/GIT Server auf einem (V-)Server wahrscheinlich sicherer, oder man baut sich lokal ein kleines System im Heimnetzwerk.

Wenn ich "Heimnetzwerk" höre, dann stellen sich mir alle Nackenhaare auf. Sicherlich hast Du in Deinem "Heim" auch einen Hochsicherheitstrakt, der 24/7 bewacht, gegen Naturkatastrophen geschützt und mit einem ausgefeilten Zugangskontrollsystem versehen ist?

[JasonDX]

Zitat:

Zitat von vagtler (Beitrag 1292530)

Zitat:

Zitat von Perlsau (Beitrag 1292513)

[...] Inzwischen hat eine darauf spezialisierte Firma die Marktreife deines Produkts erkannt, sich die Sourcen via illegalem NSA-Kontakt* besorgt, [...]

Mal abgesehen davon, dass die NSA bestimmt leichter an die Daten eines virtuellen Servers eines deutschen Massenhosters als eines australischen, darauf spezialisierten Produkthosters kommt.

Was zu bezweifeln wäre. Die Australier sind auch nicht gerade bekannt dafür, viel auf die Privatsphäre ihrer Bürger zu geben. Und die Kooperation des BND mit der NSA ist bei weitem nicht so eng und ausgiebig wie die des ASD. (Stichwort 5 eyes)

Zitat:

Zitat von vagtler (Beitrag 1292530)

Zitat:

Zitat von Neutral General (Beitrag 1292517)

Wenn ich wirklich etwas entwickel was ich später verkaufen möchte dann würde ich den Code auch niemals auf fremden Servern hosten. [...]

Warum nicht? Hierzulande hosten ganze Versicherungsunternehmen sensibelste Vertragsdaten in von fremden (amerikanischen!) Firmen betriebenen Rechenzentren... http://www.cio.de/a/allianz-riesen-o...an-ibm,2948015

Was noch lange nicht heißt, dass es eine gute Idee ist.

Zitat:

Zitat von vagtler (Beitrag 1292530)

Zitat:

[...] Da ist ein eigener SVN/GIT Server auf einem (V-)Server wahrscheinlich sicherer, oder man baut sich lokal ein kleines System im Heimnetzwerk.

Wenn ich "Heimnetzwerk" höre, dann stellen sich mir alle Nackenhaare auf. Sicherlich hast Du in Deinem "Heim" auch einen Hochsicherheitstrakt, der 24/7 bewacht, gegen Naturkatastrophen geschützt und mit einem ausgefeilten Zugangskontrollsystem versehen ist?

Manchmal ist ein Heimnetzwerk tatsächlich die beste Variante - vorausgesetzt man weiß was man tut. Man braucht auch keinen 24/7 bewachten Sicherheitstrakt. Ein Angriff auf ein ordentlich eingerichtetes Heimnetzwerk ist nur durch eine gezielte Operation machbar, die deutlich mehr Ressourcen verbraucht als ein Brief an deinen Hoster. Und vor allem: Gezielte Angriffe skalieren schlechter als Briefe.

[vagtler]

Zitat:

Zitat von JasonDX (Beitrag 1292563)

[...] Manchmal ist ein Heimnetzwerk tatsächlich die beste Variante [...]

Tatsächlich ist bei einem Heimnetzwerk das Risiko eines Brandschadens und damit vollständigen Datenverlusts ungleich höher als die Wahrscheinlichkeit auf einen gezielten Industriespionageangriff durch die NSA auf einen Hoster.

Wenn die Sourcen so wertvoll sind, dann lohnt sich der physische Angriff viel eher und ist bei einem "Heimnetzwerk" wesentlich leichter (und auch viel schwerer nachzuweisen). Als wenn die NSA einen Brief an den Hoster schickt à la "bitte Sourcen von xyz GmbH zum Zwecke der nationalen Sicherheit aushändigen".

Ich habe den Eindruck, dass die wenigsten, die sich hier äußern, überhaupt schon einmal mit Industriespionage zu tun hatten. Der USB-Stick (gerne auch eine Micro-SD-Card), den ein Mitarbeiter für einen luxuriösen dreiwöchigen Urlaub in der Karibik für die ganze Familie mal irgendwo in einem Bistro nach einem (natürlich bezahlten) Abendessen mit dem befreundeten Entwickler des Mitbewerbers aus der Nachbarstadt "zufällig" auf dem Tisch liegen lässt, ist die viel konkretere Gefahr. Die will der "German Angsthase" aber nicht sehen und investiert Zeit und Geld in zweifelhafte Schutzmechanismen für Quellcode gegen Datendiebstahl durch ausländische Geheimdienste, aber knausert an den Gehältern der und den Incentives für die Mitarbeiter.

Auf besagtem USB-Stick ist dann übrigens viel mehr als nur der Quellcode - ein Backup der Kundendatenbank und der Finanzbuchhaltung sowie der archivierten Verträge passt da sehr gut auch noch drauf...

[JasonDX]

Zitat:

Zitat von vagtler (Beitrag 1292567)

Zitat:

Zitat von JasonDX (Beitrag 1292563)

[...] Manchmal ist ein Heimnetzwerk tatsächlich die beste Variante [...]

Tatsächlich ist bei einem Heimnetzwerk das Risiko eines Brandschadens und damit vollständigen Datenverlusts ungleich höher als die Wahrscheinlichkeit auf einen gezielten Industriespionageangriff durch die NSA auf einen Hoster.

Da würde mich Interessieren woher du die Zahlen dafür hast. Risiko für Wohnungsbrände kann man berechnen, aber wie misst du die Wahrscheinlichkeit auf einen Angriff auf einen Hoster?

Zitat:

Zitat von vagtler (Beitrag 1292567)

Wenn die Sourcen so wertvoll sind, dann lohnt sich der physische Angriff viel eher und ist bei einem "Heimnetzwerk" wesentlich leichter (und auch viel schwerer nachzuweisen). Als wenn die NSA einen Brief an den Hoster schickt à la "bitte Sourcen von xyz GmbH zum Zwecke der nationalen Sicherheit aushändigen".

Gezielte Angriffe sind mit hohem Aufwand verbunden. Guck einfach mal was betrieben wurde, um Gemalto zu hacken. Und: Hacks sind sehr oft nachweisbar. Im Gegensatz zu Briefen an einen Hoster, die dann höchstwahrscheinlich mit Gag-Order versehen werden. Dann kanns gut sein, dass nie jemand davon erfährt.

Zitat:

Zitat von vagtler (Beitrag 1292567)

Ich habe den Eindruck, dass die wenigsten, die sich hier äußern, überhaupt schon einmal mit Industriespionage zu tun hatten. Der USB-Stick (gerne auch eine Micro-SD-Card), den ein Mitarbeiter für einen luxuriösen dreiwöchigen Urlaub in der Karibik für die ganze Familie mal irgendwo in einem Bistro nach einem (natürlich bezahlten) Abendessen mit dem befreundeten Entwickler des Mitbewerbers aus der Nachbarstadt "zufällig" auf dem Tisch liegen lässt, ist die viel konkretere Gefahr. Die will der "German Angsthase" aber nicht sehen und investiert Zeit und Geld in zweifelhafte Schutzmechanismen für Quellcode gegen Datendiebstahl durch ausländische Geheimdienste, aber knausert an den Gehältern der und den Incentives für die Mitarbeiter.

Ich dreh mal die Frage um: Wieviel hast du denn mit Industriespionage zu tun?
Von meiner Seite kann ich sagen, dass ich in einem Unternehmen arbeite, bei dem man davon ausgehen kann, dass es bereits Ziel von Geheimdiensten war&ist. Ich bin dort zwar nicht in der Sicherheitsabteilung, aber man kriegt so manche Sachen trotzdem mit.
Und ja, es gibt immer auch das Risiko, dass ein Mitarbeiter gekauft wird. Das sollte aber genauso nachvollziehbar sein, und der entsprechende Mitarbeiter kann dafür auch rechtlich zur Verantwortung gezogen werden. Insgesamt ist das ein nicht zu vernachlässigender Angriffsvektor, der aber kein Grund ist, andere Angriffspotentiale zu ignorieren.

[vagtler]

Zu dem Thema Brandstatistiken und Industriespionage möchte bzw. darf ich nur so viel sagen, dass ich aus meiner täglichen Arbeit durchaus vertraut mit solchen Themen bin.

Bitte komm aber noch mal auf die hier angesprochene Problematik zurück:

Wenn wir hier ein so dermaßen schützenswertes Gut haben, dass davon die Weltherrschaft abhängt, dann ist weder der virtuelle Server bei einem Massenhoster, noch ein kommerzieller Git-Hoster, noch der Server im Keller ein probater Aufbewahrungsort.

Für den durchschnittlichen Klein(st)unternehmer bleibe ich aber dabei, dass ein darauf spezialisierter Hoster die (durchaus vorhandenen und berechtigten) Schutzbedürfnisse meist besser befriedigen kann als der Betrieb eines eigenen (virtuellen) Servers bei einem Massenhoster.

Und zu glauben, dass sich die NSA wirklich für die 1.654ste in Delphi geschriebene Vereinsverwaltung interessiert, ist einfach vermessen.

Aber ich gebe Dir Recht, dass natürlich jeder Angriffsvektor abgewogen und bewertet werden muss. Oft ist es halt eine Generalangst vor allem, die dann zu unüberlegten, viel gefährlicheren Handlungen führt.

[Sherlock]

Also gegen einen Server im Keller ist doch nichts einzuwenden, so lange der nur per VPN von aussen erreichbar ist. Auf diesen Server spielt man einen Apache und kann dann gleichzeitig das Wiki und das Web-Frontend des hg-Servers drüber laufen lassen. Super einfach, stabil und geschützt genug (wer ins Firmennetz eindringen kann, der hat es sich auch verdient an die Sourcen zu kommen).

Sherlock

[JasonDX]

Zitat:

Zitat von vagtler (Beitrag 1292582)

Wenn wir hier ein so dermaßen schützenswertes Gut haben, dass davon die Weltherrschaft abhängt, dann ist weder der virtuelle Server bei einem Massenhoster, noch ein kommerzieller Git-Hoster, noch der Server im Keller ein probater Aufbewahrungsort.

Größtenteils kann ich dem beipflichten. Der Knackpunkt ist der, dass man bei Hostern davon ausgehen kann, dass sich Dritte Zugriff darauf verschaffen können. Eigene, individuelle Lösungen sind keineswegs 100% sicher, aber manchen (abhängig vom Setup) einen gezielten, nicht-skalierenden Angriff notwendig. Natürlich kann man dabei auch ordentlich verkacken, und eine offene Tür hinterlassen.

Zitat:

Zitat von vagtler (Beitrag 1292582)

Für den durchschnittlichen Klein(st)unternehmer bleibe ich aber dabei, dass ein darauf spezialisierter Hoster die (durchaus vorhandenen und berechtigten) Schutzbedürfnisse meist besser befriedigen kann als der Betrieb eines eigenen (virtuellen) Servers bei einem Massenhoster.

Das ja. Ein V-Server erbt die Problematik eines Hosters im Bezug auf rechtliche Zuständigkeit, PLUS das Risiko des eigenen SetUps. (War da nicht letzt auch mal was, dass zig-tausende MongoDBs wegen falschem Setup öffentlich zugänglich waren?)

Zitat:

Zitat von vagtler (Beitrag 1292582)

Und zu glauben, dass sich die NSA wirklich für die 1.654sten in Delphi geschriebene Vereinsverwaltung interessiert, ist einfach vermessen.

Es hängt von der Anwendung, bzw. den Kunden ab. Eine gewisse Grundabsicherung sollte immer da sein. Aber um den Aufwand zu betreiben, sich gegen bestimmte Angriffe zu verteidigen, dann sollte auch das Risiko solcher Angriffe bestehen.

Zitat:

Zitat von vagtler (Beitrag 1292582)

Aber ich gebe Dir Recht, dass natürlich jeder Angriffsvektor abgewogen und bewertet werden muss. Oft ist es halt eine Generalangst vor allem, die dann zu unüberlegten, viel gefährlicheren Handlungen führt.

Full Ack. Es war auch durchaus korrekt, auf andere Angriffsvektoren (Wie eben korrupte Mitarbeiter) hinzuweisen - Das schlimmste das man tun kann ist, eine Sicherheitsvorkehrung zu treffen, und dann glauben, man sei vor allem sicher.

Zitat:

Zitat von Sherlock (Beitrag 1292586)

Also gegen einen Server im Keller ist doch nichts einzuwenden, so lange der nur per VPN von aussen erreichbar ist. Auf diesen Server spielt man einen Apache und kann dann gleichzeitig das Wiki und das Web-Frontend des hg-Servers drüber laufen lassen.

Es ist ein Aufwand, und kostet Ressourcen. Und wenn jemand wirklich dran will, wird der Laptop eines Mitarbeiters angegriffen.

[Sherlock]

Ja, man kann natürlich Kompetenz und KnowHow nach aussen werfen, und sich auf die "wichtigen" Dinge konzentrieren. Andererseits könnte der Chef auf den gleichen Gedanken kommen, und die Entwicklungsabetilung outsourcen. Wer keinen Apache zusammenklicken kann (und mehr muss man mit einer handelüblichen XAMPP-Installation wirklich nicht tun) und darauf kein DokuWiki (imho simpelstes Wiki überhaupt) und hg-Servlet drauf bekommt, der bekommt auch sonst in der IT nichts auf die Reihe. Für das VPN und die Unternehmensfirewall sorgt die hauseigene IT.

Sherlock

[JasonDX]

Zitat:

Zitat von Sherlock (Beitrag 1292599)

Ja, man kann natürlich Kompetenz und KnowHow nach aussen werfen, und sich auf die "wichtigen" Dinge konzentrieren. [...] Wer keinen Apache zusammenklicken kann (und mehr muss man mit einer handelüblichen XAMPP-Installation wirklich nicht tun) und darauf kein DokuWiki (imho simpelstes Wiki überhaupt) und hg-Servlet drauf bekommt, der bekommt auch sonst in der IT nichts auf die Reihe. Für das VPN und die Unternehmensfirewall sorgt die hauseigene IT.

"Schuster, bleib bei deinen Leisten". Das gefährliche sind eben Leute, die meinen sich damit auszukennen, dann aber was zusammenklicken und davon ausgehen, dass es sicher sei. Wenns ne hauseigene IT gibt, dann setzt die das auf, und hat hoffentlich auch die entsprechenden Qualifikationen und Erfahrungen. Ansonsten ist ein externer Dienstleister mit dafür qualifizierten und erfahrenen Leuten trotz rechtlicher Verpflichtungen immernoch die sicherere Variante.