Post on 29-Nov-2014
description
transcript
Migros.ch
ModularizingMagnolia for
Switzerland'sLargestRetailer
Jan Reise, aperto Berlin, Daniel Özbek, Migros CWI@Magnolia Conference Basel, 4.9.2012
2
If you thought ...
… that this is what a typical
Magnolia website looks like …
3
Think again.
4
migros.ch stats
• Over 11,000 content pages
• Over 14,000 teasers
• Over 80 page templates
• Over 250 paragraph templates
• Over 1300 Java classes
Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
5
Magnolia relaunch
7
2010: Relaunch of existing site
• Old system
• MS Sharepoint based
• slow to use
• difficult to extend
• expensive to maintain
• Plan:
• keep the contents
• keep the workflow
• fix the problems
8
Requirements for new system
• easy to use for editors
• live preview
• easy to connect to other systems
• central content repository (for other systems)
• save costs
• Migros chose Magnolia ☺
9
Results
• Migration in 6 months
• System very stable
• Workflow “not changed but improved”
• Return on investment already after a few months
Some features
11
Data hub: import and improvement
Weekly import from ERP systems & editorial improvement in Magnolia
12
Data hub: exportDelivery of processed data
to other systems, eg. mobile apps
13
Teaser management
Common teaser pool for site
Time based display on pages
Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
14
Growing into a portal
Rapid growthNew sub-projects built in a short time frame (1.5 years)
16
aus-der regionmigros.ch relaunch cumulus generation-m
A portal with sub-sitesSeparate themes and templates
1 Magnolia webapp, 1 content repository
17
18
Development driven by change requests
• Over 250 change requests per year
• Different stakeholders (marketing, corporate communication,
regional cooperatives, …)
• Budgets only for visible features, not for improving or refactoring the
overall project
Feature releases 20113 simultaneous sub-projects
19
January February March April May June July
R 4.2
R 4.3
R 4.5 (migros.ch)
R 5.0 (aus der region)
R 6.0 (cumulus
R 6.1
R 5.1
R 6.2
R 6.3 (all in one)
4.1
R 4.4
20
Where‘s the architecture?
• Fast growing complexity (new modules)
• Fast growing size (permanent development and additions)
• Still using the architecture we started with:
• Magnolia
• Webapp with first project
• Modules for new projects
• But: common functionality still in with the first project
• All new projects depend on the first project
21
Dependencies: expensive and slow
• Dependencies between projects lead to side effects (bugs)
• Make a change in one project and you have to test all projects
• Testing becomes expensive
• Testing slows down the project
Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
22
Modularization
24
Why not do it like Magnolia?
• Magnolia itself has a modular
architecture
• Remove dependencies
between projects
• Put common stuff into
modules
Architecture at relaunchLike a simple project: just a webapp, a theme, and magnolia
25
New projects in new modules, depending on common functionality …
… which is in the webapp with the first project
26
„Organic“ evolution
27
Common functionality in common modulesNo software dependencies between sub-projects
28
Even more modulesEach feature in its own module
29
Over 25 Magnolia modulesEach module has its own independent software lifecycle
30
The result: better (and less expensive)
software architecture
• less dependencies �less technical complexity
• easier to understand for developers (new and old)
• more re-use by having a set of well-documented basic templates
• easier to test: test only the module that has been changed
31
Releases are containers for modules… and modules are containers for features
Releases on a steady schedule2012: Feature releases every 5 weeks
32
March April May June July August September
R 7.0
R 7.1
R 7.2
R 7.3
R 7.4
R 8.0
R 8.1
33
Easy integration of third party modulesThird party modules based on Magnolia or on Migros common stack
Third party modulesEasily integrated as software dependencies
34
Third party stuff put into a moduleMagnolia wrapper for a
Flash / PHP microsite
35
Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
36
Modularization part II
38
The last dependency: the release cycle
• Good: stable, dependable, predictable like Swiss train system
• Not so good: rigid and potentially slow
• Up to 9 weeks before a new feature goes online
39
Speeding up feature releases
• Scenario: new features in one sub-project require changes in the
common stack
• What we want: Focus test and release cycle on this sub-project
• Test and release everything else later
40
Release and deploy separatelyEach project in a separate webapp and in a separate magnolia instance
Even on separate versions of common stack
41
Handling shared data
• Some data cannot be kept redundantly
• Administer data in “master project webapp”
• Provide data to other project webapps via web services
Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
42
Summary
44
What have we gained?
• Fewer dependencies between projects
• Less coordination between projects
• Agile testing
• Free choice of development teams
• More flexibility
• More scaling possibilities
• Better scaling of development resources
New challenges
46
Integration challenges
• Coordination necessary between portal owner and project owners
• Coordination necessary between project owners and development
teams, in order to prevent double developments
• Projects have to share information
• Continuous development of the common stack
47
Management challenges
• which Magnolia instances for which editors?
• access right management
• support of the plattform
• deployments
48
Cost challenges
• hosting and maintenance of all projects in several environments
• development
• testing
• productive
• who pays for the development of common functionality?
49
To sum up
• Magnolia is good for large, multi-project, portal-type sites
• Too much complexity makes projects expensive and slow
• A modular architecture helps reduce complexity
• Magnolia offers an excellent foundation for this
• Separate deployment of sub-projects provides even more agility
• But: if you have several platforms you will have to support them!
Thank you.