© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-1
PVG (EDAF45) - lecture 3:Konfigurationshantering
Ulf Asklund/Lars Bendix
Department of Computer ScienceLund Institute of Technology
Sweden
PVG lecture 3, CM for XP
Agenda…
• CM-grunder– CM finns ”överallt”– Varför CM?– Olika målgrupper för CM
• Traditionell CM• CM-aktiviteter
• CM för utvecklare• CM för XP
• Versionshanteringsmodeller• CVS• git
PVG lecture 3, CM for XP
Denna vecka – Läsvecka 4
F3: Konfigurationshantering, mån 20 nov, 8:15-10:00, E:B (Gästföreläsare: Ulf Asklund)• Häftet: Utdrag ur bok av Babich: Software Configuration Management - Coordination for Team
Productivity.• Chromatic: Delar av Part II (XP Practices):
– p. 18-20 (Refactor Mercilessly)– p. 32-36 (Adopt Collective Code Ownership, Integrate Continually)– p. 41-42 (Release Regularly)
• Häftet: Utdrag ur bok av Jeffries et al: Extreme Programming Installed. Delar av Kap 11 + 15.• F3-OH-bilder (pdf)
Labb 2: Versionshanteringssystem, ons/tors 22/23 novFörbered dig inför labben genom att:• Gå igenom materialet för F3 enligt ovan.• Skapa ett Bitbucket-konto (Skapa Bitbucket-konto.pdf)Titta igenom dessa två youtube-klipp (du kommer göra motsvarande under själva labben):
– Kort inspelning om git (Bitbucket) och Eclipse– Kort inspelning om konfliktslösning
Labbhandledning labb 2: versionshantering med git. (pdf)
PVG lecture 3, CM for XP
What is SCM?
Software Configuration Management:is the discipline of organising, controlling and managing the
development and evolution of software systems. (IEEE, ISO,...)
The goal is to maximize productivity by minimizing mistakes. (Babich)
Det går inte att visa den här bilden just nu.
Management
Det går inte att visa den här bilden just nu.
Developer
PVG lecture 3, CM for XP
Building on sand?
Software Configuration Management
Req. Coding QATestingDesign
CM is a CMM level 2 key process area
PVG lecture 3, CM for XP
ConfigurationIdentification
ConfigurationControl
ConfigurationStatus Accounting
ConfigurationAuditing
CM activities
Release Management
PVG lecture 3, CM for XP
CM - Configuration Identification
Det
Baseline
Plan
EMWXXX
Identify
Structure
Det går inte att visa den här
Document
PVG lecture 3, CM for XP
CM - Configuration Control
• Change management• Traceability
PVG lecture 3, CM for XP
Configuration Control
Change Request (CR) Process
Document
CCB
Verify
Implement
Approve
Disapprove
Changeproposal
Evaluate
PVG lecture 3, CM for XP
The goal of CM - Change tracking
Oh some great new features!We have XGML support, and new cool color sets...
What has changed from release 3 to the new release 3.5 that we got now?
Customer Developmentproject
• File a.java is new
• File b.java altered line 35, added line 147 – 163
• File c.java was removed
CR 17CR 24
CR 32
• Bug fixes• Enhancements• New features
PVG lecture 3, CM for XP
CM - Configuration Status Accounting
Status Accounting
PVG lecture 3, CM for XP
CM - Configuration Auditing
Functional AuditPhysical Audit
PVG lecture 3, CM for XP
Release Management
Release Management
“Which configurations does this customer have?”
“Did we deliver a consistent configuration?”
“Did the customer modify the code”
“How exactly was this delivery configuration produced?”
“Were all regression tests performed on this system delivery version?”
“Did we deliver an up-to-date binary version to the customer?”
PVG lecture 3, CM for XP
Release Management
Ver 1
Products
Doc
PVG lecture 3, CM for XP
Delivery
Customer records
Productdocumentation
Education
Support
The need for CM - The maintenance phase
Manuals
PVG lecture 3, CM for XP
The goal of CM - Software deployment
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-17
SCM for XP development
Support and help for:• handling source code• collective ownership• simple integration• painless refactoring• ease of testing• effortless releasing• handling document(ation)
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-18
How does a programmer spend his time?
• 50 % interacting with other team members
• 30 % working alone (pair-programming??)
• 20 % non-productive activities
Common heritage is the reason:• sharing things• memory/history• communication• co-ordination
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-19
Problems of co-ordination
Shared data
Double maintenance
Simultaneous update
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-20
Co-ordination
Working in isolation:• local dynamicity• global stability• problem:
- multiple maintenance
Working in group:• global dynamicity• problems:
- shared data- simultaneous update
PVG lecture 3, CM for XP
Configuration ManagementStrategies - Models - Tools
PVG lecture 3, CM for XP
Concurrent development
optimistic
conservative
PVG lecture 3, CM for XP
Developing Strategy
optimistic
conservative
PVG lecture 3, CM for XP
Update Strategy
optimistic
D
conservativeD
early integration
work in peace (isolation)
PVG lecture 3, CM for XP
Models
• Turn-taking
• Split-combine
• Copy-merge
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-26
Immutability principle
Principle: components are immutable
copy
add
edit
database
localworkingcopies
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-27
Working
update
commit
Project repository Private/pair workspace
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-28
Copy/merge work model
Can we lock the things we want to work on? NO!
So we copy everything to our workspace......and everyone else copy to their workspaces...Þ double maintenance !!
o
Fortunately ”update” has a built-in merge facility:• We first merge from the repository into the workspace• Then we check and fix problems• Finally we commit (add) to the repository
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-29
• Overall CVS (and CM) was a HUGE help for the project.• The version history was a real life saver.• CVS made it possible for 12 people to work on the same
code at the same time.• CVS rules!• It would have been impossible to merge different
people’s work without it.• CVS sucks!• Branching made releasing much easier.• We tagged the releases – it served it’s purpose.
Quotes from XP’ers
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-30
So how is CM used?
• update-commit• merge – merge – merge• no versioning, diff, tag, …• change log only to identify people
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-31
Long transactions I
Lars
Checkout
Ulf
Checkout
Repository
workspace creation
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-32
Long transactions II
Repository
UlfLars
update
commit commit
workspace usage (termination)
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-33
Unfortunately :-(
Repository
UlfLars
commit commit
NO strict long transactions - so...
PVG lecture 3, CM for XP
Distributed version control
Repository
UlfLars
commit update/merge
Yes, strict long transactions (push/pull)
Repository
commit update/merge
Repository
push
fetch push
fetch
PVG lecture 3, CM for XP
git - BitBucket
Repository
UlfLars
commit update/merge
Yes, strict long transactions (push/pull)
Repository
commit update/merge
Repository
push
fetch push
fetch
BitBucket - cloud
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-36
Extreme programming
SCM-related practices:• collective ownership (developer)• continuous integration (developer)• refactoring (coding)• small releases (business)• planning game (business/developer)• test-driven development (developer)
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-37
Collective code ownership
Goal: to spread the responsibility for the code to the team
How/why:• from individual (pair) to team ownership• reinforces code review (and readability)• enables refactoring
Requires:• team spirit• frequent integration
SCM dangers:• huge merge conflicts
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-38
Integrate continually I
Goal: to reduce the impact of adding new features
How/why:• ”download” & ”upload” integration• run tests; update (merge); re-run tests; commit• all components must be in repository• integration machine/responsibility/how often?• keeps everyone in synchronisation• keeps the project releasable all the time
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-39
Integrate continually II
Requires:• collective source code repository• short tasks
SCM dangers:• merge conflicts
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-40
Goal: to find the code’s optimal design
How:• before & after a task, think about refactoring• changes the structure, but not the behaviour• break out code; remove duplications; …
Requires:• collective code ownership• coding standards
SCM dangers:• big-bang refactorings
Refactor mercilessly
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-41
Release regularlyGoal: to return the customer’s investment often
Why/when/how:• two-way feedback• at the end of each iteration (daily?)• clean machine principle• automating and optimising the release
Requires:• continuous integration
SCM dangers:• manual process takes time• a broken release :-(
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-42
Play the Planning GameGoal: to schedule the most important work
Why/how:• to maximize the value of features produced• divides planning responsibilities (what/how)• developers estimate user stories• developers split stories up into tasks
Requires:• active customer• mutual respect
SCM dangers:• sloppy estimates and work break-down
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-43
XP process1. Always start with all of the “released” code.2. Write tests that correspond to your tasks.3. Run all unit tests.4. Fix any unit tests that are broken.5. When all unit tests run, your local changes become
release candidates.6. Release candidate changes are integrated with the
currently released code.7. If the released code was modified, compare the
differences and integrate them with your changes.8. Rerun tests, fix, rerun tests, fix, rerun ….9. When the unit tests run, release all of your code, making
a new official version.
© Lars Bendix - Lund Institute of Technology PVG lecture 3, CM for XP
F3-44
Diffing and merging
1.1 1.2 2.1 2.2 3.1
1.2.1.1
Visualisation of differences:• diff
Merging of branches:• merge• always control manually that things went well
Top Related