Amazon的内部工具比Google

用过亚麻的cloud desktop，再用FB的on demand，感觉亚麻内部工具组都在吃屎。亚麻你需要自己申请一台host，然后用一个pipeline来维护它，然后专门跑一个script把本地的代码同步上去（每开一个新的workspace都要重新设置一下）。然后你要测试的时候还得ssh上去跑一堆命令，最后再浏览器里手动设置override和test page才能看到效果。
FB你只需要打开vscode，点一下on demand，然后写完代码保存。直接浏览器里加上od就自动能override到你的测试代码上去了，甚至连手机端都可以自动识别sandbox。断线了所有编辑都自动保存，下次再开换一台host，一切都无缝衔接。开发效率高了几条街。

zhangyi3737 发表于 2022-6-24 14:59
没在脸工作过，说说为什么好两个数量级？ CD的优劣不能光看每天deploy的次数，而要看减轻了多少工程师的开 ...

FB大部分产品组的工程师完全不用管pipeline，亚麻基本每个组都常年要留一个工程师别的不干就折腾pipeline的那些破事。

我没有去过脸也没有去过G，但是我觉得肯定各有所长。
我一直觉得亚麻的Tools组是最牛的组之一，因为我能很清楚的看到很多改进，当然时间可能是以年为单位的。
看到有人吐槽Apollo和Pipeline，我觉得这两个都是极好用的工具。
- 我觉得最近一两年Pipeline最大的改动就是增加stats，这样每个stage的失败次数甚至每个test suite的失败数据都有了，非常适用于OE进步。
- Apollo的变化不大，因为已经够强大了，但是可以看到Deployment Pref的加强。
简单的说，COE导致Runbook更新，然后ORR更新，然后Tools跟进，这个不断迭代进步是非常显著的。

另外也有人提到的一点，不是Tool不行，是你用的不行，我也是绝对同意的。
我说iGraph是YYDS，加入亚麻前两年觉得正常，第三年因为Ops重需要很多trouble shooting才开始仔细看它的dimensions，然后还有自己的Painting Wiki，然后才真正感触到了，一图胜千言。

说到这里，必须给Alexa Atocha打call了，比cloud watch不知道好用到哪里去，他们的lead和founder好像是国人，大大的赞。

造反精兵 发表于 2022-6-24 16:31
FB大部分产品组的工程师完全不用管pipeline，亚麻基本每个组都常年要留一个工程师别的不干就折腾pipeline ...

平衡的说是各有利弊。

脸的工程师跳槽到小公司这些破事还是会自己找上门来。

麻麻们各各都是经过历练的

t__c___ 发表于 2022-6-25 08:19
我没有去过脸也没有去过G，但是我觉得肯定各有所长。
我一直觉得亚麻的Tools组是最牛的组之一，因为我能很 ...

. “另外也有人提到的一点，不是Tool不行，是你用的不行，我也是绝对同意的“

只能说没有对比就没有伤害。

hgon23 发表于 2022-06-25 12:13:04
“另外也有人提到的一点，不是Tool不行，是你用的不行，我也是绝对同意的“

只能说没有对比就没有伤害。

我井底之蛙了 争取以后可以多学习

hgon23 发表于 2022-6-24 15:27
亚麻的内部工具（非Native AWS）都比较难用，并且文档残缺。

举几个例子

LPT是真的垃圾

明明就是template，非要用一个麻里面是个人都不怎么碰的ruby来搞，而且debug莫名其妙

不过NAWS的体验确实不一样

在AWS我们就直接用ec2了，基本不去管brazil/apollo那一摊子破事儿，基本就是用brazil构建一下service

亚麻内部tool其实还是默认java才能用的舒服，其他都是after thought

mr_putin 发表于 2022-06-23 00:17:54
你们难道都没有被亚麻的version set的各种不同版本冲突蹂躏得死去活来么？

gk-fix-mv-conflicts

hgon23 发表于 2022-06-24 14:10:11
脸的Scuba对标麻的iGraph, 个人觉得Scuba高级了2个数量级。

脸的CI/CD也比较牛逼，每天deploy +10次，对比AWS S3，一个月半自动deploy1 次

CICD 跟 s3 有啥关系，只要 source 有新的 commit 就开始 deploy 了，想 deploy 多少次都行