Downloaded 54 times
Uploaded byMatt Graham
Continuous Deployment of Architectural Change
The document, presented by Matt Graham from Etsy, discusses the principles and practices of continuous deployment and its application in enabling architectural changes in web applications. It emphasizes the importance of tools, such as feature flags and communication graphs, in facilitating seamless deployments and mitigating the risks associated with frequent changes. The presentation also outlines a systematic approach to scaling and implementing architectural modifications through small, gradual steps while maintaining both old and new systems in parallel.
More Related Content
![Droid con 2013 workshop unit testing in android [robolectirc]](https://cdn.slidesharecdn.com/ss_thumbnails/droidcon2013workshop-unittestinginandroidrobolectirc-131127032715-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Continuous Deployment of Architectural Change
Continuous Deployment of Architectural Change
- 1. Continuous Deployment of Architectural Change Matt Graham Core Engineer @ Etsy Continuous Deployer #iasany September 27, 2011
- 2. A Brief Historyof Deployment
- 3.
- 4.
- 5.
- 6.
- 7. Database Deployment @Etsy Thursday
- 8. What it's allabout ● Broadly Applicable ● Tools Help ● Enables the Unfeasible
- 9. MTTR vs MTTF
- 10. MTTR vs MTTF ● Cheaper for electrons
- 11. MTTR vs MTTF ● Cheaper for ● Cheaper for electrons protons & neutrons
- 12. MTTR vs MTTF ● Cheaper for ● Cheaper for electrons protons & neutrons ● Cost prohibitive for humans
- 13. MTTR vs MTTF ● Cheaper for ● Cheaper for electrons protons & neutrons ● Cost prohibitive for humans ● Necessitates low MTTD
- 14. The Case ofElectrons ● Consider a project that has 6 bugs ● continuous deployment testing misses 4 & deploys fixes in 4 hours ● monthly release testing misses only 2 & deploys fixes in 24 hours ● 16 hours of broken < 48 hours of broken
- 15. Good Excuses ● Infrequent Changes
- 16. Good Excuses ● Infrequent Changes ● Infrequent Executions
- 17. Good Excuses ● Infrequent Changes ● Infrequent Executions ● Life and Death
- 18. Good Excuses ● Infrequent Changes ● Infrequent Executions ● Life and Death ● Physical Investment
- 26.
- 27. Culture Before Tools ● No planned deploys; only on demand
- 28. Culture Before Tools ● No planned deploys; only on demand ● A positive change is ready & tested
- 29. Culture Before Tools ● No planned deploys; only on demand ● A positive change is ready & tested ● Software is stable & supported
- 30. Jenkins ● Unit Tests
- 31. Jenkins ● Unit Tests ● Functional Tests
- 32. Jenkins ● Unit Tests ● Functional Tests ● Manual Testing
- 33.
- 34. tail -f |grep
- 35.
- 36.
- 37. Key Tools Communication Tools Graphs Feature Flags
- 38. Feature Flags Deploy !=Product Launch
- 39. Dark Launch def get_feature_a_link(): return ...
- 40. Dark Launch def get_feature_a_link(): if enabled('NewFeatureA'): return new_feature_a_link() else: return old_feature_a_link()
- 41. Dark Launch application_config - NewFeatureA: admin - NewFeatureB: off - NewFeatureC: on
- 42. Ramp Up application_config - NewFeatureA: 1% - NewFeatureB: off - NewFeatureC: on
- 43. Ramp Up application_config - NewFeatureA: 5% - NewFeatureB: off - NewFeatureC: on
- 44. Ramp Up application_config - NewFeatureA: 25% - NewFeatureB: off - NewFeatureC: on
- 45. Ramp Up application_config - NewFeatureA: 100% - NewFeatureB: off - NewFeatureC: on
- 46. AB Testing ● Prove success of interface changes ● Prove interest in new features
- 47.
- 48.
- 49.
- 50.
- 51. StatsD if ($success) { StatsD::timing('feature.runtime', $time); } else { StatsD::increment('feature.failure'); } github.com/etsy/statsd
- 52.
- 53.
- 54.
- 55. Forums / MessageBoards
- 56.
- 57.
- 58.
- 59. Deployment is FirstClass Deployment is a First Class Feature
- 60.
- 61.
- 62.
- 63.
- 64.
- 65. Premature Architecture What now?
- 66. Passing Time =>Change ● Scale ● Product ● Technology ● Engineering Team
- 67. Passing Time =>Change ● Scale ● Product ● Technology ● Engineering Team ● The Correct Architecture Changes
- 68. Examples ● Images From Twisted to PHP ● From PostgreSQL to MySQL Shards
- 69. From Twisted toPHP ● Run Apache/PHP on a new port
- 70. From Twisted toPHP ● Run Apache/PHP on a new port ● Implement one service in PHP
- 71. From Twisted toPHP ● Run Apache/PHP on a new port ● Implement one service in PHP ● Ramp up users on new service
- 72. From Twisted toPHP ● Run Apache/PHP on a new port ● Implement one service in PHP ● Ramp up users on new service ● Repeat for remaining services
- 73. From Twisted toPHP ● Run Apache/PHP on a new port ● Implement one service in PHP ● Ramp up users on new service ● Repeat for remaining services ● Shut down Twisted version
- 74. PostgreSQL to MySQLShards ● Migrate table by table
- 75. PostgreSQL to MySQLShards ● Migrate table by table ● Teed writes to MySQL
- 76. PostgreSQL to MySQLShards ● Migrate table by table ● Teed writes to MySQL ● Backfill old data from PostgreSQL
- 77. PostgreSQL to MySQLShards ● Migrate table by table ● Teed writes to MySQL ● Backfill old data from PostgreSQL ● Verify data matches in both DBs
- 78. PostgreSQL to MySQLShards ● Migrate table by table ● Teed writes to MySQL ● Backfill old data from PostgreSQL ● Verify data matches in both DBs ● Ramp up users reading from MySQL
- 79. PostgreSQL to MySQLShards ● Migrate table by table ● Teed writes to MySQL ● Backfill old data from PostgreSQL ● Verify data matches in both DBs ● Ramp up users reading from MySQL ● Stop Postgres writes & drop tables
- 80. Continuous Deploy Pattern ● Change in small steps
- 81. Continuous Deploy Pattern ● Change in small steps ● Dark launch placeholder via config
- 82. Continuous Deploy Pattern ● Change in small steps ● Dark launch placeholder via config ● Deploy to production while dark
- 83. Continuous Deploy Pattern ● Change in small steps ● Dark launch placeholder via config ● Deploy to production while dark ● Maintain old & new in parallel
- 84. Continuous Deploy Pattern ● Change in small steps ● Dark launch placeholder via config ● Deploy to production while dark ● Maintain old & new in parallel ● Ramp up to new architecture
- 85. Continuous Deploy Pattern ● Change in small steps ● Dark launch placeholder via config ● Deploy to production while dark ● Maintain old & new in parallel ● Ramp up to new architecture ● Remove old architecture
- 86. Review ● Broadly applicable ● Key Tools: Feature Flags, Graphs, Communication ● Enables Architectural Change ● It's really fun!!!
- 87. Continuous Deployment of ArchitecturalChange Matt Graham http://twitter.com/lapsu http://lapsu.tv Core Engineer @ Etsy Continuous Deployer http://codeascraft.etsy.com We're Hiring! http://bit.ly/etsywantsawesome