Transcription

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

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

Kooperation auf gleicher Datei3Einführung in die Softwaretechnik

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

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

Konfliktvermeidung durch Sperren6Einfü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: 7Zwei 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)8Einführung in die Softwaretechnik

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

Beispiel10Einführung in die Softwaretechnik

Beispiel11Einführung in die Softwaretechnik

Beispiel12in 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 konfliktfrei13Einführung in die Softwaretechnik

Verwalten von Projekten14Einfü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 16Einführung in die Softwaretechnik

Revisionen von Projekten17Einfü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.ui19Einfü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 Releases20Einführung in die Softwaretechnik

Branches (Verzweigen) Kopie des QuelltextWird getrennt versioniertKann wieder zusammengefügt werden (merge) Typisches Vorgehen 21Hauptbranch 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 Lösungen ielle Sprachen Analog Abhängigkeiten vonMerkmalen oder Kunden- Softwareproduktlinien24Einfü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 25Verteilte Repositories (mit allen bekannten Revisionen) diesynchronisiert werden könnenBeispielsysteme: Git, Mercurial, ClearCaseEinführung in die Softwaretechnik

CVS / SVN26Einfü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 27Einführung in die Softwaretechnik

Typischer Arbeitszyklus Einmalig: Projekt lokal anlegen Arbeitskopie auf den neuestenStand bringen: svn updateÄnderungen an der Ordnerstruktur durchführen: svn checkoutsvn addsvn deletesvn copysvn moveÄnderungen zurücknehmen(optional): Konflikte auflösen: svn revertsvn updatesvn resolvedÄnderungen in das Repositoryeinlesen: svn commitÄnderungen prüfen: 28svn statussvn diffEinführung in die SoftwaretechnikTaentzer

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

Git30Einfü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 lokal31Einführung in die Softwaretechnik

Übersichtclone, push, pullcheckout / updatecommit32Einfü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 aus entferntenRepositories (auch mehreren!)Push-Operation kopiert lokale Änderung zu entferntemRepository (wenn Rechte vorhanden)33Einführung in die Softwaretechnik

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

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

Beispiel Revisionshistorie36Einführung in die Softwaretechnik

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

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

Ticket-Systeme39Einführung in die Softwaretechnik

Wie verwaltet man Fehlermeldungen? Sofort bearbeitenEmail-/Text-/ZettelsammlungKommentare im QuelltextWiki Typische Fragen: 40Organisation?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 nachvollziehbar41Einführung in die Softwaretechnik

Bugzilla für Eclipse42Einführung in die Softwaretechnik

Beispiel43Einfü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 Kunden44Einführung in die Softwaretechnik

Nicht nur Fehlerverwaltung (Issue Tracking) Offene ische Ticketgenerierungvon AlarmsystemenJeweils mit Möglichkeit zur 45DiskussionPriorisierenProtokollierung 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 Kunden46Einführung in die Softwaretechnik

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

Software48Einführung in die Softwaretechnik

Server? Viele kostenlose Angebote für (Open-Source) Projekte om Web-OberflächeOft mit Bug-TrackerAufsetzen eines eigenen Servers gut dokumentiertsiehe auch http://en.wikipedia.org/wiki/Comparison of open source software hosting facilities49Einfü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 Lesezugriff50Einführung in die Softwaretechnik

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

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

Probleme beim Sperren 7 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.