![]() Now imagine the repository had more than one active release branch (e.g., release_v5.1, a release branch to stabilize the future v5.1 release). She checks out the maintenance_v4 branch locally, cherry-picks the bug fix to it using git, runs the tests locally, creates a PR targeting maintenance_v4, and asks Bob for another code review before merging the PR. Alice then kicks off a long list of mundane tasks. Bob approves the fix and suggests cherry-picking it to maintenance_v4 since the bug fix is security related. ManualĪssume Alice opens a pull request to fix a bug in the trunk. The maintenance_v4 branch is used to make critical bug fixes and security upgrades to the previous major version (v4), so consumers who are still on v4 can pull in critical fixes without having to simultaneously do the major upgrade. Trunk is the development branch for the current major version (v5). Imagine two developers, Alice and Bob, collaborate on a GitHub repository with two protected branches: trunk and maintenance_v4. Now cherry-picking commits only takes one developer a few seconds as opposed to multiple developers spending 10+ minutes without this automation, thereby reducing the time that developers need to spend on cherry-picking commits by around 99.6% This newfound efficiency means now developers can spend more time and focus on delivering the insights and information that our members and customers value most.įigure 1: Manual Cherry-pick vs Automated Cherry-pick: User Actions The Tale of Two Options To automate this task, we developed the Automated Cherry-pick GitHub app which significantly reduces efforts of developers working at LinkedIn. This is a really mundane and time-consuming task for any developer. In this case, they use the ‘git cherry-pick’ command to manually apply changes across branches. Sometimes when developers make some code changes in the main branch, they want to apply those changes to release branches as well so that those branches also get the same benefit. While most repositories (e.g., web services) practice continuous delivery solely from trunk (or main branch), those (e.g., core libraries) that need to stabilize their release or release on a fixed schedule use release branches. Code changes are peer reviewed using a pull request (PR) workflow on GitHub and merged into the main branch. Most of these repositories practice trunk-based development, which means developers push code changes frequently to the trunk (main branch) and avoid any other long-lived branches. With approximately 15,000 code repositories, our developers work tirelessly to make thousands of code changes each day, improving functionality and resolving any issues that may arise. Our developers at LinkedIn are constantly exploring ways to enhance and strengthen our platform, aiming to provide our members and customers with the greatest possible access to knowledge and connections.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |