From massive pull requests to trunk-based development in Ruby

Massive, long-lived pull requests are often such a headache. In this session we go through a move into a trunk-based development source-control workflow which eliminates the need for these “code avalanche” pull requests.

After short introduction of trunk-based development and the fears people have for implementing it, we will go through concrete examples, lifted from a production system, of code, architecture, and workflows to tackle those fears when working on improving the development and deployment happiness of the team working on the application.

After this talk the attendee are emboldened to start their own trunk-based development journey or excited to apply some of the techniques from the talk to their existing development processes and codebases.

Transcript

1. From massive pull requests to trunk-based development in Ruby Vesa Vänskä Euruko 2022
2. The pain of long-lived branches
4. Vesa Vänskä
6. Offtopic curl -s https://api.github.com/users/vesan | grep created_at "created_at": "2008-04-03T16:32:37Z",
7. GitHub Flow
10. Trunk-based development
11. What is trunk-based development? Source-control branching & collaboration model Collaboration happens in trunk (aka master/main) No other long-lived branches
13. Caveat: This talk is about services.
14. "It will never work!" "This feature will take months to build" "Broken code will go to production all the time" "But we are not Google" 😞
15. "This feature will take months to build. My branch needs to be long-lived."
16. Feature flags
17. Feature flags <%# erb file %> <% if Flipper.enabled?(:widgets, current_user) %> <%= render "widgets" %> <% end %>
18. Feature flags # rails console Flipper.enable_actor :widgets, user Flipper.enable_group :widgets, :beta_testers Flipper.enable_percentage_of_actors :widgets, 2 Flipper.enable :widgets
19. Feature flags # routes.rb resources :widgets, constraints: -> { |request| request.session[:user_id] && Flipper.enabled?(:widgets, User.find(request.session[:user_id]) }
20. "Broken code will go to production all the time."
21. Continuous Integration server
22. Monitoring
23. ActiveSupport::Notifications
24. ActiveSupport::Notifications ActiveSupport::Notifications.instrument("widgets.manufacture", widget_id: widget.id) do # Run the code end ActiveSupport::Notifications.instrument("widgets.manufacture_failed", widget_id: widget.id) ActiveSupport::Notifications.subscribe("widgets.manufacture") do |name, start, finish, id, payload| push_event_to_monitoring(name, start, finish, id, payload) end
26. "We are not Google"
27. CI/CD
28. CI CD
29. "Any improvements made anywhere besides the bottleneck are an illusion." Eliyahu Goldratt, Theory of Constraints
31. State of DevOps report
32. DORA metrics
33. DORA metrics Deployment Frequency Lead Time for Changes Change Failure Rate Time to Restore Service
34. State of DevOps survey 2022 results
35. State of DevOps survey 2022 results 😮
36. State of DevOps survey 2022 results 😮😬
37. State of DevOps survey 2022 results 😮😬😅
38. State of DevOps survey 2022 medium tier Deployment frequency: Between once per week and once per month Lead time to changes: Between one week and one month Time to restore service: Between one day and one week Change failure rate: 16%–30%
39. Start experimenting!
41. Resources to get further The site https://trunkbaseddevelopment.com State of DevOps report https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out Check out Kisko Labs virtual booth
42. Thank you! Vesa Vänskä · twitter.com/vesan · vesa@vesavanska.com
43. Images DHH Github image: https://signalvnoise.com/posts/2486-bootstrapped-profitable-proud-github GitHub Flow image: https://github.com/SvanBoxel/release-based-workflow/issues/1 GitHub logo: https://www.flaticon.com/free-icon/github-logo_25231