Ankündigung

Einklappen
Keine Ankündigung bisher.

Release Management

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Release Management

    Hallo zusammen,

    ich fange gerade damit an, mich mit Release Management zu beschäftigen. Jetzt bin ich auf der Suche nach einer geeigneten Strategie, um den vorhandenen Ablauf zu optimieren.

    Erstmal die Voraussetzungen:
    - Zur Code-Versionierung wird SVN verwendet
    - Zum Deployment soll ANT verwendet werden (der alte Ablauf basiert darauf)
    - Vor dem Deployment wird alles mit einem Encoder "verschlüsselt"
    - Die Versionsnummer ist immer ein Major-Release + Service-Pack + Patchlevel (also beispielsweise 5.4.9)
    - Die Versionsnummer, Service-Pack und Patchlevel sind immer vergeben (5.4.0, 5.4.1, etc.)
    - Es existiert immer eine aktuell freigegebene Version (Stable) und hin und wieder soll eine BETA erstellt werden, damit sie getestet werden kann

    Aktuell ist der Ablauf grob so:
    - Für jedes Major-Release wird ein Branch erstellt (z.B. 5.4.0)
    - Aktuelle Entwicklungen des Trunk werden in den Branch gemerged, sofern es sich nicht um komplette Neuentwicklungen handelt
    - Merge wird getestet
    - Nach dem erfolgreichen Test wird der Patchlevel wird erhöht (5.4.1)
    - Release wird ersetzt

    Um das ganze zu automatisieren, habe ich mir folgendes überlegt:
    - Für jedes Release wird ein Branch mit Major-Release+Service-Pack erstellt (z.B. 5.4)
    - Die stable-Revision wird mit 5.4_stable getagged
    - Die zu testenden Änderungen werden gemerged
    - Sobald die Tests erfolgreich waren, wird die entsprechende Revision nach dem Merge mit 5.4_stable getagged
    - Gebaut wird immer der 5.4_stable Tag, es sei denn, ich gebe irgendwie mit, dass ich eine Beta brauche


    Ist das eine sinnvolle Strategie? Und kann ich ALLE stable-Tags (*_stable) auslesen und immer den mit der höchsten Nummer bauen lassen?
    Fynder - http://www.fynder.de - Tutorials zum Thema Technik


  • #2
    Hi,

    im Prinzip (mit Ausnahme der Code-Verstümmelung) klingt das wie die Vorgehensweise bei uns im Team.

    Im svn-Rootdir findest du ein hooks-Verzeichnis. Dort das post-commit.tmpl dementsprechend erweitern, ein paar Beispiele findest du hier:

    http://stackoverflow.com/questions/4...-been-commited

    Wenn das auf einem linux system läuft, kannst du den Verzeichnisnamen per regex bspw. auf "_stable" testen, a la

    Code:
    case $DIR in   
    *_stable*) echo "stable version";   
    *) echo "non stable version"
    Wenns ein *nix system ist, würd ich (aber das ist meine persönliche Meinung) auf make umsteigen, gefühlt ist das um einiges schneller beim Projekte bauen.

    Ansonsten wird bei uns auch Hudson verwendet, aber davon hab ich (noch) keine Ahnung.


    Viele Grüße


    Basti
    I like cooking my family and my pets.
    Use commas. Don't be a psycho.
    Blog - CoverflowJS

    Kommentar


    • #3
      Kennt jemand von euch erfahrenen Usern ein gutes, professionelles Tutorial um sich in die SVN Geschichte einzulesen?

      Wichtig ist, dass es mind. eine gute Basis ist und die Informationen daraus alle korrekt sind.
      (Vgl. PHP Anfängertutorials, wo manchmal Schwachsinn geraten wird)

      Kommentar


      • #4
        Ich würde Dir gleich zu Mercurial oder git raten.

        http://hgbook.red-bean.com/read/

        http://book.git-scm.com/index.html
        http://de.whygitisbetterthanx.com/

        Btw. Dein erster Anlaufpunkt sollte immer der Referenzteil der Wikipedia sein.

        http://svnbook.red-bean.com/
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          wir nutzen im team mercurial, hat einfach den grund, dass die gui recht einfach ist und so unerfahrende entwickler schneller damit klar kommen. privat nutze ich git.

          Kommentar


          • #6
            Du meinst dann vermutlich Tortoise Hg, oder? Für GIT gibts IMHO auch was von Tortoise. Und für SVN auch.
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar


            • #7
              tortoisehg (für mercurial) ist brauchbar (besonders die alte version > 2), für git leider völlig unbenutzbar. die mir bekannten git gui's sind völlig unbrauchbar. gittower soll gut sein, existiert jedoch nur für den mac uns ist relativ teuer.

              insbesondere wenn ihr relativ neu im umgang mit der materie seit, oder ein team habt, welches bis dato wenig erfahrung damit gemacht hat, würde ich euch mercurial wirklich empfehlen. ist sehr effektiv, intuitiv und nach git das mächtigste vcs welches ich kenne/nutze,

              Kommentar

              Lädt...
              X