Obejct Oriented SCM - OOSCM
Download as PPTX, PDF0 likes602 views
The document discusses motivations for developing a new object-oriented software configuration management (OOSCM) tool. Current SCM tools do not adequately support object-oriented development or track changes at the method and class level. The proposed OOSCM tool would better manage the change lifecycle, integrate changes intelligently, support upgrades and refactorings, and model a system's architecture and evolution over time. It is being developed in Pharo Smalltalk with the goal of also supporting Java and other languages.
Obejct Oriented SCM - OOSCM
- 1. agile software development & services OOSCM Object Oriented SCM SCM Next Generation
- 2. We’d like to declare… Barcelona The SCM Conference
- 3. Why? ▶ Colin Putney’s Monticello 2 – “Merging is the most important feature of an SCM” ▶ Veronica Urquillaz-Gomez – Torch: Code review before integration ▶ Fernando Olivero – Reify the programmer an his “unit of work” ▶ Dale Henrichs and Mariano Martinez Peck – Metacello ▶ And at the same time as this talk Alan Knigth – Taking about Store
- 4. We NEED a BETTER SCM tool
- 5. What are we going to talk about OOSCM ▶ A new SCM concept ▶ WHY? – Current tools do not fulfill our goals – Current tools have conceptually different approaches to solve SCM that our idea – We want to promote Smalltalk
- 6. Motivation 1 ▶ I want to know – where a change was integrated – By who and when – On what versions – What were the changes made to that code during integration – Provide feedback to the programmer at all levels (method, class, etc)
- 7. Motivation 2 ▶ Did all the test run after implementing that change? – The programmer should run all tests before submitting the change to integration ▶ Does the change provide new tests?
- 8. Motivation 3 ▶ We don’t want this to be an integration conflict Object subclass: #Class1 instanceVariableNames: ‘’ Object subclass: #Class1 instanceVariableNames: ‘a’ Object subclass: #Class1 instanceVariableNames: ‘b’ V1 V1.1 V1.2 Integration Conflict!
- 9. Motivation 4 ▶ I want the decisions I made during the pre- integration code review to be applied during integration – Reformat the code – Do not integrate this method
- 10. Motivation 5 Baseline Integration 1.2 -unit -amount -asMeters -convertTo: aDistanceUnit DistanceMeasure 1.0.0 -unit -amount -asMeters -convertTo: aDistanceUnit Measure 1.0 -unit -amount -asMeters Measure 1.1 -unit -amount -asMeters DistanceMeasure method added class renamed
- 11. Motivation 6 ▶ Seaside releases version 3.1 that includes lots of method renames – I want the system to tell me there is a new version – I decided Patagonia should work with seaside 3.1!! • I can’t because I have to do the rename myself in Patagonia! • Why not applying those renames to Patagonia automatically?
- 12. Motivation 7 ▶ How do I know if programmers are doing TDD or just testing? – Writing the test first really ▶ How do I know the system architecture and its evolution? – Maven in Java, but can not see its evolution or internal architecture, only dependencies.
- 13. What can we do with the current tools?
- 14. Traditional SCM Requirements Traditional SCM (SVN, Git, etc) MANAGE CHANGE LIFECYCLE NO CHANGE QUALITY NO SMART AUTOMATIC INTEGRATION NO PRE-INTEGRATION TOOLS NO AUTOMATIC REFACTORING INTEGRATION NO AUTOMATIC UPGRADE NO QUERY THE REPOSITORY NO (there is no model)
- 15. Traditional SCM ▶ Archive oriented: Archive is the minimun trackeable item – Between commit changes are lost! (lost of information) – Not easy to track group of changes ▶ No reification of what a module is, what a system is, etc. Just files and directories ▶ Not easy to model the development process – It has to be defined from outside the tool ▶ Good for versioning files, not so for OO development ▶ Advantages: – Simple interface – Can work offline
- 16. Monticello/Metacello Requirements Monticello/Metacello MANAGE CHANGE LIFECYCLE NO CHANGE QUALITY NO SMART AUTOMATIC INTEGRATION Medium PRE-INTEGRATION TOOLS Torch AUTOMATIC REFACTORING INTEGRATION NO AUTOMATIC UPGRADE NO QUERY THE REPOSITORY Yes (But limited to the info it stores)
- 17. Monticello / Metacello ▶ As traditional SCM, only “commits” are saved – Between commit changes are lost ▶ Metacello helps to model the system architecture ▶ But it does not help to – model the development group – Integrate different development lines – See the integration history (evolution) ▶ Advantages: – Simple – Can be use offline – Metacello provides tools that allow to use it easily
- 18. Store * Requirements Store MANAGE CHANGE LIFECYCLE NO CHANGE QUALITY NO (could be added) SMART AUTOMATIC INTEGRATION Not sure PRE-INTEGRATION TOOLS Medium AUTOMATIC REFACTORING INTEGRATION NO AUTOMATIC UPGRADE NO QUERY THE REPOSITORY Yes (But limited to the info it stores) * We do not have experience with Store, so this could be wrong
- 19. ENVY Requirements ENVY MANAGE CHANGE LIFECYCLE NO CHANGE QUALITY NO (could be added, in fact we did it) SMART AUTOMATIC INTEGRATION NO (we did it) PRE-INTEGRATION TOOLS Three way Differences AUTOMATIC REFACTORING INTEGRATION NO AUTOMATIC UPGRADE NO QUERY THE REPOSITORY Yes * ▶ New objects can be added to the repository
- 20. ENVY ▶ Trackable items are methods, classes, modules (application) and systems (configuration maps) ▶ Between commit (versioning) changes are saved ▶ Easy to see method, class and module history ▶ Not so easy to see the system history ▶ Kind of difficult for agile development (unless you remove security, etc) ▶ No reification of programmers changes ▶ No automatic integration (unless you develop it)
- 21. ENVY ▶ Disadvantages: – Proprietary – Old server technology – Complex implementation – Only for Smalltalk ▶ The best one we have used so far
- 26. Change Quality
- 27. Change Quality
- 28. Change Quality
- 33. OOSCM Goals ▶ SCM oriented to development with Objects – Paradigm shift from traditional SCM ▶ Easy to track programmers work ▶ Easy to track system evolution – Be able to model system architecture ▶ Automatic Integration – Smart – Easy to integrate complex changes (i.e. refactorings) ▶ Upgrades – Automatic upgrading ▶ Not only for Smalltalk: – Planned: Java with Eclipse – Open to other languages
- 34. Architecture ▶ Client-Server ▶ REST ▶ Multi-repository ▶ Offline support ▶ IDE Client: Plug-In Architecture ▶ WebBrowser support
- 35. Details ▶ Technology: – Developed with Pharo – Production: GLASS ▶ Project: – Subsidy of the Argentine Ministry of Technology (USD 38 K) – Total time: 13 months (with out refactoring integration) – We just started ▶ License: – Not sure, open client, close server? – Open for Smalltalk, paid for other languages? – Based on projects, customers, SaaS?
- 36. Suggestions – Help – Support - Ideas
- 37. agile software development & services Thank you! info@10pines.com www.10Pines.com twitter: @10Pines Hernan Wilkinson hernan.wilkinson@10pines.com Jorge Silva jorge.silva@10pines.com