jimmylv.github.io
jimmylv.github.io copied to clipboard
JimmyLv
TBD & Monorepo: Integrate with Lerna and Yarn workspace
项目纵向拆分
⓵ 定义目标和原则
⓶ 展望结果（OKRs）
⓷ 头脑风暴（发散）
⓸ 组织整理（收敛）
⓹ 明确「下一步行动」
- before monorepo（setup）
- lerna usage
- lerna run & exec
- yarn workspace
Ideas
- Monorepos - Trunk Based Development
- monorepo 新浪潮 | introduce lerna · Issue #3 · pigcan/blog
- 谷歌的代码管理 - 阮一峰的网络日志
Example
- babel/monorepo.md at master · babel/babel
- create-react-app/CONTRIBUTING.md at master · facebookincubator/create-react-app
- Why Google Stores Billions of Lines of Code in a Single Repository - YouTube
- https://staltz.com/setting-up-a-javascript-monorepo.html
Tools
- lerna/lerna: A tool for managing JavaScript projects with multiple packages.
- lerna-changelog
- http://formidable.com/open-source/builder/
- https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
- https://code.facebook.com/posts/274518539716230/announcing-yarn-1-0/
- Introducing Composite Builds
Others
- https://developer.atlassian.com/blog/2015/10/monorepos-in-git/
- The Case for Monorepos
- Advantages of monolithic version control
- New wave modularity with Lerna, monorepos, and npm organizations
- Monorepo, scaling projects
Topic: Monorepo
Problems:
- Overhead of dependency upgrade
- Versioning management not easy cross repos
When the application gets more complex, dependencies become hard to manage and bring overhead in development. Mono-repo is to solve this issue by bring them together in one repo, so that we can working on one repo without manage dependencies in different places. We'd like to share with you what changes we made in O$P to make our frontend development easier and the problems we've solved.
Topic: Trunk Based Development
Problem:
- Long release cycle
- Long review cycle
- Maintain too many branches
Solution & Benefits: Trunk-Based Development is a source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches. Trunk-Based Development is a key enabler of Continuous Integration and by extension Continuous Delivery. When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.
发现自己 Release 有问题 -> 拉个分支吧！ 发现不要跟 master 有冲突 -> 拉个分支吧！ 发现现在这个 Feature 现在不 Release -> 拉个分支吧！ 发现线上有 bug 要修 -> 拉个分支吧！
「拉个分支吧！」是最简单的代码隔离方案，但并不意味着最快速。(长期而言，考虑时间的因素。）
其实每个 Team 是或多或少用过 Git Flow，只是自己没意思到。大部分都是混合用的，也有可能命名并没有那么 git flow 那么严格
按《持续交付》的意思，其实除了主分支，就不应该有长期存活的分支
老马就是在说，这明明是 Continuous Delivery，为啥要创造 TBD 新名词 新概念！
用 git flow | github flow | tbd 其实没有绝对的方案，而是跟具体项目的 Release 周期有关。只是 现在的商业产品都在追求快速、Release 周期短，所以才说适用于 TBD。
ref: Trunk_Correlated_Practices_v2.8.pdf
结合CD来讲，因为之前在 VxxFxxx 里面用的git flow，这就意味着存在存活较长的分支，所以每个分支都要构建的pipeline，构建的产物通过更改deploy任务的配置，部署对应版本的构建到对应的环境，诟病很多，一是人为操作多了，二是pipeline数量和复杂度高了，维护成本高了
关于依赖版本管理与核心库升级：
React 的实践还挺好的，当前版本会把下一版本的 Feature 提前通过 warnings 的方式预告出来，修完 warnings 再升级，efforts 就很小咯。
也许在日常工作中，TL 或者某个角色需要订阅核心库的 Release CHANGELOG，每次 小版本都可以 update 跟上。
还有一个实践是 local 和环境上的 deps versions 一致性的问题，比如 yarn 的 lock file 的方式可以解决问题，那何时 upgrade version 以及 update yarn.lock 又是另外一个话题了，😂
那有没有可能集成某个 CI step，跟 npms 保持同步，显示某个 deps 的状态？
哈哈哈，我终于知道某些开源库为什么有 outdated 的 badge 了（类似 npm version 那种）：Dependency status for JimmyLv - Haiku v1.0.0 - David
