Software Configuration Management

Software Configuration Management

Posts 1-6 of 6
  • Bernd Augustin
    Bernd Augustin    Premium Member
    The company name is only visible to registered members.
    SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    Hallo,
    wir führen gerade die Diskussion in der Firma, ob die einzelnen Projekte in ein Repository kommen sollten, oder doch lieber führ jedes Projekt sein eigenes Repository.

    Hinter Grund:
    Alle Projekte bauen auf eine gemeine Platfrom auf , die über externals in die einzelnen Projekte gebracht werden sollen. Kundenspezifische Erweiterungen, Konfigurationen und Anpassungen werden in den einzelnen Repositories vorgenommen.

    Die Weiterentwicklung der Platform wird automatisch in die Projekte verteilt.
    Ist ein Kunden Projekt fertig wird der letzte Stand in dem ProjekRepository "eingefroren" und das kundenspezifische Projekt besitz komplett sein eigenes Repositiory.

    Oder ist der bessere Weg alle Projekte in ein Repository ein zulagern und nur mit Branches und Tags zu arbeiten.

    Wie sind im allgemeinen die Erfahrungen? Welche Vorteile bietet die eine Vorgehensweise welche die andere?

    Ich würde lieber ein Repository mit der Platform schaffen, und alle anderen Projekte in ein eigenes Repository, um so eine Trennung der einzelnen Projekte zu bekommen.

    Bernd Augusitn
    • 17 Nov 2008, 10:30 pm
  • Edward Orlowski
    Edward Orlowski    Premium Member
    The company name is only visible to registered members.
    Re: SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    Hallo,

    gerade mit dieser Problematik beschäftigen wir uns seit einigen Jahren. Wir haben eine der möglichen Lösungen (mit allen möglichen Vor- und Nachteilen) inzwischen bei vielen von unseren Kunden durchdiskutiert und auch (vom Fall zum Fall) differenziert umgesetzt. Deshalb möchte ich Ihnen unsere Homepage empfehlen (http://www.uvd.co.at) bzw. zu einer Veranstaltung einladen, die am 03.12. 2008 stattfindet.

    Nur eine rege Diskussion kann bei der Repository-Strategie helfen.

    Mit freundlichen Grüßen
    Edward Orlowski

    P.S. Ich erlaube mir die Details zu unserem Round Table hier zu präsentieren:

    =================================================================================
    Round Table mit anschließender Diskussion

    IT-weites Release Management in der Praxis

    Die UVD Business Consulting GmbH und Herr Monti Krause, Unternehmensberater, freuen sich,
    Sie zum Round Table IT-weites Release Management in der Praxis - 2008 einzuladen.
    Als Lösungsspezialist und Hersteller im Bereich Software Release Management werden wir alle Aspekte rund um das Thema „IT-weites Release Management“ kritisch beleuchten und mit ExpertInnen folgende Fragen diskutieren:

    :: Planung und Durchführung von technischen Rollouts
    :: Plattform-übergreifende Paketierung von Software
    :: Management der Software-Lieferkette
    :: Zentrale Steuerung von Deployment Prozessen
    :: Bestandsverwaltung für Test- und Produktionsumgebungen

    Als Vortragende begrüßen Sie

    DI Michael Schmidt
    Geschäftsführer der UVD Business Consulting GmbH und langjähriger Experte für
    das Release Management und Deployment von komplexen IT Systemen

    DI Monti Krause
    DI Monti Krause, Senior Consultant mit langjähriger Erfahrung im Software Management.

    Im Anschluss an die Vorträge laden wir zur Diskussion und zum Vernetzen beim Mittagessen.

    Mittwoch, 3. Dezember
    09:00 Begrüßung
    09:15 Beginn der Vorträge
    12:45 Mittagessen und Ende der Veranstaltung

    Hotel Ascari in Pulheim
    Tagungsraum
    Jakobstrasse
    D-50259 Pulheim/Köln
    ================================================================================
    • 18 Nov 2008, 10:51 am
  • Karl Heinz Marbaise
    Karl Heinz Marbaise    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    Hallo,

    meine erste Frage wäre: Subversion 1.5 oder noch 1.4 ?

    Nun mal zum Thema....aus technischer Sicht besteht keinerlei Notwendigkeit mehrere Repositories zu haben....

    Hinter Grund:
    Alle Projekte bauen auf eine gemeine Platfrom auf , die über externals in die einzelnen Projekte gebracht werden sollen. Kundenspezifische Erweiterungen, Konfigurationen und Anpassungen werden in den einzelnen Repositories vorgenommen.
    Die Weiterentwicklung der Platform wird automatisch in die Projekte verteilt. Da würde mich interessieren wie das gemacht wird...

    Weiterhin wäre interessant, ob hier vornehmlich in Java entwickelt wird?

    Ist ein Kunden Projekt fertig wird der letzte Stand in dem ProjekRepository "eingefroren" und das kundenspezifische Projekt besitz komplett sein eigenes Repositiory. Welchen Vorteil hat ein eigenes Repository ? Hat der Kunde zugriff darauf ? Entwickelt der Kunde mit, sprich ändert der Kunden die Doku und/oder Source-Code ?

    Oder ist der bessere Weg alle Projekte in ein Repository ein zulagern und nur mit Branches und Tags zu arbeiten. Bitte nicht ein Repository mit Projekten verwechseln....

    Man kann ja durchaus ein Repository in der folgenden Form aufbauen:

    /
    - Projekt1
    +-- trunk
    +-- tags
    +-- branches
    - Projekt2
    +-- trunk
    +-- tags
    +-- branches

    Damit kann Projekt2 ohne Probleme per externals Inhalte von Projekt1 nutzen. Idealerweise ist dann Projekt1 ein Framework/Bibliothek für Projekt2....Somit ist hier die Trennung der Projekt1 vorhanden als auch Verantwortlichkeiten sind hier getrennt. Nämlich das Team für Projekt1 (Framework) und Projekt2 usw.

     
    Wie sind im allgemeinen die Erfahrungen? Welche Vorteile bietet die eine Vorgehensweise welche die andere?     Der einzige wirkliche Grund eigene Repositories für die Projekte zu machen ist der, dass man auch bei einer Fehlkonfiguration der Zugriffsrechte, keinen Einblick in andere Bereich bekommt.

    Persönliche Anmerkung: Warum wird Leuten in Firmen der Zugriffe (zumindest lesend) auf die Repositories verweigert....hat man so wenig Vertrauen in die eigene Manschaft......


    Ich würde lieber ein Repository mit der Platform schaffen, und alle anderen Projekte in ein eigenes Repository, um so eine Trennung der einzelnen Projekte zu bekommen. Warum ? Welchen Vorteil hat das?

    Der Vorteil eines einzigen Repositories ist z.B. von seiten der Administration, dass hier nur ein Repository gebackupd werden muss....

    Weiterhin ist die Administration im Bereich der Hook-Scripte einfacher, da es nur ein Repository gibt und nicht verschiedene....wobei sich darüber durchaus diskutieren läßt...


    MfG
    Karl Heinz Marbaise
    • 18 Nov 2008, 11:25 am
  • Bernd Augustin
    Bernd Augustin    Premium Member
    The company name is only visible to registered members.
    Re^2: SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    meine erste Frage wäre: Subversion 1.5 oder noch 1.4 ? Wahrscheinlich 1.5 sehe aber nicht wieso das einen Unterschied machen würde.
     
    Weiterhin wäre interessant, ob hier vornehmlich in Java entwickelt wird?     Nein die Projekte sind im wireless sensornetz werk anzusiedeln (max. Adressraum incl. Perepherie 64K, Batteriebetrieb 2-3 Jahre ohne wartung).
    Somit enthält die Plattform Betriebssystem, Treiber, Protokolle, Basis Funktionalität, usw.)


    Persönliche Anmerkung: Warum wird Leuten in Firmen der Zugriffe (zumindest lesend) auf die Repositories verweigert....hat man so wenig Vertrauen in die eigene Manschaft...... Der Zugriff zwischen den einzelnen Mitarbeitern ist nicht das Problem. Problem könnte auftretten wenn die Kunden, zugriff auf die Datenbank bekommen sollten.

    Ich würde lieber ein Repository mit der Platform schaffen, und alle anderen Projekte in ein eigenes Repository, um so eine Trennung der einzelnen Projekte zu bekommen.
    Warum ? Welchen Vorteil hat das?     Ein Repository enthält alle Projekt relevanten Daten, und nichts anderes. es könnte als eine Zusammenfassung von verschiedenen Basissystemen dienen (z.B. Sensornodes, AccessPoints, PC Bedienersoftware usw.) welche auf unterschiedlicher Basissoftware aufsetzt. Es ist aber nur das vorhanden was benötigt wird, z.B. Anpassungen auf unterschiedliche Prozessoren ist im "Projekt-Repository" nicht mit aufgeführt.

    Der Vorteil eines einzigen Repositories ist z.B. von seiten der Administration, dass hier nur ein Repository gebackupd werden muss....
    Auch das kann Vorteile haben, dies Projektbezogen zu ändern
    • 18 Nov 2008, 12:08 pm
  • Karl Heinz Marbaise
    Karl Heinz Marbaise    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^3: SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    Hallo,

    Wahrscheinlich 1.5 sehe aber nicht wieso das einen Unterschied machen würde. Ganz einfach. Mit der Version 1.5 wurde die Syntax für svn:externals erweitert und bringt aus diesem Grund einige Verbesserungen mit sich...Relative externals etc. siehe...http://subversion.tigris.org/svn_1.5_releasenotes.html#exter...

    Nein die Projekte sind im wireless sensornetz werk anzusiedeln (max. Adressraum incl. Perepherie 64K, Batteriebetrieb 2-3 Jahre ohne wartung).
    Somit enthält die Plattform Betriebssystem, Treiber, Protokolle, Basis Funktionalität, usw.)     Ah ....also richtige Hardware etc.

    Der Zugriff zwischen den einzelnen Mitarbeitern ist nicht das Problem. Problem könnte auftretten wenn die Kunden, zugriff auf die Datenbank bekommen sollten. Hier wäre die Frage zu beantworten. "könnte" das ein Problem sein oder ist das ein Problem...Wenn ja, dann mehrere Repositories ansonsten ein einziges...


    Ein Repository enthält alle Projekt relevanten Daten, und nichts anderes. es könnte als eine Zusammenfassung von verschiedenen Basissystemen dienen (z.B. Sensornodes, AccessPoints, PC Bedienersoftware usw.) welche auf unterschiedlicher Basissoftware aufsetzt. Es ist aber nur das vorhanden was benötigt wird, z.B. Anpassungen auf unterschiedliche Prozessoren ist im "Projekt-Repository" nicht mit aufgeführt. Hm. Aber einige Module z.B. Basissystem sind doch für verschiedene Bereich gleich. Die Frage ist, was passiert, wenn in dem Bereich ein Fehler gefunden wird....wenn das Modul dann von 20 Verschiedenen anderen Projekt verwendet wird ? Wie geht man dann mit so einem Fehler um ?
    Wenn alle Projekte das z.B. per external einbinden, dann braucht das Basis Team nur eine neue Release fertig zu machen (tags setzen) und die anderen Teams, die das Module verwenden lediglich den External Verweis zu aktualisieren...

    Auch das kann Vorteile haben, dies Projektbezogen zu ändern Selbstverständlich ....kann man weiterhin...

    MfG
    Karl Heinz Marbaise
    • 18 Nov 2008, 1:05 pm
  • Bernd Augustin
    Bernd Augustin    Premium Member
    The company name is only visible to registered members.
    Re^4: SVN alles in ein Reporsitory oder jedes Projekt sein eigenes
    Während der normalen Entwicklung werden die aktuellen Basissysteme eingepflegt, Da diese parallel mit aufgebaut werden. Ist das Kundenprojekt beendet, würde ich sogar soweit gehen und die Basissysteme als kopie mít in das Kunden-Repository kopieren. Somit ist alles in einem Reporsitory, was auch entsprechend auf CD (mit SVN Programm) archiviert werden kann. Und wenn später Reklamationen kommen, wird das Repository wieder hergestellt, inclusive der SVN Version und es kann normal weitergearbeitet werden, mit dem letzten Stand.


    Der Aspekt, dass die einzelnen Repositories einzeln Administriert werden können, inklusive Skipts ist glaube ich das Hauptargument für getrennte. Da SVN ja noch mit anderen Tools kommuniziert, z.B. automatische Unit - Tests, Dokumentationserstellung usw. können die einzeln konfiguriert werden, und werden nicht ausgeführt, wenn irgend ein Projekt irgendwas eingecheckt wird, was mit den andren gar nichts zu tun hat.

    Weiterhin kann ein bessere Trennung der einzelnen Projekte erfolgen, damit nicht plötzlich beim Kunden ein Programmüberschrift steht „Programm für Mitbewerber geschrieben“.
    • 18 Nov 2008, 2:12 pm