Transcription

Einführung in die SoftwaretechnikKonfigurationsmanagementKlaus Ostermann(mit Folien von Christian Kästner)1Einführung in die Softwaretechnik

AgendaVerteiltes ArbeitenVersionskontrolle}}}}}KonzepteCVS / SVNGitFehlerverwaltung mit Ticket-Systemen}2Einführung in die Softwaretechnik

Softwarekonfigurationsmanagement}Übergreifende Disziplin}Definitionen und ProzesseVersionierung und Konfliktbehandlung FokusPlanung von VariantenDokumentieren von Fehlern und deren siertes }}}3Einführung in die SoftwaretechnikFokus

Kooperation auf gleicher Datei4Einführung in die Softwaretechnik

Technische ZusammenarbeitWo liegen Dateien?}}}}Geänderte Dateien per Email zuschickenManuelles Synchronisieren bei ProjekttreffenAlle Dateien auf gemeinsamen NetzlaufwerkWer darf was?}}}5Pro Datei ist ein Entwickler verantwortlich, nur er darf ändernJeder darf alles ändernEinführung in die Softwaretechnik

Änderungskonflikte6aus „Version Control with Subversion“Einführung in die Softwaretechnik

Konfliktvermeidung durch Sperren7Einführung in die Softwaretechnik

Probleme beim SperrenTechnische Probleme:}}}Technische Sperren vs. Ankündigung auf MailinglisteVergessen zu entsperren typischUnnötige Sequentialisierung der Arbeit:}}Gleichzeitige Änderungen an unterschiedlichen Stellen nichtmöglichFalsches Gefühl von Sicherheit:}}8Zwei Nutzer arbeiten getrennt auf den Dokumenten A und B.Was passiert, wenn A von B abhängig ist? A und B passen nichtmehr zusammen. Die Nutzer müssen dieses Problemdiskutieren.Einführung in die Softwaretechnik

Konfliktlösung durch Mischen (Teil 1)9Einführung in die Softwaretechnik

Konfliktlösung durch Mischen (Teil 2)10Einführung in die Softwaretechnik

Beispiel11Einführung in die Softwaretechnik

Beispiel12Einführung in die Softwaretechnik

Beispiel13in dieSoftwaretechnikSystemEinführungkann nichtautomatischdie Reihenfolge entscheiden

Eigenschaften des Mischens}Ein Dokument liegt in zwei Versionen vor.}}Mischen nicht immer automatisierbar}}}Überlappende Änderungen: KonfliktWerkzeug (diff) zeigt Unterschiede anEin Nutzer integriert beide Versionen manuell (ggf. inAbsprache)In der Praxis: die meisten Änderungen sind konfliktfrei14Einführung in die Softwaretechnik

Verwalten von Projekten15Einführung in die Softwaretechnik

Revisionen und Varianten}}}Revisionen ersetzen frühere Revisionen (Zeitlich)Varianten koexistieren mit anderen Varianten (Inhaltlich)Version als OberbegriffBasissystem r-VarianteErweiterung für Kunde AErweiterung für Kunde BXXXXXX

Code und Nicht-Code Dateien}Java CodeDokumentationModelleBuild-Scripte: Ant/MakefileLizenzenGrammatikenKompilierte DateienHTML, JavaScript, CSS}Bei Binärdateien ist Konfliktbehandlung schwieriger}}}}}}}17Einführung in die Softwaretechnik

Revisionen von Projekten18Einführung in die Softwaretechnik

Versionsverwaltung}}Versionierung von QuelltextdateienRepository: Archiv alter Quelltextversionen}}}}}}Zeitstempel und BenutzerkennungTags: Benannte Revisionen z.B. Release 1 0Änderungen als DeltaTypisch: Kommentar beschreibt ÄnderungJederzeit Änderungen nachvollziehenAlte Versionen wieder herstellbar

Revision HistoryAus Eclipse Quelltext: org.eclipse.jdt.ui20Einführung in die Softwaretechnik

Release}Release identifiziert veröffentlichte ProduktversionJava 1.6.0 15Eclipse Platform SDT 3.5.2.M20100211-1343}Typisches Muster:}}}}}}}Hauptreleasenummer: Signifikante ÄnderungenNebenreleasenummer: FunktionserweiterungenRevisionsnummer: FehlerbehebungenBuildnummer: weitere DetailsRelease 0.x für Beta-Releases (vorab)Release-Versionen oft unabhängig vonRevisionsnummernTags markieren Releases21Einführung in die Softwaretechnik

Branches (Verzweigen)}Kopie des QuelltextWird getrennt versioniertKann wieder zusammengefügt werden (merge)}Typisches Vorgehen}}}}}}22Hauptbranch für Wartung oder HauptentwicklungNeuer Branch für experimentelle Funktionalität, wirdzusammengefügt wenn erfolgreichNeuer Branch für WartungsaufgabenTeils neuer Branch für VariantenEinführung in die Softwaretechnik

Branches – Beispiel

Varianten und Revisionen[Staples&Hill, APSEC’04]

Variantenmanagement}Variantenerstellung durch Branches skaliert nichtSpezielle Mechanismen oder Werkzeuge benötigtKomplexität muss geplant werden}Viele rBuild-SystemSpezielle Sprachen Analog Abhängigkeiten vonMerkmalen oder Kunden- Softwareproduktlinien25Einführung in die Softwaretechnik

Versionsverwaltungssysteme}}Systeme für Sperren und Mischen verfügbarLokale Versionsverwaltung}}}Zentrale Versionsverwaltung}}}}Lokale Archivierung (meist einzelner) DateienBeispielsysteme: SCCS und RCSRevisionen liegen auf zentralem ServerClients erfragen Updates, senden ÄnderungenBeispielsysteme: CVS, SVN, Perforce, Visual SourceSafeVerteilte Systeme}}26Verteilte Repositories (mit allen bekannten Revisionen) diesynchronisiert werden könnenBeispielsysteme: Git, Mercurial, ClearCaseEinführung in die Softwaretechnik

CVS / SVN27Einführung in die Softwaretechnik

CVS und SVN}}Zentrale VersionsverwaltungssystemeCVS seit 1990, SVN als inoffizieller Nachfolger seit 2004}Ein zentrales RepositoryBenutzer erstellen lokale KopieÄnderung der lokalen Kopie, Abgleich mit RepositoryUpdate – Commit Zyklen}Unterstützt Branches und Tags}Zentrale Rechteverwaltung}}}28Einführung in die Softwaretechnik

Typischer Arbeitszyklus}Einmalig: Projekt lokal anlegen}}Arbeitskopie auf den neuestenStand bringen:}}}}}svn addsvn deletesvn copysvn moveÄnderungen prüfen:}}29}svn updateÄnderungen an der Ordnerstruktur durchführen:}}svn checkoutÄnderungen zurücknehmen(optional):}}}svn revertKonflikte auflösen:}svn update}svn resolvedÄnderungen in das Repositoryeinlesen:}svn commitsvn statussvn diffEinführung in die Softwaretechnik Taentzer

CVS vs. SVNCVS}}}SVNRevisionsnummer proDateiTextdateien (Binärdateienmögl.)Weiter verbreitet}}}}}30Revisionsnummer fürganzes ProjektAtomare Commits: alleDateien oder keineDateien und VerzeichnisseUmbenennungenMetadaten möglich undversioniertEinführung in die Softwaretechnik

Git31Einführung in die Softwaretechnik

Git}}}Verteilte VersionsverwaltungKein zentraler Server nötigKopie des gesamten Repository lokal}}}}Lokale Funktionalität ähnlich SVN (update, commit, branches,diff)Nicht-lineare Entwicklung: Spezieller Fokus auf verteiltesVerzweigen und MischenDatenabgleich zwischen Repositories möglichHohe Geschwindigkeit bei commit/diff/revert/ , da alleDaten lokal32Einführung in die Softwaretechnik

Übersichtclone, push, pullcheckout / updatecommit33Einführung in die Softwaretechnik

Verteilte Revisionen}}Revisionen nicht global koordiniert/sortiertRevisionen und Branches global eindeutig durch HashIDs}}Clonen eines Repositories jederzeit möglich}}}}}z.B. 52a0ff44aba8599f43a5d821c421af316cb7305Merkt sich Ursprung (wichtig für Updates und Merging)Normale Checkout/Commit OperationenCommits möglich ohne ursprüngliches Repository zu ändernFetch und Pull-Operationen holen Updates ausentfernten Repositories (auch mehreren!)Push-Operation kopiert lokale Änderung zu entferntemRepository (wenn Rechte vorhanden)34Einführung in die Softwaretechnik

BeispielKernel-Entwicklercheckout / updateclone / pullLinuxLinuxcommitpusheditpull & mergeclonecheckoutLinuxcommitNeuer Entwickler35Einführung in die Softwaretechnikedit

Repositories in mustache.jsmustache.js Projekt36Einführung in die Softwaretechnik

Beispiel Revisionshistorie37Einführung in die Softwaretechnik

Zentrale Repositories weiterhin möglich Scott Chacon Buch “Pro Git”38Einführung in die Softwaretechnik

“Social Coding” mit Github u.ae.39Einführung in die Softwaretechnik

Ticket-Systeme40Einführung in die Softwaretechnik

Wie verwaltet man Fehlermeldungen?}Sofort bearbeitenEmail-/Text-/ZettelsammlungKommentare im QuelltextWiki}Typische Fragen:}}}}}}}}41Organisation?Wer ist verantwortlich?Hat sich jemand darum gekümmert?Ist es noch aktuell?Welche Module sind besonders fehleranfällig?Einführung in die Softwaretechnik

Ticket-Systeme}}}}}}}Speichern Fehlermeldung in zentraler DatenbankMeta-InformationenIn Open-Source-Projekten typischerweise öffentlichFehler können Gruppen/Listen/Personen zugeordnetwerdenPrioritäten setzenFortschritt wird protokolliertAlle Änderungen nachvollziehbar42Einführung in die Softwaretechnik

Bugzilla für Eclipse43Einführung in die Softwaretechnik

Beispiel44Einführung in die Softwaretechnik

Vorgehen (grob)}}}}}}}Fehlermeldung kommt anAufnehmen als Ticket (Status: new, Priorität setzen)Prüfen ob der Fehler wirklich auftritt (Status: confirmed)Projektmanager weist Ticket passendem Entwickler zu(Status: assigned)Entwickler stellt ggf. Rückfragen oder gibt das TicketweiterEntwickler entfernt Fehler und schließt das Ticket (Status:closed, Resolution: Fixed / Duplicate / Invalid / Won’t Fix)Ggf. release neue Version, Information an Kunden45Einführung in die Softwaretechnik

Nicht nur Fehlerverwaltung (Issue Tracking)}}}}}}Offene ische Ticketgenerierungvon AlarmsystemenJeweils mit Möglichkeit zur}}}46DiskussionPriorisierenProtokollierung von Zuständigkeiten und FortschrittEinführung in die Softwaretechnik

Ticket-Systeme als Kontrollwerkzeug}}Erzwing vordefinierte Vorgehensprozesse (Workflows)Alle Änderungen werden protokolliert}}}}Erlaubt diverse StatistikenBearbeitungsdauer und –QualitätWelche Module sind besonders Fehleranfällig}}}z.B. wer hat wann die Priorität geändertggf. hilfreich bei UrsachenforschungSammeln von häufigen Fragen (FAQs)Nachvollziehbarkeit für Kunden47Einführung in die Softwaretechnik

IDE Integration: Eclipse Mylyn}}}Zeigt Tickets direkt in Eclipse anIntegration mit VersionsverwaltungAutomatische Kontextverwaltung48Einführung in die Softwaretechnik

Software49Einführung in die Softwaretechnik

Server?}Viele kostenlose Angebote für (Open-Source) comcode.google.com Web-OberflächeOft mit Bug-TrackerAufsetzen eines eigenen Servers gut dokumentiertsiehe auch http://en.wikipedia.org/wiki/Comparison of open source software hosting facilities50Einführung in die Softwaretechnik

Clients?}}KommandozeilenwerkzeugeGraphische Benutzeroberflächen, z.B.}}}}Integration in IDEs, z.B.}}}}TortoiseCVS/SVN/Gitgitk, gigglerapidsvnNative CVS Unterstützung in EclipseSubversion Plugin für SVNEGit Plugin für GitWebfrontends für Lesezugriff51Einführung in die Softwaretechnik

Ticket-Systeme}}}}}BugzillaTracSAP CRMLassen sich mit VersionsverwaltungssystemenkombinierenIn SourceForce, Assembla, Github, etc. mit angeboten52Einführung in die Softwaretechnik

Zusammenfassung}Revisionen und VariantenVerzweigung und Behandeln von KonfliktenVerteilte Versionsverwaltung}Fehlerverwaltung mit Ticket-Systemen}}53Einführung in die Softwaretechnik

Probleme beim Sperren 8 Einführung in die Softwaretechnik } Technische Probleme: } Technische Sperren vs. Ankündigung auf Mailingliste } Vergessen zu entsperren typisch } Unnötige Sequentialisierung der Arbeit: } Gleichzeitige Änderungen an unterschiedlichen Stellen nicht möglich } Falsches Gefühl von Sicherheit: } Zwei Nutzer arbeiten getrennt auf den Dokumenten A und B.