The document discusses the transition from a naive approach to an agile methodology in software development, particularly for SaaS applications. It outlines various scenarios and challenges faced in staging, development, and testing, while emphasizing the benefits and drawbacks of agile practices compared to traditional methods. Emphasis is placed on maintaining environment consistency, the need for version control, and the importance of feedback in the development cycle.

1. From Naive to Agile - SaaS
– DEC/18 Stayman

2. From Naive to Agile
● Two Scenarios
● Naive Approach
● Staging
● Development
● Testing
● Agile
– New Feature → Test → Implement → Refactor
● Rails

3. Two Scenarios
– Non-SaaS is different
● Outsourcing Project
– One-time Development
– Maintenance
– Improvement
– (Please Rectify)
● In-house Project
– On-going Development
– Engaged Operations
– Bug Fixing
– New Feature
– Feedback
– Deprecated Feature

4. Naive Approach
Internet
Prod Stack
WorkStation
dev in prod
over ftp

5. Naive Approach
● Favor php over others
● The Good
– Fast Delivery
● e.g. new news site
● The Bad
– Bugs go to Prod
– Hard to find Bug
– Hard to fix Bug
– Large upfront cost and
delayed feedback
– Blocking others dev
● e.g. down on change

6. Staging
Internet
Prod Stack
WorkStation
push to prod
over ftp
Stag Stack
dev in stag
over ftp

7. Staging
● The Good
– Fast Delivery Get some
lags on your delivery (1
day)
● The Bad
– Bugs go to Prod Get
some covers for bugs
– Hard to find Bug
– Hard to fix Bug
– Large upfront cost and
delayed feedback
– Blocking others dev

8. Staging
● The Problem
– How to replicate the change to prod?
● Code
● DB!
● e.g. kpop shop

9. How to replicate the change to prod
- Code
Internet
Prod StackWorkStation
Stag Stack
dev in master branch
deliver in production branch
Central Repo
Pull master on change
Pull production on change

10. How to replicate the change to prod
- DB
Internet
Prod StackWorkStation
Stag Stack
dev in master branch
deliver in production branch
Central Repo
Pull master on change
Exec db migration
Pull production on change
Exec db migration

11. Staging
● The Good
– Get some covers for
bugs
– e.g. It indeed prevents
bugs
● The Bad
– Get some lags on your delivery (1 day)
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Either setup CI or use deployment tools
– Hard to find Bug
– Hard to fix Bug
– Large upfront cost and delayed feedback
– Blocking others dev
– Blocking others delivery
– e.g. it takes around 1 hour to make even a tiny change
– e.g. hard for designer to adopt
– e.g. wait for others staging

12. Development
Internet
Prod Stack
WorkStation
Stag Stack
dev in master branch
Stage in master/stage branch
deliver in production branch
Central Repo
Pull master/stage on change
Exec db migration
Pull production on change
Exec db migration
Dev Stack

13. Development
● Must have for non-php
● The Good
– Get some more covers
for bugs
● The Bad
– Get some lags on your delivery (1 day)
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Either setup CI or use deployment
tools Learn more about CI and
deployment
– Hard to find & fix Bug Able to use
debug tools
– Large upfront cost and delayed feedback
– Blocking others dev Non-blocking dev
– Blocking others delivery
– e.g. strace vs debugger

14. Development
● The Problem
– How to keep your environment similar?
● Dev vs Dev
● Staging vs Prod
● e.g. chef dev package upgrade

15. ●How to keep your environment
similar? - Dev vs Dev
Internet
Prod Stack
WorkStation B
Stag Stack
dev in master branch
Stage in master/stage branch
deliver in production branch
Central Repo
Pull master/stage on change
Exec db migration
Pull production on change
Exec db migration
VagrantBox
WorkStation A
VagrantBox

16. ●How to keep your environment
similar? - Staging vs Prod
Internet
Prod Stack
WorkStation B
Stag Stack
dev in master branch
Stage in master/stage branch
deliver in production branch
Central Repo
Pull master/stage on change
Exec db migration
Pull production on change
Exec db migration
VagrantBox
WorkStation A
VagrantBox
IT Automation
Config Mngmnt
config
trigger

17. Development
● Must have for non-php
● The Good
– Able to use debug tools
– Non-blocking dev
● The Better
– Get more covers for
bugs
● The Bad
– Get some lags on your delivery (1 day)
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Have to learn IT Auto/Config
Mngmnt
– Have to learn Vagrant/Docker
– Large upfront cost and delayed feedback
– Environment Consistency
– Blocking others delivery
● The Worse
– Learn more about CI and deployment

18. Testing
Internet
Prod Stack
WorkStation B
Stag Stack
dev in master branch
Stage in master/stage branch
deliver in production branch
Central Repo
Pull master/stage on change
Exec db migration
Pull production on change
Exec db migration
VagrantBox
Dev/test env
WorkStation A
VagrantBox
Dev/test env
IT Automation
Config Mngmnt
config
trigger
Test Stack

19. Testing
● The Good
– Able to use debug tools
– Find bug earlier
– Non-blocking dev
● The Better
– Get more most covers for
bugs/security holes/low-
quality code
– e.g. new association
– e.g. improve design pattern
● The Bad
– Get some more lags on your delivery
(1 day hours to weeks)
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Have to write test code
– Have to learn Vagrant/Docker
– Have to learn IT Auto/Config Mngmnt
– Large upfront cost and delayed feedback
– Environment Consistency
– Blocking others delivery
● The Worse
– Learn more about CI and deployment
– e.g. months to test a project

20. Testing
● The Problem
– If test takes time?
– More lags typically doesn't work in our community

21. Testing
● The Good
– Able to use debug tools
– Find bug earlier
– Non-blocking dev
● The Best
– Get most covers for
bugs/security holes/low-
quality code
● The Bad
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Have to write test code
– Have to learn Vagrant/Docker
– Have to learn IT Auto/Config Mngmnt
– Large upfront cost and delayed feedback
– Environment Consistency
– Blocking others delivery
● The Worst
– Learn most about CI and deployment
– Get more lags on your delivery (hours
to weeks)

22. Agile
Naive
Staging
Dev
Test
Agile
Develop
Deliver & Feedback
Develop
Deliver & Feedback
Bug
Build repo
& stag env
Develop DebugBug
Day 1: pending
Build repo
& dev env
Build
stag env
Develop DebugBug
Deliver & Feedback
Build repo
& dev env
Build
stag env
Develop DebugBug Test DebugBug
Deliver
Feedbac
Story
board
Feedback
Build repo
& dev env
Test
Feedback
Develop Build
stag env
Deliver
Feedback
Debug/Refactor
Deliver
Feedbac
Bug Bug Bug
Debug
Day 2:
Deliver & Feedback

23. Agile
● The Good
– Able to use debug tools
– Find bug earlier
– Non-blocking dev
● The Best
– Get most covers for
bugs/security holes/low-
quality code
● The Bad
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Have to write test code
– Have to learn Vagrant/Docker
– Have to learn IT Auto/Config Mngmnt
– Large Low upfront cost and delayed early
feedback
– Environment Consistency
– Blocking others delivery
● The Worst
– Learn most about CI and deployment
– Get more less lags on your delivery
(hours)
– e.g. my latest rails project

24. Agile
● The Good
– Able to use debug tools
– Find bug earlier
– Non-blocking dev
– Low upfront cost and early
feedback
● The Best
– Get most covers for
bugs/security holes/low-
quality code
● The Bad
– Have to learn & setup version control
– Have to learn DB migration tools
– Have to make seed data
– Have to write test code
– Have to learn Vagrant/Docker
– Have to learn IT Auto/Config Mngmnt
– Environment Consistency
– Blocking others delivery
– Get less lags on your delivery (hours)
● The Worst
– Learn most about CI and deployment
Should NOT be a problem

25. Agile
● The Good
– Able to use debug tools
– Find bug earlier
– Non-blocking dev
– Low upfront cost and early
feedback
● The Best
– Get most covers for
bugs/security holes/low-
quality code
● The Bad
– Have to make seed data
– Have to write test code
– Environment Consistency
– Blocking others delivery
– Get less lags on your
delivery (hours)

26. Rails
● Php
– Flyway
– N/A
– PhpUnit
– Cucumber
– N/A
– ...
– Fabric
– N/A
● Rails
– Rake db
– Rake asset
– Rspec
– Cucumber
– Brakeman
– Rubocop
– Capistrano
– Byebug

27. Conclusion
● No Best. find the one fits your needs

28. My case
● MockingBird
● Ruby on Rails
● Vagrant
● RVM
● Cucumber
● Rspec
● Brakeman
● Rubocop
● Chef
● Kitchen-ec2
● Nginx
● Passenger
● MariaDB
● Gitlab
● Capistrano
● Jenkins
● Staging & Prod in one box

29. Thank You
Questions?