"Same but different: A story of delivering multi-brand product." I want to share my story with you - how we deliver multi-brand products at the same time with one small team. What challenges we faced? Having custom localization, individual brand view, specific features in almost the same products. Agile tell us to work smarter, not harder. DevOps & automation practices were turned upside down. So instead of working on every single flow, we took a step back, and start improving simultaneous delivery. All as one.

1. SAME BUT DIFFERENT
A story of delivering multi-brand product

2. Based on a true story.

3. Ivan Pashko
● Project Manager Scrum
Master
● QA Automation Engineer
● 10+ years in IT
● 1+ years happy father

4. Multi-brand strategy
Multi-branding strategy - is when each brand is
intended for a different market segment.
What it meant for us (as a web project):
● Visual differences (colors, styles, layouts)
● Content differences (content localization, data specifics)
● Feature/Behaviour differences (user journeys, data flow)

5. Multi-brand solution

6. Our implementation plan

7. A-a-a-a!
● Architecture
● Automation (Testing)
● Automation (Process)
● Automation (Deploy &
monitoring)

8. Architecture
● No silver bullet
● Do not “overproduct” on the start
○ Release as fast as you can, with basic architecture
○ Improve continuously with “baby steps”
● Build quality in
○ Regression automation on all levels

9. Fakes & mocks
● Fast, Stable, Readable tests
● New features developing without
blocking on Backend (FE side)
● Prototyping new ideas

10. Feature Toggling
● Create feature once
● Enable via config (not from
code)
● Cover with tests scenarios
● Run tests depending on
config (automatically)

11. If something is difficult or painful, do it
more often*
*for multybrand - everything is painful :)

12. Process automation
● Blueprints
● Single command env build
● Local environment
● Fast switch between brands

13. Deploy automation
● Unified deploy procedure
● Parallel and optimal deploy strategy
● Build binaries once
● Rollback
● If common fails, stop the line,
if one brand fail - keep moving.

14. Don’t write automated tests, write
executable specifications

15. Test Automation
● Use automation as a testing tool:
○ Visual artifacts
○ Verify at one brand - run at all
● Optimize resources:
○ Run on every code change only feature tests
○ Use testing pipelines and suites
● BDD

16. BDD
● Only Live documentation
● Encourages collaboration between QA & Dev’s:
● QA act as a business representative for the developers
● QA and development work together.

17. Monitor. Support. Explore

18. Post Deploy Monitoring
● Realtime & available log data
● Track user’s journeys
● Explore clients errors
● Create Smart notifications (static rules or AI)
○ Deviation in average values (charts)
○ Case of degeneracy

19. Summary
2 things to follow:
● A close, collaborative working relationship
between everyone involved in delivery
● Extensive automation of all possible parts of
the delivery process and removing waste

20. Thank you! Questions?
Contact me:
Email: pashko.ivan@gmail.com
FB: https://www.facebook.com/ivan.pashko