Talks
From massive pull requests to trunk-based development with Ruby
#continuous-integration-ci
#ruby-on-rails
#git
#feature-flags
#devops
#software-development-practices
Summarized using AI
From massive pull requests to trunk-based development with Ruby
by Vesa VänskäIn this talk, Vesa Vänskä addresses the transition from managing massive pull requests to adopting trunk-based development within Ruby projects. He highlights the complexities associated with long-lived branches, which often lead to merging difficulties and diminished code review quality. With 15 years of Ruby experience, Vänskä shares insights rooted in his own encounters with branch management in a smaller consultancy setting, Kisco Labs. The talk primarily covers how trunk-based development streamlines collaboration by prioritizing short-lived branches, encouraging frequent merges, and reducing the clutter that comes with extended pull requests.
Key Points Discussed:
- Introduction to Trunk-Based Development: Vänskä defines trunk-based development as a method that emphasizes collaboration on the main branch (trunk), minimizing the use of long-lived branches. This method fosters a cleaner development process.
- Benefits of Short-Lived Branches: Developers should aim to keep branches alive only for hours to a week before merging them into the trunk, enhancing the efficiency of the workflow.
- Use of Feature Flags: For managing features that are not fully developed, feature flags can provide a robust solution. Vänskä illustrates this with examples utilizing the Ruby gem Flipper, which allows for controlled deployment of features to specific user segments.
- Continuous Integration Importance: The significance of continuous integration (CI) in ensuring smooth development processes underlines the necessity to run automated tests to catch issues early, thereby improving code quality.
- Metrics from the State of DevOps Report: Vänskä references the report, which identifies key performance metrics like deployment frequency and change failure rate, providing data that can help teams assess their practices.
- Careful Transition Phases: The speaker suggests a gradual implementation of CI/CD practices rather than overhauling the existing systems abruptly, enabling teams to adapt effectively without overwhelming members.
Vänskä concludes that trunk-based development can serve as a practical alternative for teams struggling with pull requests. He encourages teams to assess their specific needs, experiment with various practices, and adapt their workflows for improved productivity. The talk points towards abundant resources available for teams wishing to learn more about trunk-based development, highlighting an accessible entry point for teams of any size to refine their development processes.
00:00:04.799
Thank you for joining this talk.
00:00:10.980
Today, we will discuss how to transition from massive pull requests to trunk-based development using Ruby. This talk is rooted in the pain of dealing with long-lived branches.
00:00:19.920
Branches often diverge significantly from the main branch, making them difficult to merge.
00:00:25.880
This leads to poor quality code reviews, where reviewing multiple requests is manageable, but the motivation wanes as pull requests grow larger.
00:00:31.080
To provide some context, I've been developing with Ruby for 15 years and have been a web enthusiast since I was 10.
00:00:36.840
Currently, I work for Kisco Labs, a software agency focused on building new products from scratch.
00:00:42.960
We operate as a consulting product house with a small team, rather than having hundreds of developers.
00:00:49.320
My experience with painful branch management has shaped my insights.
00:00:57.379
I used Git back in the day when I would install it on my own server, but it was GitHub that truly popularized it.
00:01:04.700
Back in the day, GitHub's interface was quite different.
00:01:10.740
I discovered that there is an API for GitHub that allows you to see when your account was created.
00:01:16.680
My account was created in 2008, and a few weeks later, David Heinemeier Hansson joined.
00:01:25.200
This points to the fact that perhaps David wasn’t as eager on Hackers News as I was.
00:01:33.200
This was around March 10th, 2008.
00:01:40.140
With GitHub, we adopted GitHub flow. Before Git, I primarily used Subversion.
00:01:45.780
Creating branches in Subversion was cumbersome, and they were often long-lived.
00:01:52.439
Git made branching easy and GitHub introduced us to the pull request flow.
00:01:59.820
Most developers are familiar with creating feature branches, adding commits, and opening pull requests for reviews.
00:02:05.880
However, the review process can take weeks if branches are not managed properly.
00:02:12.239
This brought me to discover trunk-based development, which seemed like a possible solution to my problems.
00:02:18.660
Who here has heard of trunk-based development?
00:02:25.620
It seems like quite a few of you are familiar with it.
00:02:32.640
In essence, trunk-based development pertains to source control and is heavily linked to collaboration models.
00:02:39.420
Collaboration occurs primarily in the trunk, which is also known as master or main.
00:02:45.420
The idea is to avoid long-lived branches, as they can complicate the merging process.
00:02:51.840
Branches should only be short-lived, ideally hours to a week.
00:03:02.760
Once the code in these branches is ready, it goes through a pull request for review before merging.
00:03:10.379
The process leads to cleaner releases, directly from the trunk.
00:03:16.979
There is also a non-scaled style where developers push directly to trunk without feature branches.
00:03:22.019
While this is encouraged by many proponents of trunk-based development, it might not suit all projects.
00:03:29.900
This discussion focuses on services with live versions in production.
00:03:38.460
If you manage a project that releases patches on various versions, other processes might be more appropriate.
00:03:45.780
For services with a single live version, trunk-based development is highly relevant.
00:03:50.760
You might wonder how a process that seems chaotic could lead to broken features or slow development.
00:04:01.680
Questions abound about how we can reconcile pushing code straight to the main branch.
00:04:08.400
While we’re not Google, we can still implement some effective practices.
00:04:15.840
For projects involving long-lived features, using feature flags can be instrumental.
00:04:22.620
These allow for partial development features to be released in controlled environments.
00:04:31.579
For example, using the Ruby gem Flipper, we can render new features conditionally.
00:04:39.660
You might set a flag to enable new widgets only for specific users.
00:04:46.920
Flags can be controlled via Rails console or through a web UI.
00:04:52.680
Enabling features only for select users or groups, such as beta testers, keeps the overall user experience intact.
00:05:03.960
As features are finalized, you can gradually roll them out to larger user percentages.
00:05:10.940
Finally, cleanup should follow once the feature becomes stable to prevent clutter in the codebase.
00:05:18.240
Feature flags can be applied not only in views but throughout the codebase.
00:05:27.120
For example, an HTTP endpoint can be made available conditionally for users based on flags.
00:05:35.300
You can exclude certain endpoints from documentation or serializers when using feature flags.
00:05:41.880
Addressing how broken code could frequently go to production revolves around the necessity for continuous integration.
00:05:50.760
How many of you currently use a continuous integration server?
00:05:58.080
Most teams have established CI systems that automatically run tests whenever someone pushes code.
00:06:06.180
Implementing automated tests in a CI/CD pipeline is essential, especially for trunk-based development.
00:06:12.340
Even if trunk-based development isn't your goal, leveraging CI is beneficial for any development workflow.
00:06:21.360
As the landscape has evolved, starting with CI in Ruby and Rails projects has become easier.
00:06:30.420
Modern platforms offer numerous solutions for CI/CD, simplifying the setup process.
00:06:39.240
Focus on monitoring and visibility in your production environment is equally important.
00:06:49.680
Error monitoring is crucial to understand how your software is performing.
00:06:57.600
Utilizing Active Support notifications in Ruby and Rails can provide detailed insights into application performance.
00:07:04.620
You can create metrics and subscribe to events collected from your application.
00:07:10.740
With monitoring in place, you can glimpse into user interactions and application workflows.
00:07:16.680
Deploying to services like AWS makes it easier to visualize custom logs and events in CloudWatch.
00:07:30.720
This can lead to enhanced visibility for development teams.
00:07:39.000
Now, what about the notion of 'we are not Google?' Many professionals believe certain techniques only suit large corporations.
00:07:46.500
However, the tools and libraries available today are accessible to teams of any size.
00:07:55.740
Trunk-based development can work for smaller teams as well.
00:08:02.460
We see a growing emphasis on productivity in Ruby development.
00:08:09.420
Although there’s a connection between continuous integration and continuous delivery, they shouldn't be conflated.
00:08:22.740
Continuous integration lets teams collaborate on a common trunk efficiently, while continuous delivery automates releases.
00:08:32.520
Transitioning from continuous integration to continuous delivery can be challenging, and teams should approach it in stages.
00:08:40.380
Don't feel pressured to adopt a comprehensive CI/CD pipeline all at once; instead, incrementally introduce helpful practices.
00:08:49.680
Dr. Goldratt once said, 'any improvement made anywhere besides the bottleneck is an illusion.'
00:08:57.840
Identify the bottlenecks within your team and experiment with techniques that resonate with your workflow.
00:09:06.960
Evaluate if trunk-based development addresses issues like long-lived pull requests.
00:09:15.600
If pull requests aren't an issue, feel free to keep your current practices if they are serving your team well.
00:09:25.680
Not every team needs to adopt trunk-based development, and that's perfectly fine.
00:09:34.560
For teams experiencing difficulties with pull requests, however, this approach can streamline development.
00:09:43.200
Long-running pull requests are often seen as an insurmountable challenge, leading to fatigue among developers.
00:09:53.220
Have you ever felt overwhelmed by the review process of a large pull request?
00:10:01.200
The clutter can create a poor experience for reviewers and developers alike.
00:10:09.660
Additionally, there's often a misconception that lengthy pull requests provide a comprehensive view.
00:10:17.700
While there's no magic bullet to resolve this issue, fostering better communication and smaller changes can help.
00:10:25.920
It's crucial to find a balance in the review process.
00:10:35.400
This is where the State of DevOps report comes in.
00:10:45.300
This survey provides invaluable insights about team performance and effective practices.
00:10:53.700
Who here is familiar with the State of DevOps report?
00:11:03.840
The report analyzes data from various organizations and produces insights applicable across the industry.
00:11:09.840
It highlights key metrics that organizations should prioritize.
00:11:17.640
The four key metrics include deployment frequency, lead time for changes, change failure rate, and time to restore service.
00:11:26.520
These metrics help teams diagnose their performance and success in implementing agile development practices.
00:11:35.520
Overall findings help organizations improve by optimizing processes and tools.
00:11:43.920
As trunk-based development grows in implementation, it’s worth considering how it relates to these metrics.
00:11:54.360
Ultimately, teams looking to enhance their development processes can benefit from adopting new methodologies.
00:12:03.840
While it's possible that some teams may feel overwhelmed, there's a clear path forward.
00:12:13.080
Take small steps, evaluate your progress, and make changes as needed.
00:12:21.420
By experimenting with techniques and approaches, teams can improve their development environment.
00:12:30.600
As an example, I suggest visiting strongbaseddevelopment.com, which has many practical resources.
00:12:42.120
Additionally, the latest State of DevOps report is worth perusing for insights.
00:12:52.920
Feel free to engage with any Kisco Labs representatives here at the event to discuss these topics further.
00:13:02.160
Thank you for your attention.
00:13:10.920
Let's move on to questions.
00:13:19.200
What is your process for cleaning up obsolete feature flags after a feature is available to everyone?
00:13:26.880
Initially, it’s not urgent, but after sufficient time—perhaps a release cycle or two—I would remove old flags.
00:13:34.920
If they’ve been stable and everything runs smoothly, it’s wise to clear out old flags.
00:13:41.880
How do you handle long-running work, such as breaking Ruby on Rails upgrades?
00:13:47.700
We often use dual-booting strategies, allowing the old and new versions to run in parallel until the transition is smooth.
00:13:56.640
Creating new versions alongside existing ones allows for a clean switch.
00:14:01.800
When it comes to feature flags, how do you avoid cluttering your code with endless conditionals?
00:14:08.400
Maintaining a healthy practice of cleaning up feature flags after they serve their purpose is crucial.
00:14:15.840
You’ll learn through mistakes about where to effectively implement feature flags.
00:14:24.720
Transitioning from not being Google to leveraging tools from large-scale development does take time.
00:14:31.800
How can you handle feature flags in large teams? The overhead can be significant.
00:14:39.360
Organizations often find it helpful to create dedicated infrastructure and SRE teams to manage these complexities.
00:14:47.520
This can help in deploying effectively while requiring less overhead on individual team members.
00:14:54.120
How do you monitor or log feature flags?
00:15:01.160
Keeping a change log or part of the deployment calendar can help monitor feature flag status.
00:15:08.160
Transparency teams can help navigate feature flag statuses.
00:15:14.880
Can testers test specific new features targeted just for them?
00:15:22.560
Yes, enabling certain flags for testers allows for excellent control over test environments.
00:15:30.240
Trunk-based development can work well even in teams of varying sizes.
00:15:38.640
Companies like Google use trunk-based development, showcasing its scalability.
00:15:48.840
Automations to manage CI runs support a trunk-based approach.
00:15:55.680
Ultimately, finding the right balance of merging and automating processes is key.
00:16:02.760
What do you prefer for continuous integration servers?
00:16:09.600
I find GitHub Actions to be efficient and well-suited for Ruby development.
00:16:15.120
They come with a robust set of options requiring less effort for setup.
00:16:22.920
Are there any alternatives to trunk-based development?
00:16:30.300
GitHub flow is a valid approach, though it may not fit everyone’s needs.
00:16:38.520
Reading more about various methodologies can provide valuable insights.
00:16:46.200
Thank you all for attending this discussion today.
Explore all talks recorded at EuRuKo 2022
+3