Spree Conf 2013

Clarke and Gregor's slides from their talk at Spree Conf 2013.

Transcript

1. Large Scale Migrations to Spree By Clarke Brunsdon And Gregor MacDougall Freerunning Technologies
2. Us • Gregor MacDougall – 14+ Years programming – Passionate about high-quality software – Focused on providing value through code • Clarke Brunsdon – 14+ Years programming – Passionate about high-quality software – Focused on providing value through code
3. Us (Cliff Note) • Gregor MacDougall – Has Long Hair – Drinks no beers • Clarke Brunsdon – Has short Hair – Drinks All The Beers
4. FreeRunning Technologies • Visit us at http://freerunningtech.com • contact@freerunningtech.com
5. “By the time you've heard about us, your life sucks”
6. Small Store Migration Plan
7. New Client, Same Story • Usual Problems – 500 server errors – Falling sales – Angry customers – High Developer Turnover • Awesome business – Runs dozens of e-commerce sites selling goods and software worldwide. – Big revenue, awesome people. Damn, thats a lot of problems.
8. Phase One: Investigation! • Do a company inventory – Technology – People – Business Practices • Get a good idea of what everyone does thats involved in the system • Verify every claim you hear
9. Frontend Sites
10. Custom PHP Cart
11. C++/qt Custom Template Editor/language
12. PHP Custom Mail server
13. Custom PHP DNS Server
14. Custom PHP SSH Implementation
15. When you have a hammer in your hand, everything looks like a nail • Someone taught them to code – This was arguably a bad idea.
16. No more hammer time.
17. Spree Logo Here
18. Spree To Most People
19. Focused Product Stores
20. Many stores, One/Many products
21. The Greenfield Plan
22. One big Re-Write == One Big Waste of Time • This is a real world company with 7 years of technical debt out there. • Even if the re-write was 100% guaranteed success (pause for laughter), there are countless business obligations and reasons to improve your existing systems.
23. Cupcake Assembly line
24. Replace Assembly Line
25. Bypass Assembly line!
26. Retain Compatibility • A/B Test • Scalability test • “Special” Cases don't need to be handled by both systems right off the bat • Ability to revert back to the old code at the press of a button
27. Remove old component!
28. Step One: Venn Diagram Stuff Your System Does Stuff Spree Does
29. Step Two: Decisions! • Every feature in the old system: – Should we cut it? – Should we port it?
30. When to cut functionality • No one uses it • Broken/incorrect information • There are better alternatives • Cut the functionality if it will not make or save more money that it would cost to port it
31. **CAUTION** SPREE MIGHT NOT FIT YOUR NEEDS
32. Ways to port your software to Spree 1. Pull request back to core 2. Add Code to Your App 3. Extension in Spree
33. When to write a pull-request to the main Spree repository • If this is something that many people would like to have • If the Spree core team agrees it is a good idea • If it won't break existing functionality
34. When you MUST write a pull- request to the Spree repository • When the functionality is required through the entire process.
35. Huzzah, Spree! • Luckily for us these are all awesome people
36. Multi-Currency • Added in Spree 1.3 • Adds the concept of currencies all over the place (Spree::Order, Spree::Price, Spree::Variant) • If its caused you issues, blame gmacdougall.
37. Ways to port your software to Spree 1. Pull request back to core 2. Add Code to Your App 3. Extension in spree
38. When to add code to your app • Very specific to your domain • Interacts with non-spree models • “glue code” for your legacy application
39. Syncronizing Data
40. Syncronizing Data
41. But it looks roughly like this
42. Ways to port your software to Spree 1. Add Code to Your App 2. Pull request back to core 3. Extension in Spree
43. When to write an extension • It's not tied to your domain • Its code that some other people would want to use • Extracting to Spree environment simplifies the situation
44. Spree_License_key • Delivers electronic “software activation keys” to customer once an order is complete. • Licenses are stored in the database • Can deliver different number of keys for different products • https://github.com/freerunningtechnologies/spree-license-key
45. Other Extensions • spree_pre_order • spree_flexible_weight_rate • spree_multi_domain (*by spree team) • spree_custom_store_email • spree_ban_users • spree_kana
46. **CAUTION** Monkey Patching Considered Harmful?
47. Extension Code Example
48. Extension Code Example (pt. 2)
49. Extension Code Example (pt. 3)
50. • Short Answer – One of them doesn't work • Long answer – We need a better solution than monkey-patching classes
52. Major change can happen while preserving existing functionality
53. WARNING • This is a big undertaking.
54. Encouragement! • This is achievable!
55. GENERIC SPECIFIC ADVICE • Don't try and track “stable” branches. Fork a specific git ref and code against that. • Spree test cases fail. Learn which ones are failing BEFORE you start coding. • Talk to people. Talk to IRC. Talk to your co- workers. Make sure whatever you're doing isn't crazy. • Pry! Use pry. Seriously, use pry. •
56. Questions?! • No way, Lunch time! • Come hang out with us and we can talk during lunch • We're also entertaining offers from people to buy us dinner...
57. • Clarke Brunsdon – clarke@freerunningtech.com – clarke in #spree on freenode IRC • Gregor MacDougall – gregor@freerunningtech.com – gmacdougall in #spree on freenode IRC • http://www.freerunningtech.com/