Hallo Leute, ich bin in der Software-Integration tätig (kleines Team) und wir haben ein organisatorisches Problem würde ich sagen. Und zwar ist es so, dass vor vielen Jahren die SW Entwicklung outgesourced wurde. Die Weiterentwicklung macht eine andere IT / Drittfirma, die sind jetzt auch Lieferant unserer SW. Die benutzen intern in ihrer Firma natürlich ein Repository (SVN) wo sie ihre Software entwickeln, committen und builden und danach uns zur Verfügung stellen. Soweit kein Problem. Nun ist es so, dass wir auch ab und zu Spezial-Anpassungen machen und diese einchecken. Wir haben aber unser eigenes Repository (auch SVN). Idiotischerweise verwendet jeder sein eigenes Repository! Klarerweise haben wir schon oft den Vorschlag gemacht auf ein Repository zu setzen, dies scheiterte anscheinend an rechtlichen und organisatorischen Gründen, (oder einfach weil die Firma bekloppt ist). Bis jetzt wurden die Libs und Sourcen über SFTP ausgetauscht (!). Wenn wir was neues haben laden wir es hoch und vice versa. Klar, dass da ab und zu etwas vergessen geht, es Merge Konflikte gibt, oder man sich plötzlich wundert, wo (oder von wem) die Änderung kommt. An Fehlern sind aber trotzdem wir schuld, wenn wieder mal etwas nicht funktioniert. Nun haben wir ein Meeting, wo wir Chefs erklären müssen, wo das Problem liegt und wie wir das verhindern können. Blöderweise sind die nicht sehr IT-affin und haben selbst noch keine Ahnung oder sich noch nie mit SVN oder Git o.ä. beschäftigt. -Gibt es ein Konzept wie diesen Mist umgehen kann (klar, ein einziger SVN Server) - wenn aber kurzfristig nicht möglich? -wie kann man Chefs die nicht wirklich viel Ahnung von Entwicklung haben, das Problem erklären? thx Endwiggler
Endwiggler schrieb: > klar, ein einziger SVN Server So klar ist das nicht. Linus Torvalds schafft es, den Linux-Kernel verteilt entwickeln zu lassen. Da werdet ihr paar Hanseln doch auch zusammenkommen. Kannst dir ja von Herrn Torvalds was abschauen.
Endwiggler schrieb: > -Gibt es ein Konzept wie diesen Mist umgehen kann (klar, ein einziger > SVN Server) - wenn aber kurzfristig nicht möglich? Für sowas bietet Git viele Werkzeuge, dort sind dezentrale Repositories Standard. Stichwörter: pull, rebase, merge, cherry-picking Es bringt dir aber nichts, Git wie eure SVN-Server zu verwenden. Damit verliert ihr alle Vorteile. IMHO kommt es mir eher so vor, als hättet euer Management die Funktionsweise von Versionsmanagement nicht verstanden. Ich würde da kündigen und mir die Schmerzen nicht weiter geben.
Endwiggler schrieb: > der sich noch nie mit SVN oder Git o.ä. beschäftigt. Git wäre hier genau die Lösung... Das geht dezentral, ihr könntet eure Änderungen halbautomatisch an die andere Firma schicken bzw. die Firma macht ein "pull" auf euer Repo. Oder ihr verwendet beide GitHub oder BitBucket (mit nicht-öffentlichen Repositories) oder eine gemeinsame GitLab Instanz, da wäre es super einfach Änderungen des anderen jeweils zu übernehmen.
Endwiggler schrieb: > Nun ist es so, dass wir auch ab und zu Spezial-Anpassungen machen und > diese einchecken. Wir haben aber unser eigenes Repository (auch SVN). Und achtet Ihr auch darauf, dass die Verzeichnis- und Dateistruktur genauso aufgebaut ist wie bei dem externen Dienstleister? > Idiotischerweise verwendet jeder sein eigenes Repository! Alles Iditioten, außer Dir natürlich. > Klarerweise > haben wir schon oft den Vorschlag gemacht auf ein Repository zu setzen, > dies scheiterte anscheinend an rechtlichen und organisatorischen > Gründen, Genau solche Gründen darf man eben nicht vernachlässigen. Von dem großen Ziel, auf einer gemeinsamen Quellcodebasis zu arbeiten, muss man sich leider sehr häufig verabschieden, auch wenn es manchmal als die einfachste Lösung erscheint. Es kann sehr gute Gründe geben, warum man z.B. bestimmte Checkins oder Verzeichnisse Dritten nicht zur Verfügung stellen möchte. > (oder einfach weil die Firma bekloppt ist). "Die Firma" ist der nur der Name, unter der ein eingetragener Kaufmann tätig ist. Du meinst wahrscheinlich das dahinter befindliche Unternehmen. Dieses wird aber dummerweise durch seine Mitarbeiter verkörpert, also auch durch Dich. > Bis jetzt wurden die Libs und Sourcen über SFTP ausgetauscht (!). Wenn > wir was neues haben laden wir es hoch und vice versa. Das ist doch durchaus praktikabel. Wichtig ist jedoch, wie die Daten jeweils organisiert sind. Und befinden sich geeignete(!) Lieferinformationen dabei, z.B. README, Änderungslisten, usw.? > Klar, dass da ab und zu etwas vergessen geht, es Merge Konflikte gibt, > oder man sich plötzlich wundert, wo (oder von wem) die Änderung kommt. Das heißt also, dass Ihr Entwickler (also z.B Du) den Austausch solcher Lieferungen nicht hinreichend erst nehmt. Es ist gar nicht so klar, dass dabei etwas vergessen wird, wenn man geeignete Lieferprozesse realisiert hat. Unvollständige Lieferungen kommen vor allem dann zustande, wenn man mal schnell irgendetwas aus einer Entwickler-Sandbox zusammenkopiert. Deswegen ist es immens wichtig, für Lieferungen immer saubere, frische Checkouts in leere Verzeichnisstrukturen zu verwenden und darauf den Buildprozess durchzuführen. Dann merkt man sofort, ob alles vollständig ist. (*) Dieser Vorgang ist durchaus auch ohne Lieferung an Dritte ratsam, sondern stellt die Konsistenz auch für interne Zwecke sicher. Wenn man mit Buildservern wie z.B. Jenkins arbeitet, denen man nur ein Label oder Tag des Versionskontrollsystems verabreicht, hat man das perfektioniert. > An Fehlern sind aber trotzdem wir schuld, wenn wieder mal etwas nicht > funktioniert. Nun haben wir ein Meeting, wo wir Chefs erklären müssen, > wo das Problem liegt und wie wir das verhindern können. Und ganz genau so ist es auch richtig. > Blöderweise sind die nicht sehr IT-affin und haben selbst noch keine > Ahnung oder sich noch nie mit SVN oder Git o.ä. beschäftigt. Aha, und wieder sind die anderen alle blöd. Ihr versucht also, Eure eigene mangelnde Disziplin bei der Lieferung und Integration Dritten in die Schuhe zu schieben? > -Gibt es ein Konzept wie diesen Mist umgehen kann (klar, ein einziger > SVN Server) - wenn aber kurzfristig nicht möglich? Dann muss man sich eben geeignete Lieferprozesse überlegen. Lieferungen müssen immer VOLLSTÄNDIG sein und dürfen NIEMALS nur aus einzelnen hingeworfenen Dateihäppchen bestehen, auch wenn es zunächst verschwenderisch erscheint, wegen ein paar geänderter Bytes einen viele Megabyte großen Dateihaufen zu liefern. Lieferungen müssen KONSISTENT sein, siehe oben. Und sie müssen geeignet gekennzeichnet sein. OurGreatSoftware-1.0-new-version.zip ist kein geeigneter Name. Und auch die Integration fremder Software muss entsprechend ablaufen. Sinnvollerweise versioniert man dabei alle Integrationsschritte: ZIP-Datei --> OurGreatSoftware/transfer/lieferant/in/version entpackte Quellen --> OurGreatSoftware/branches/lieferant/version Von dort ausgehend führt man die Software auf einem separaten Merge-Branch zusammen, bis sie letztendlich in den oder die Arbeitsbranches bzw. den Trunk (je nach Arbeitsmodell) integriert wird. > -wie kann man Chefs die nicht wirklich viel Ahnung von Entwicklung > haben, das Problem erklären? Ganz einfach: "Hallo Chefs, wir Entwickler sind zu faul, uns über geeignete Austauschprozesse hinreichend viele Gedanken zu machen und einen reproduzierbaren Arbeitsablauf einzuführen. Stattdessen verschwenden wir lieber ein Vielfaches der Zeit damit, herumzulamentieren und auf sehr fehlerträchtige Art und Weise die Softwarestände irgendwie zusammenzuflicken." Zu (*): Ich kenne leider auch einige drittklassige Entwickler, die monatelang oder jahrelang immer auf demselben Arbeitsverzeichnis arbeiten und nicht sicherstellen, dass dort keine Dateileichen usw. herumliegen. Dabei kann ich mich noch an den Fall erinnern, in dem ein ehemaliger Kollege die Lieferung eines sehr wichtigen Firmwarestandes an einen großen Kunden durchführen sollte. Ich fand es ohnehin ziemlich fahrlässig, diesen Idioten damit zu beauftragen. Ich drängte ihn, für die Lieferung unbedingt eine frische Sandbox auszuchecken, dort alles zu kompilieren, kurz zu testen usw.. Bei solchen wichtigen Lieferungen ist es sogar wichtig, anschließend die Sandbox inklusive aller Artefakte des Buildprozesses z.B. in einer ZIP-Datei o.ä. zu packen, um im Falle von Problemen ggf. sogar noch Forensik betreiben zu können. Und was machte der Typ: er machte ein Update auf seiner Sandbox, checkte einige eigene Dateien ein, kompilierte, lieferte die Firmware an den Kunden und löschte seine Sandbox, um am nächsten Tag auf einem sauberen Stand aufzusetzen zu können, und ging nach Hause. Am nächsten Tag dann die Überaschung: wir anderen Entwickler führten ebenfalls ein Update durch und stellten beim Kompilieren fest, dass mehrere Dateien fehlten. Der o.a. Entwickler hatte vergessen, ein paar von ihm selbst erstellte Quellcodes einzuchecken. Dies war bis dahin niemandem aufgefallen, da er an einem recht isolierten Modul arbeitete und die Verknüpfung mit seinen neuen Quellcodes erst durch die o.a. Checkins für jedermann sichtbar wurden. Der Trottel hatte aber seine Sandbox gelöscht, so dass seine Quellcodes unwiderbringlich verloren waren. Und natürlich hat er auch nicht - wie es eigentlich vorgeschrieben war - auf einem Netzwerklaufwerk gearbeitet, das der regelmäßigen Datensicherung unterworfen war, sondern nur auf seinem eigenen PC. Da das gelieferte Firmwareupdate ein paar sehr wichtige Bugfixes enthielt, führte der Kunde auch gleich ein großes Rollout durch. Dies bedeutete, dass sich plötzlich zigtausende an Geräten mit einem Firmwarestand befanden, der nicht mehr reproduzierbar war! Zum Glück gab es kein Problem mit der Firmware, und es gab genug Zeit, die fehlende Software noch einmal nachzuimplementieren.
Dr. Sommer schrieb: > Git wäre hier genau die Lösung... Nein, nicht zwingend. Das funktioniert nur dann reibungslos, wenn alle Beteiligten hinreichend kompatible Verzeichnisstrukturen verwenden. > Das geht dezentral, ihr könntet eure > Änderungen halbautomatisch an die andere Firma schicken bzw. die Firma > macht ein "pull" auf euer Repo. Damit werden aber auch die Checkins sichtbar, die eigentlich für die andere Partei verborgen bleiben sollen. > Oder ihr verwendet beide GitHub oder > BitBucket (mit nicht-öffentlichen Repositories) oder eine gemeinsame > GitLab Instanz, da wäre es super einfach Änderungen des anderen jeweils > zu übernehmen. Für die Nutzung solcher externen Dienste (auch mit nicht-öffentlichen Repositories!) muss aber vorab juristisch geklärt werden, ob es rechtliche Hindernisse gibt, z.B. bei Fremdsoftware. Dies ist eine sehr umfangreiche Thematik, die sehr viele Fragen aufwerfen und den Rahmen dieses Threads gewaltig sprengen kann.
Andreas S. schrieb: > Nein, nicht zwingend. Das funktioniert nur dann reibungslos, wenn alle > Beteiligten hinreichend kompatible Verzeichnisstrukturen verwenden. Ja logisch. Ich war mal davon ausgegangen, dass Leute die am selben Projekt arbeiten, die gleiche Verzeichnisstruktur nutzen. Das klappt ja bei tausend Open Source Projekten auch. Andreas S. schrieb: > Damit werden aber auch die Checkins sichtbar, die eigentlich für die > andere Partei verborgen bleiben sollen. Nur die Commits die man dem anderen per pull/merge übergibt (und die "zwischen" den Ständen), nicht die aus anderen Branches. Mir war aber aus dem originalen Posting nicht klar dass das ein Problem darstellt. Andreas S. schrieb: > Für die Nutzung solcher externen Dienste (auch mit nicht-öffentlichen > Repositories!) muss aber vorab juristisch geklärt werden, ob es > rechtliche Hindernisse gibt Im Zuge des ganzen Cloud- und Saas-Hype hätte ich mal vermutet, dass das nicht mehr so das große Problem darstellt. Viele Firmen verwenden fremde Hoster auch z.B. für e-Mail, Web & Co. GitHub bzw. Atlassian sind ja nicht irgendwelche Firmen. Ich weiß auch nicht ob das rechtliche das eigentliche Problem ist - in den AGB der Anbieter heißt es ja dass die Daten geschützt sind. Die Frage ist mehr ob man es denen auch glaubt! Kommt es doch zum Datenleck, weiß man ja wen man verklagen kann.
Nutzt GIT! SVN skaliert nicht, das merkt ihr gerade. GIT wurde genau für solche Anwendungszwecke geschaffen.
Andreas S. schrieb: > Alles Iditioten, außer Dir natürlich. Schon hart Du lastest dem TO an, das er sich über Defizitte in seiner Firma aufreget, da er sich anscheinend Gedanken macht und etwas ändern will und selbst: Andreas S. schrieb: > Ich fand es ohnehin ziemlich fahrlässig, diesen > Idioten damit zu beauftragen. Andreas S. schrieb: > Der Trottel hatte aber seine > Sandbox gelöscht, so dass seine Quellcodes unwiderbringlich verloren > waren. Unabhängig davon, das Du mit Deinem geschriebenen ja recht zu haben scheinst, hat es beim lesen trotzdem einen gewissen Beigeschmack gehabt. Das ganze Thema SW-Entwicklung mit mehreren Entwicklern war noch nie einfach und wird es auch nie sein. Es hat halt leider jeder seine Gewohnheiten und Arbeitsweisen und da wird ist es nie einfach alle unter einen Hut zu bekommen. Ich kenne das auch, losgelöst von SW-Entwicklung, da ist der verantwortliche im Urlaub, Du darfst vertreten und siehst nicht durch vor lauter .sec und .org Dateien und Ordnern, weil man könnte es ja noch mal gebrauchen. Dann versucht man sachlich auf die Probleme hinzuweisen und der jenige fühlt sich so an's Bein gepinkelt, das eine Diskussion über die tatsächlich vorhandenen Probleme nicht möglich ist und dem zu Folge die Probleme auch nicht gelöst wurden. Natürlich waren die Probleme bekannt, aber man hat halt immer irgendwo händisch ein gegriffen und kein anderer wusste wo. In dem Fall kam halt auch noch dazu, das man sich natürlich auch nicht erklären lassen wollte, wo die eigentlichen Probleme in der Basis lagen und wie man diese beheben hätte können, da hat man lieber irgendwelche Scripte angepasst und festgestellt, das es am Ende trotzem nicht ging. Von dem her kann ich den TO schon verstehen, er will was ändern, hat aber einen Chef der scheinbar keine Weitsicht hat und Kollegen die Probleme nicht erkennen.
Wenn E-Techniker sich über Softwareentwicklung Gedanken machen. Zu geil :D Wir entwickeln mit > 200 Leuten an einem Standort an einem System, aber ja klar, Entwicklung mit mehreren Leuten an einem System ist nicht einfach. Wo ist der Wallbashsmiley? :D
nnn schrieb: > Wenn E-Techniker sich über Softwareentwicklung Gedanken machen. > Zu geil :D Alles Idioten, außer dir natürlich.
Dr. Sommer schrieb: > Andreas S. schrieb: >> Nein, nicht zwingend. Das funktioniert nur dann reibungslos, wenn alle >> Beteiligten hinreichend kompatible Verzeichnisstrukturen verwenden. > Ja logisch. Ich war mal davon ausgegangen, dass Leute die am selben > Projekt arbeiten, die gleiche Verzeichnisstruktur nutzen. Das klappt ja > bei tausend Open Source Projekten auch. Einer unserer Kunden, mit dem wir sehr regelmäßig Lieferungen in beiden Richtungen austauschen, verwendet auf Grund einer internen Konventionen so unglaublich lange Verzeichnispfade, dass man darauf nicht sinnvoll entwickeln kann. Teilweise werden solche Pfade von Tools abgeschnitten oder gar nicht erst akzeptiert. Aus diesem Grunde arbeiten wir z.B. mit geschickt definierten svn:externals, d.h. zwecks Beibehaltung der kundenseitigen Verzeichnisstruktur gibt es die langen Pfade, aber für problematische Fälle eben auch die deutlich kürzeren Pfade als Referenzen. > > Andreas S. schrieb: >> Damit werden aber auch die Checkins sichtbar, die eigentlich für die >> andere Partei verborgen bleiben sollen. > Nur die Commits die man dem anderen per pull/merge übergibt (und die > "zwischen" den Ständen), nicht die aus anderen Branches. Sobald man aber, wie es oben beschrieben wurde, nur noch einen einzigen Git-Server verwendet, werden alle Branches sichtbar, zumindest für den Administrator. Man kann natürlich auch noch an anderer Stelle, z.B. auf dem eigenen PC, noch weitere Repositories ablegen, aber diese müssen dann auch der Datensicherung usw. unterworfen werden. Technisch kann man bei Git o.ä. zwar beliebig viele Repositories verwenden, aber die Gefahr ist dabei auch sehr groß, dass wichtige Checkins verlorengehen. Spätestens dann, wenn z.B. Commits zur automatischen Generierung von E-Mails oder Aktualisierung von Tickets (z.B. bei Trac, JIRA) führen sollen, sollten die Repositories nicht zu sehr verstreut sind. > Mir war aber aus dem originalen Posting nicht klar dass das ein Problem > darstellt. Du ahnst gar nicht, wie sehr Versionskontrollsysteme auch für "Firmenpolitik" missbraucht werden können. Damals als Angestellter kam irgendwann ein Produktmanager zu mir und befragte mich zu den Auswirkungen bestimmter Checkins, in denen ich die Struktur etlicher im Laufe der Zeit gewachsener C-Headerdateien deutlich aufräumte. Ich erklärte es ihm, aber wie zu erwarten war, verstand er es nicht. Daraufhin gab es eine Arbeitsanweisung an alle Entwickler, dass nur noch Änderungen eingecheckt werden dürfen, die unmittelbar die User Experience verbessern und den Shareholder Value maximieren. :-/ Von einem anderen Unternehmen ist mir bekannt, dass der dortige Betriebsrat vor dem Arbeitsgericht durchsetzte, dass Checkins und Bugtracker-Tickets keine Rückschlüsse mehr auf die beteiligten Entwickler zulassen dürfen, denn dies verletze die Persönlichkeitsrechte von Gewerkschaftsmitgliedern. > Im Zuge des ganzen Cloud- und Saas-Hype hätte ich mal vermutet, dass das > nicht mehr so das große Problem darstellt Das mag in vielen Fällen zwar kein Problem darstellen, daraus auf eine Allgemeingültigkeit zu schließen ist jedoch nicht zulässig. Bei einem Kunden, der u.a. im Rüstungsbereich tätig ist und weltweit Standorte hat, geht es sogar so weit, dass es nicht zulässig wäre, (natürlich verschlüssselte) VPN-Verbindungen über Leitungen zu führen, die auf dem Staatsgebiet von Ländern verlaufen, mit denen keine entsprechenden militärischen Abkommen bestehen. Es ist nämlich rechtlich kaum ein Unterschied, ob man verschlüsselte Daten per LWL transportiert oder einen Konvoi mit schwerem Kriegsgerät durch ein Drittland transportieren möchte. Und nein, wir reden hier nicht über die technische Seite, sondern ausschließlich über die juristische und politische Seite. > Viele Firmen verwenden fremde > Hoster auch z.B. für e-Mail, Web & Co. GitHub bzw. Atlassian sind ja > nicht irgendwelche Firmen. Viele Firmen verwenden ausschließlich eigene Infrastruktur. Und wiederum andere Firmen nutzen für manche Dienste ausschließlich eigene Infrastruktur und für andere auch Fremdleistungen, z.B. mein Unternehmen. > Ich weiß auch nicht ob das rechtliche das > eigentliche Problem ist - in den AGB der Anbieter heißt es ja dass die > Daten geschützt sind. Die Frage ist mehr ob man es denen auch glaubt! > Kommt es doch zum Datenleck, weiß man ja wen man verklagen kann. Das hängt von Unternehmen zu Unternehmen ab. Teilweise werden sicherlich juristische Gründe vorgeschoben, um sich einfach die technischen Themen vom Hals zu halten. Aber in anderen Fällen verbieten eben bestehende oder noch zu schließende Verträge mit Kunden oder Lieferanten die Auslagerung der Daten an externe Dienstleister, insbesondere wenn diese anderen Rechtssystemen unterworfen sind oder unterworfen werden können. Gerade bei US-amerikanischen Unternehmen muss man ja sehr vorsichtig sein, weil die Geheimdienste eine so große Macht haben, dass die Unternehmen entsprechende Eingriffe weder publik machen noch sich mit rechtlichen Mitteln dagegen wehren können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.