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.
