This article covers selected materials from speeches made on Github Universe 2019 in form of re-organized notes. All the copyrights of speech contents still belong to original authors. Please contact the author for any questions and concerns regarding the copyright.
原本是计划11月给自己放个小假，但当时还没有想好去哪儿。后来看到Chrome Dev Summit和Github Universe都在旧金山，而且时间恰巧都在同一周，所以就决定去旧金山遛一下，顺带还能去硅谷朝圣。Github Universe是自己买的Early Bird Ticket（完全没有指望公司能够报销），Chrome Summit是抽签免票机制，奈何自己运气不太好结果没有抽上。
去参加Github Universe的主要是想尝鲜感受一下，其次一大原因是想学习一下大公司在运维方面的经验。虽然目前工作主要是前端开发，但在参与不同项目的管理过程中，发现很多方面其实是有改进空间的，但是奈何经验不够导致自己对很多想法的可行性没有办法准确评估。
我之前有在多伦多的Web Unleashed做过志愿者，也听过几场讲座。将这样一个在多伦多地区算是顶尖的Fullstack峰会与其比较，Github Universe的质量可以说是高很多了，也看得出来技术的扩张力和深度推广在不同地区的程度是真的完全不同。然而，今年的内容感觉比起前几届的内容（youtube视频）要弱一些，主要是实践上的细节说明薄弱以及案例过于简单。
以下主要为当时参会时的笔记并做了简单整理。
Nov 13 - Keynote
Actions和Packages不再是beta版本。
Github Action:
- 直接由社区制作模版
- 在线IDE直接修改ci/cd config然后push触发ci在线build
- 可以适应不同的运行环境（Linux/Win/Mac），甚至还有self-hosted的各种环境
- 提供Cache用于dependency得以省时：PR可以直接查看Cloud的状态，并且PR里的check可以直接挂钩在云上
网站方面的改进:
- 代码内的Navigation： Ruby/Python/Go可以直接在网页里检查函数的definition和所有references
- 代码Search功能上的改进，原先是分词搜寻，现在可以做到完整搜寻（exact string）
- Reminder->Load Balancing用于PR中code review的assignment，不再局限于Round-robin, PR reminder on social apps, like slack
- Notification Panel的更新
Github Mobile App:
- 基本上属于移动网页版的优化版本
- 正常的PR review，issue和merge可以直接操作
- 最重要的是有ipad版本
Project 可以直接sponsor
Github Archive Program
- Arctic Code Vault: 把开源项目的代码放在挪威，以微缩胶片的形式
- 2020/02/02之前archived的所有代码都可以保存在这里
Nov 13 – Actions Packaged: Use GitHub Actions and GitHub Package Registry for CI/CD of any app, package, and service
Actions/starter-workflow
- Action里可以自动鉴别主要语言并提供推荐模版
- Helper function可以帮助跨平台的build
- Marketplace里有不同平台的add-ons插件
- Github 的每个repo里的settings 有个secret store，类似travis ci的调用方法
- Actions – Runner可以指定不同的env
Caching support是新功能，用于项目ci/cd构建时的dependency配置
Package的publish config一样融合在对应的yml文件里。没有太多亮点，只是self-host然后转载包信息至其他公共或私人平台上。
Deploy到online env，可以直接在github上查看情况。
New Workflow可以直接将指定的branch deploy到所需要的cloud env里，可以追踪谁build谁deploy。
Yarnbot里可以根据issue里指定的代码进行直接actions运行然后打上producible标签
Nov 13 – “Good code documents itself” and other lies: Changing work culture through documentation
没有什么太多实用的东西。大多是一些在代码中进行标注说明的规范要求。
Nov 13 – The elusive quest to measure developer productivity
主要讲解了如何在一个团队里衡量每个人的生产力。
The Flawed Five – metric
（measure the output instead of productivity）
- Commits
- Lines of code
- PR count
- Velocity points
- Impact
Commits
- 显然不精确
Lines of code
- 对于不同的code行数无法说明它的复杂性
- 不同的语言受到不同的影响
- 更精短的代码可能会有更大的影响
PR count
- 负面鼓励没用的pr上交
- 而且没有办法量化当前任务工作的粒度
Velocity points
- Sizing is done before work starts
- 完全estimate工作的本质
- 用于sprints
Impact
- 难以量化
衡量一个团队的生产力的本身意义并不只在于奖惩，更多的是在对于一个过程的衡量，而不单是最后的产出结果output。
Measure against target, instead of absolute numbers. And try to avoid individual metrics.
Nov 13 - The code behind cars: How GitHub turned Ford into a software company
主要在于众多的组件编译构建的pipeline设计，引入Github+Jenkins+Kubernetes的形式。
这种模式应该在众多软件公司里会经常用到，尤其是模块化分散至不同小组的情况。
Nov 13 - Building and deploying modern websites and apps
例如twitter和linkedin，每次启动时其实是一个markup page框架（空白无内容）。Piggybacked于一个前端框架上。
Serverless其实是对于前端开发者而言有利的。
Tailwindcss – 开发和设计的角色开始倾向于合并（直接在浏览器中实现设计）
“Frontend devs and designers want to share and receive feedback quickly.”
实现后端和前端的完全隔离，不用在意state和存储之类的内容。
Code review 转向 Deployment preview。不再是一个简单的diff并且修改得以通过测试的过程。而是直接在deployment之前的检查。比如在dev分支或pr上直接进行快速构建。
直接将deployment移进check项目中，甚至还能提供diff checks并且告诉用户哪里有修改。
Shipping to prod应该和merge to master一样的代价（简单）
但是出现问题之后只能merge ‘revert PR’
Alternate between URLs to reduce potential surface of error with measurable changes.
可以根据error rate进行自动revert（根据sentry提供的数据）
Nov 14 – Applying the Github security development lifecycle to your project
Example of financial corporation
当黑客有密钥和vpn链接时，可以直接寻找没有双重验证的服务器直接访问production network
对于malware的检查
2-factor auth
监控
Example of Credit Corporation
有众多微服务instances，并使用开源项目，其中某个服务器没有及时打补丁，甚至有明文证书，然而监控失效。
Example of Stuxnet
核电站的西门子PLC控制器
Security development lifecycle
- Training
- Design
- Architecture review
- Threat modeling（列出在整个服务流中每个节点（用户、服务、服务器、数据库）之间可能存在的安全风险）
- Secure development
- Inventory your dependencies（尽可能自己写，需要做security review）
- Verify
- Penetration testing/red team
- Google oss-fuzz
- Monitor & Respond
- Github – publish a security policy
- Incident response plan
- Github Security advisories
- Publish CVE
Nov 14 - How visualization helps developers
利用简单的饼图、线图来表示文件大小、FSM之类的。
更加直观，而不是用普通的纯文本表现。
基本上用visualization的方法demonstrate各种实际问题，比方说算法的分析。没有太多实用的干货。
Nov 14 - Machine learning operations with GitHub Actions and Kubernetes
Kuberflow -> open-source
https://ai.google/research/pubs/pub42576
develop model, deploy model -> kubeflow
automation, review -> github
Convert notebook to docker containers via kuberflow
Nov 14 - Ship happens: shipping pull requests at scale with the merge queue
在往年的Github Universe上，Airbnb亦曾做过有关DevOps方面的案例讲解。个人觉得非常值得一听。
YouTube：From Monorail To Monorepo: Airbnb’s Journey into Microservices
背景：shopify每天要做40次deploy。PR直接推出。Black Friday之前会进行一次code freeze，然后进行patching，很烦。
3 rules of shipping
- Master must always be green
- Master must stay close to production
- Emergency fixes must be fast
2016年的情况
流程：Create PR -> wait for branch CI (15mins) -> merge
结果：有很多的PR会同时merge，这样会有很多低效情况，比方说master上的CI要疯狂并行跑，然后deploy一系列（1个cluster包含多个PR的修改）已经通过测试的PR到production。同时每个dev都能监控他们的PR状态。
反思：这个流程是有问题的。
- Conflicts
a) Soft Conflicts，已经merge的PR修改某处并通过测试，导致另一个PR直接fail。很多人并不知道master现在挂了，所以他们会继续merge PR
b) 如果采取revert操作，在出现问题的PR和revert之间的所有PR全部报废 - Drift
a) Master比production还要far ahead
b) 一个紧急补丁会导致情况1的出现
改进方案
整个Merge Queue还是一个Predictive-branch。
Merge Queue Version 1
按下‘merge queue’按钮，将该PR加入merge queue，然后merge进master的顺序得以控制，还是可以分批依次拉入master。甚至可以lock住merge暂停合并（在推进emergency fix的时候）。
问题1: 很慢。后续的PR要等很长时间才能merge进，甚至更长的时间才知道会不会有问题。
问题2: “Add to merge queue”是通过浏览器的extension实现的，不是github原生的。原生的merge按钮还是留着为了emergency fix。
Merge Queue Version 2
类似airbnb的方法，在comment里‘/shipit’触发PR加入merge queue。CI直接在merge queue里的每个PR上运行（PR本身在这之前已经运行过CI了），master直接fast-forward到last-passing最后测试成功的PR。甚至可以lock住merge暂停合并（在推进emergency fix的时候）。
如果queue中间的某个PR没有通过CI测试，把这个PR拿出来的代价太高，因为会直接导致这个queue所在的branch结构直接打乱。Tolerate fail机制，把有问题的PR留着，如果后续的n个PR还是出问题，就把这个有问题的PR拿出来。
同样的 short-cut ‘/shipit –emergency’可以直接将PR推进master。
底线保证
- Automatic removal of failed PRs from the queue
- Evergreen master
- CI before merge
潜在问题
Removing a PR from the queue resets CI statuses
Skipping the queue to reset CI statuses
未来改进
Parallel tree：每个tree缺省一个不同的PR，进行排列组合得以交叉检查确认哪个PR会是潜在的导致CI fail的原因，然后把全部passed的组merge出去。
评论