improvements of server-side developer team. › We focused on internal development processes, especially repository management and review. Because we believe that quick feedback and the continuous small improvements is the basis of improving throughput. › As a result, we saved 89% of time until PR is merged, and many qualitative surveys showed an increase in development speed.
› I think we should split modules for new feature. › But time and individual efforts needed. › After: Mono-repository mind. › Just create directory. Moving files. Done. With history. › Module test coverage ++.
to development. › Applied in our team. (13Dev, 3 Units › Ref: › Big IT company also uses mono-repo. ※ ※ Rachel Potvin and Josh Levenberg, “Why Google stores billions of lines of code in a single repository,” Communications of the ACM, 59 No. 7 (2016): 78-87.
small repository. › But not for large repository. Mainline (A.K.A master) / Developers on it Development (A.K.A. Beta) QA, Planner, other teams on it New features No problem for small team. But uncontrollable when service scaled.
too difficult for human. › Especially team management. › Anti-Pattern: THEIR(Team’s) latest is not MY latest. › Solution: Define single truth of mainline. › Starting point of development = reviewed = internal beta = next release candidate.
finally releases. My interruption cost is higher than benefit of fast feedback for peers. Isn’t it? › NO! › Pending PR is stock. › Stock is not assets. It’s liabilities. › Of course, you need a “zone”. Please remind reviewing when you interrupted.
› Checklist › Do you finish code reviews before starting write your code? › Do you subscribe notification when code review requested? › Do you check PR list regularly like checking slack? › Most important thing is the culture and trust that submitting review is one of the fastest way to got feedback and improve your ideas.
review. That makes schedule clear. › Conflict reduced. Many merge operation is not needed. › Context switching between coding and reviewing is not needed. › Cons › Need to protect unreleased feature by feature flag. › But better than managed by branch.