cloud几十分钟解决？你看过新闻吗？亚马逊的aws down了7个小时的都有。 production server resource monitoring是最基本的。有些bug测不出来不代表之前那些乱说的帖子说check in的code会自动merge到production code然后自动production release，说啥现在不需要qa, 完完全全的说是放屁都不为过。
你说一句，错一句！code merge之前unit test过了，并不代表和其他部门的code merge后不会起冲突，产生新的bug。所以要有production release final version，最后还要qa unit test和各个部门sign off. Unit test抓不完就release了？一次损失几百万而已？production有bug要rollback，要多少人参与？做无用功吗？笑死人了，越说越离谱。
cloud几十分钟解决？你看过新闻吗？亚马逊的aws down了7个小时的都有。 production server resource monitoring是最基本的。有些bug测不出来不代表之前那些乱说的帖子说check in的code会自动merge到production code然后自动production release，说啥现在不需要qa, 完完全全的说是放屁都不为过。
要test stage是为了在release前找出bug，不是说能找出所有的bug。这么超级简单的逻辑不懂吗？连这个都要争论，都要杠吗？哈哈哈😂。 随便网上找一下都有推特公司自己staging test的详细内容。非常industry standard的procedures。都不知道哪个公司会不test就release。还和我争check in就可以release了。这个贴里和我杠的水平低的真的可以。我一个做金融的居然还要和你们争互联网公司有没有QA/Staging test那么低级的问题！ https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service. Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics. Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
好的产品在production 出现bug的几率应该很低，如果出现了特殊数据才能trigger的bug，说明测试不够，或者程序写得不够好，不能容易的完成test. Unit test and integration test 还有performance test, 这么多test都抓不住影响巨大的bug, 那只能说明project 管理有问题。 Production 可以有bug, 但是不应该是影响巨大的bug. 而且有些bug 是有workaround 的。 最糟的程序就是bug 在非常特定的情况出现，与developer 水平相关，也跟测试相关。
好的产品在production 出现bug的几率应该很低，如果出现了特殊数据才能trigger的bug，说明测试不够，或者程序写得不够好，不能容易的完成test. Unit test and integration test 还有performance test, 这么多test都抓不住影响巨大的bug, 那只能说明project 管理有问题。 Production 可以有bug, 但是不应该是影响巨大的bug. 而且有些bug 是有workaround 的。 最糟的程序就是bug 在非常特定的情况出现，与developer 水平相关，也跟测试相关。 chengyixiaohao 发表于 2022-11-25 19:43
只能说你们业务简单。没有上下游或者上下游简单。上下游复杂的，如1000多个call/service那种，你都不知道该测哪个版本，也搞不清楚上下游的release plan。如果因为上下游改了导致编译通不过或者跑不起来或者fail unit test当然简单。这一种相当常见。怕的就是季报的时候finance audit才发现的bug那种就搞笑了。
好的产品在production 出现bug的几率应该很低，如果出现了特殊数据才能trigger的bug，说明测试不够，或者程序写得不够好，不能容易的完成test. Unit test and integration test 还有performance test, 这么多test都抓不住影响巨大的bug, 那只能说明project 管理有问题。 Production 可以有bug, 但是不应该是影响巨大的bug. 而且有些bug 是有workaround 的。 最糟的程序就是bug 在非常特定的情况出现，与developer 水平相关，也跟测试相关。 chengyixiaohao 发表于 2022-11-25 19:43
呵呵呵，看到他写了那么多test了吗？你以为staging test server每个马公一台啊，跑几分钟就完事了啊。你要release，别人也要release。每天十几个人都check in了，几个发现问题不release了，其他checked in的要release怎么办？还要拿对方退出的code version还要重新test一遍，第二天又重复发生同样的事情。那么多人每天大家merge code，unmerge就乱套了。还没说放在production几个星期慢慢开放给大众呢，天天release，怎么manage？ 没在大公司做过，连对方写的都看不懂。 3. 每个项目都会有非常详细的launch plan，包括ab testing, ramp up plan, bug bash date, successful matrix等等。ramp up plan就是规定这个feature switch先对内部earlybird开放测试，测多久，然后对某个特定用户组开放，或者是抽样1%用户，再慢慢到5%，20%… 100%。ab testing是为了对比两组用户的matrix以证明这个feature不会降低mdau并且达到之前的goal才会继续ramp up 推特官方test procedure都在网上。写了就release，开玩笑吗？ https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service. Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics. Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
呵呵呵，看到他写了那么多test了吗？你以为staging test server每个马公一台啊，跑几分钟就完事了啊。你要release，别人也要release。每天十几个人都check in了，几个发现问题不release了，其他checked in的要release怎么办？还要拿对方退出的code version还要重新test一遍，第二天又重复发生同样的事情。那么多人每天大家merge code，unmerge就乱套了。还没说放在production几个星期慢慢开放给大众呢，天天release，怎么manage？ 没在大公司做过，连对方写的都看不懂。 3. 每个项目都会有非常详细的launch plan，包括ab testing, ramp up plan, bug bash date, successful matrix等等。ramp up plan就是规定这个feature switch先对内部earlybird开放测试，测多久，然后对某个特定用户组开放，或者是抽样1%用户，再慢慢到5%，20%… 100%。ab testing是为了对比两组用户的matrix以证明这个feature不会降低mdau并且达到之前的goal才会继续ramp up 推特官方test procedure都在网上。 https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service. Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics. Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
呵呵呵，看到他写了那么多test了吗？你以为staging test server每个马公一台啊，跑几分钟就完事了啊。你要release，别人也要release。每天十几个人都check in了，几个发现问题不release了，其他checked in的要release怎么办？还要拿对方退出的code version还要重新test一遍，第二天又重复发生同样的事情。那么多人每天大家merge code，unmerge就乱套了。还没说放在production几个星期慢慢开放给大众呢，天天release，怎么manage？ 没在大公司做过，连对方写的都看不懂。 3. 每个项目都会有非常详细的launch plan，包括ab testing, ramp up plan, bug bash date, successful matrix等等。ramp up plan就是规定这个feature switch先对内部earlybird开放测试，测多久，然后对某个特定用户组开放，或者是抽样1%用户，再慢慢到5%，20%… 100%。ab testing是为了对比两组用户的matrix以证明这个feature不会降低mdau并且达到之前的goal才会继续ramp up 推特官方test procedure都在网上。写了就release，开玩笑吗？ https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service. Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics. Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
那个应该是DNS问题吧。感谢（CISCO）核心路由器，时有发生。我们这小厂都出过。TCP/IP的原罪，无解。
你说一句，错一句！code merge之前unit test过了，并不代表和其他部门的code merge后不会起冲突，产生新的bug。所以要有production release final version，最后还要qa unit test和各个部门sign off.
Unit test抓不完就release了？一次损失几百万而已？production有bug要rollback，要多少人参与？做无用功吗？笑死人了，越说越离谱。
我不了解全部。但互联网大厂也有没有QA/QE的了。这是潮流。现在是SE兼任QA/QE。干不干得好上面说了算。上面的Leadership。
Release是自动的rollback也不需要很多人。这是“技术进步”。
几百万刀算多的了。别看YT等用户多，每个用户没几厘钱。而且release也不可能一下子更新重启数以万计的instance。本来就需要时间。如果bug明显，1%的时候就抓到了。
你连在网上看一下亚马逊的aws为什么down还不会吗？还什么DNS那么低级的错误？别在秀你的知识量好吗？
https://www.wsj.com/articles/amazon-web-services-appears-to-be-down-for-many-users-11638898270
真没看。穷，华邮网站要收钱。看不了。
真的是啥都不懂，嘴巴轻飘飘。反正你的能力已经摆在那里了，连自知之明都没有。
能不能先把principal engineer拼对再吹牛逼。
对。能怼niuheliang（计算机）的谁说不是牛人。
你人真好啊
大妈不会相信你的🤣
睿大妈你这样见人就怼，怼了半天还记得你自己的观点是啥吗？
当然记得了，楼主说因为很多人check in code，所以production上一大堆bug, 广告商撤了一半。check in code可以有bug都不需要QA直接上production。
还没说有些check in是要和其他部门或者UI和backend配合一起上production。app审查也有时间，好像可以随随便便check in就release到production一样。
嗯，还有那么多bug, 都是广告商的。推特本身都没出任何问题。
说了一圈，推特本身增加了很多用户和流量，完全没有问题。
agree
你退休是很久了
大厂都没有QA. Canary release, monitoring/alerting, slow ramp，先在公司内部release，每个员工都是qa。等等。出了错，rollback其实很简单，都不用redeploy，click一个button，就可以把新feature turn off。所以出个bug，也没啥大不了的
知道部署上线还有alpha beta gamma环境，最后才到prod么？知道shadow deployment不？知道canary test不？
dev本地测个屁啊，毫无意义。那种级别的bug只有在大规模线上环境里才会冒头。
这种bug 引起的impact都是可以查得到的，会退钱，还会赔钱。当然，真要走，也没办法。
哪个大厂没有bug啊，出了bug，fix完，都是马上evaluate impact。出个bug，是不好的，但天也都塌不下来。要fast development，就要允许一定的bug
说到点子上了，QA根本没法阻止production出问题，有load testing都没法保证。互联网公司release非常频繁， 那个睿大概还活在上世纪，一季度一个release的节奏。
我从来没说过QA能抓所有的bug. 我怼的原话是没有QA，因为dev check in 的code会被自动release到production。这种话完全是放屁。
CICD就是这样啊，code merge就initialize prod release 加上一些smoke tests.
任何互联网大厂都是这样cicd，你还在这里丢人现眼
我的天，至少5年没听说过release cycle这个词了
只有要实际发布设备端软件，比如apple，tesla，amazon echo，这些部门才会有qa。因为他们测试的是一个release的内容，这个内容是固定的
cicd根本没有release的概念。所有的东西都是pipeline的一环，rolling basis, 只有dependency，只有每次测试时临时snapshot出来的version set。没有固定的release。懂么？
睿大妈手里五百万是迷之自信啊。相比之下老马算礼贤下士的了。
CICD不代表checked in code就自动上production。如果你完成一个stage只是要放在repository里，或者check in要给另一个developer用。楼主原话是太多code checked in，所以一大堆bug上production.
这就是事实。cicd的基本假设就是小问题可以立刻roll back.大规模互联网平台从来不是非黑即白要保证任何时候都完美正确的。
如果大量互相dependency的东西同时进pipeline，整个pipeline就会崩溃，没人知道到底什么work什么bogus了
你说的好像cicd是个玩具一样，code dependency一向都是非常复杂，说啥pipeline崩溃，没人知道怎样work也太搞笑了。
打脸，看到第一张图的release了吗？第二张图的deploy to production 了吗？看到两个都有test stage了吗？知道啥是release schedule吗？知道holiday release freeze吗？难道code也不能check in了？
正是因为太复杂，所以很多问题只有production才会冒出来。可能你们厂有stage，很多厂都是直接上prod的，不要瞎评论了。
太复杂，只有在production才冒出来？开玩笑吗？QA environment是做啥用的？各种test scripts 可以simulate绝大多数production case，包括regression，traffic load, 各种contingency cases等等。让production bug减到最低化。
所以有些人还是得苦哈哈的工作，厉害的人早就可以享受生活了。
我这个月刚好给组里面了几个sre。你这种屁话一说出来直接挂。毫无基本常识lol
对。别说假日，就是周五也不code review/merge。On call那位一定会骂死周末半夜被叫醒的。
好吧，你面试的人得说bug不需要test stage找出来, bug 到production冒出来再rollback。写sre还值得炫耀的？哈哈哈。
我回你的图看到了吗？
你每天还要工作，我不需要了，看到difference了吗？
睿大妈不要总以为自己有五百万现金，别人就不能也有几百万资产。也不要总认为混到几千亿了就不工作了。这就是difference。
正因为你不工作了，所以你out了，很合情合理啊。为啥你觉得自己就是对的？
任何行业都要test stage。难的不是吗？说啥automate, 新的feature也要有新的test。这个是不变的基本常识。在哪个行业都是！
那个公司做的东西到production才开始找bug，说明你们的东西根本不重要，懂吗？
我有5米就够钱变钱了，其他人没有这个本事有这个consistency赚钱。
所以大多人再有钱也得辛辛苦苦打工赚钱。因为他们只有这个本事可以赚钱。
canary servers就是test environment，在canary上test发现了问题，roll back就好了。但是一个网站运营的各个环节，automated test甚至canary上的manual test都不一定能全部cover到。很多时候只有出现了问题才知道，比如那个广告商发放了太多广告，要到广告部门自己的alert被trigger了才会发现。
就这？lol
我不管当下networth还是pre ipo纸钱都不止5m，但是一想到fire以后可能会跟你这号人混一个圈子，那还是算了。职场正常人多。
这个automate regression test case没有写好。哪些key words 或者user category trigger哪些广告，这个是最基本的广告test logic吧。根本不需要到production才知道。
好吧，截个屏上来吧，投资账户或者银行都可以，秀个两百万小钱总可以吧。
还pre IPO呢，定价多少知道吗？现在这个市场还没IPO的以后能不破产已经走大运了，哈哈哈。
你为了不和我沦为一群，甘愿工作到死，你的逻辑真的是顶呱呱👍！
睿大妈临时Google了一些名词，可以给一分苦劳
你那个ps的截屏都没人把底裤都扒没了。怎么又拿出来说事，是以为这里都是新人没人知道你老底？
老天在上，如果我的截屏是ps的，我死全家。如果不是ps的，你死全家，别逃，敢不敢发誓？
https://huaren.us/showtopic.html?topicid=2826052
有啥可无语的，加州前后都要挂的呀。但是，警察不是不敢给，是人家懒得抓，抓一次没多少钱，除非还有其他问题就顺带了，身边有俩朋友最近就是因为顺带给罚了。
我对你的本事表示怀疑。钱看好了。脸皮很厚倒是真的。
拉倒吧，真有相信美国微信那个笑话？
Why not。还能比去火星更好笑？
我看的挺好的，去年5米多一点，现在还是5米多一点。我自己本事几斤几两，我有自知之明。
你可以辩解我写的逻辑。我只是说我不需要靠苦哈哈每天工作赚钱。我靠我自己的逻辑赚钱。
很多人觉得自己懂的很多，喜欢夸夸其谈，然后在自己懂的领域又不敢投资，扔钱就亏，矛盾的很。
最搞笑的还说一龙不懂，好像华人说的这些事情一龙没有这个智力理解一样，lol。
笑话还是真事等等看呗，星链，发火箭之类的一开始也都像笑话。 open mindset vs fixed mindset。。。
前Tweep给你科普一下 1:release是自动的。但是release当天还是要oncall一路盯着monitor各种sentry error啥的 2.正常情况新的feature都是藏在feature switch后面的，就是一个开关，即使code到了production，普通用户也trigger不了 3. 每个项目都会有非常详细的launch plan，包括ab testing, ramp up plan, bug bash date, successful matrix等等。ramp up plan就是规定这个feature switch先对内部earlybird开放测试，测多久，然后对某个特定用户组开放，或者是抽样1%用户，再慢慢到5%，20%… 100%。ab testing是为了对比两组用户的matrix以证明这个feature不会降低mdau并且达到之前的goal才会继续ramp up 4.正常一个项目从代码进production到真正release给所有用户一般几周到数月都有可能。 巴特，马一龙哪等的了，来了以后要求一周release blueverified，包括写代码和所有的launch plan，还有apple那边需要快速approve才有可能。他要是有个正经ramp up plan，impersonate的事情应该早意识到了。 他比较明智的是code freeze了所有blueverified以外的change，不然估计twitter早崩了
对手不一样
你上次也说过类似的话吧？结果还是被扒皮了。你这样泼妇骂街似的赌咒发誓有屁credit
嗯，你说的非常靠谱，毕竟release到那么多servers上肯定是trigger一个automated job来release。不可能一个个server放上去，然后restart所有的production server processes. 都是半自动的。release team可以看release后的servers health status然后慢慢release。
看具体是什么feature了，有些比较simple的feature上了production就trigger了，不需要多一个logic layer，特别是完全新的internal feature来improve stat collecting的。当然你们比较小心也完全understand。有些的确要switch，特别是改进improved的feature，有时间限制或者用户端dependency的。
blueverifed的确一龙操之过急了，没有人能提出或者说服一龙多简单impersonate我个人感觉非常意外，因为是一个非常好表现自己的机会，让一龙刮目相看。不过可能一龙没钱也顾不了那么多了，低估了网上那么多闲人喜欢恶搞的热情。
大裁人的情况下肯定不能release code。他release了blueverified感觉他钱袋的确太紧了，哈哈哈。
谢谢你的帖子，收益良多。🙏
自己没本事，还要怀疑别人。动真格的又不敢发誓来个痛快的，只会继续发牢骚。没本事加上说谎没信用，只会骂个不停，你全占了。
原来你最牛，你们的product bug free！
要test stage是为了在release前找出bug，不是说能找出所有的bug。这么超级简单的逻辑不懂吗？连这个都要争论，都要杠吗？哈哈哈😂。
随便网上找一下都有推特公司自己staging test的详细内容。非常industry standard的procedures。都不知道哪个公司会不test就release。还和我争check in就可以release了。这个贴里和我杠的水平低的真的可以。我一个做金融的居然还要和你们争互联网公司有没有QA/Staging test那么低级的问题！
https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter
In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service.
Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics.
Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
Production 可以有bug, 但是不应该是影响巨大的bug. 而且有些bug 是有workaround 的。
最糟的程序就是bug 在非常特定的情况出现，与developer 水平相关，也跟测试相关。
只能说你们业务简单。没有上下游或者上下游简单。上下游复杂的，如1000多个call/service那种，你都不知道该测哪个版本，也搞不清楚上下游的release plan。如果因为上下游改了导致编译通不过或者跑不起来或者fail unit test当然简单。这一种相当常见。怕的就是季报的时候finance audit才发现的bug那种就搞笑了。
做了integration test, 上下游关系就理顺了。前面层主写的Twitter的release 过程非常好， make sense. 所以新feature 出问题就是没有做好测试，太心急。
1000个call就复杂了，笑死人了，server上几千个schedule的jobs怎么办啊。你知道啥是staging吗？上面有production和pre release两个不同的farm。然后所有的job和service从头到尾都跑一遍。每天不停的跑看comparison matrix，哪里慢了，或者数据对比不一样都会显示。
你说的情况是理想情况，楼主已经说了现在是twitter人都快被裁光了，很多东西找不到人负责查验就给release到production了。码农都知道在这种情况下这是多么容易发生的事情，不出漏子才是不正常。
有推特员工在帖子里出来澄清了只有blue verified上了production而去rollback/turn off了。所有其他release都freeze了，根本没上production。楼主给打脸了。
一龙如果只会乱来会开成功那么多公司而且个个都成为龙头吗？难道对手都是猪吗？好好想想。
每个feature都要这么长的流程吗？有些小改动不需要这么大阵仗吧？
基本常识：即使小改动也都全部放在一起test和release的，不是每个部门每个马公写了一点就release的。否则有1000个马公得天天release。
每个release都有一长条list，最上面是新的feature，下面是bug fix.
就是写了就release，只是behind feature flag，你还是没看懂。
上下游都是moving的。你肯定没经历过过抢火车晚一天release不了要rollback或者昨天好好的今天被别人release搞死的事情。
大家能理解您out了，您就别跑出来献丑了
呵呵呵，看到他写了那么多test了吗？你以为staging test server每个马公一台啊，跑几分钟就完事了啊。你要release，别人也要release。每天十几个人都check in了，几个发现问题不release了，其他checked in的要release怎么办？还要拿对方退出的code version还要重新test一遍，第二天又重复发生同样的事情。那么多人每天大家merge code，unmerge就乱套了。还没说放在production几个星期慢慢开放给大众呢，天天release，怎么manage？
没在大公司做过，连对方写的都看不懂。
3. 每个项目都会有非常详细的launch plan，包括ab testing, ramp up plan, bug bash date, successful matrix等等。ramp up plan就是规定这个feature switch先对内部earlybird开放测试，测多久，然后对某个特定用户组开放，或者是抽样1%用户，再慢慢到5%，20%… 100%。ab testing是为了对比两组用户的matrix以证明这个feature不会降低mdau并且达到之前的goal才会继续ramp up
推特官方test procedure都在网上。写了就release，开玩笑吗？
https://blog.twitter.com/engineering/en_us/a/2014/push-our-limits-reliability-testing-at-twitter
In staging Load testing: Performing load tests against few instances of a service in non-production environment to identify a new service’s performance baseline or compare a specific build’s performance to the existing baseline for that service.
Tap compare: Sending production requests to instances of a service in both production and staging environments and comparing the results for correctness and evaluating performance characteristics.
Dark traffic testing: Sending production traffic to a new service to monitor its health and performance characteristics. In this case, the response(s) won’t be sent to the requester(s).
所以要抢跑啊。给你两周结果两月都release不了就等着PIP好了。
啥抢跑啊，code freeze没读懂啥意思吗？难道是放冰箱吗？连我一个不写code都知道啥意思的居然你读不懂！？
他比较明智的是code freeze了所有blueverified以外的change，不然估计twitter早崩了
我不知道该怎么评论您这一段话为好。您还是多谈怎么不投资股市吧。
真的是，人家第一句话就是：release是自动的。这就是cicd的原则。如果pipeline里面跑没有发现有问题，而且还behind feature flag，cicd process就自动release到prod了。至于end user能用到这个feature，可能是几个月后的事，跟你说的feature list是两回事，那是以前还有release engineer的时候他们的工作。 为什么是code freeze而不是release freeze？因为只有把code freeze了才不会被自动release到prod去。
反正一年差不多见分晓吧。
这回一龙是龙，还是马应龙，大家见证历史就是了。
楼主都删了了原文了，这儿还在吵，哈哈
人家有钱任性。不如说说一年后一龙还是不是首富。人家现在股价腰斩，套现200多亿，还是首富。
一龙是不是打算玩每年 100 亿 的滑滑梯？
当然，霸道总裁有钱就可以任性！！
字都认识，不知道你在说啥系列。我是科班出身。你说不出个啥，或者不懂前面那个tweep说的啥意思，能不能不懂装懂？我看着你这回复难受。
你是鸡同鸭讲，睿她根本不懂啥叫flag…却还要不懂装懂，笑死我了。
牛人不会鸟他这个神经病剩下的菜一点很难理解吗？
笑喷了，睿大妈还在这儿“test server每个马工一台” lol
让我想起我大概7,8年前， 从硬件公司第一次面试互联网公司时候，中午吃饭闲聊问了面试官一个问题：
你们的devbox啥配置啊？
面试官听得一头雾水。啥叫devbox？我们开发在云上，测试也是云上pipeline。每个马工都能随时起几千个instance，几十万个task，为什么要给每个马工单独配一台机器？
睿大妈你就承认你那点传统公司的眼界完全out了，好好学习一点新趋势不好么？非要在这里死杠。
帖子本来在讨论架构，莫名其妙成了讨论测试，大颈睿是真的不行，人生直线往下走哇
不是废话吗？instance中文就是一台啊。几十年前都是remote login了。哪个公司会server放自己桌子底下的自己用的？？？ cloud的好处就是instance在cloud上可是你可以完全感觉不到，可以当作一般server用。
我个人不相信twitter的完整production replicated的staging server可以一个人一个instance来做测试。即使在cloud上面公司也没那么多钱砸在hardware和software/db license上。除非是个小公司做个小游戏啥的，这种推特大型的software要build可能都要很久。一般staging server都是shared.
还有一点肯定不是build就pipeline released的因为不可能低阶的developer可以check in后马上自动放到production。因为新的feature没有新的test case照样能过，或者test case给developer改错了，output都是对的，production就出问题了。staging to production server deployment 一般都有把关有权限的，不是完全自动的。
看来你完全不懂啊。code freeze是指production code freeze。哈哈哈，难道code freeze dev就不能写code，check in dependent的shared code了吗？code freeze就不能做staging test了吗？很多case都是holiday code freeze period 一过，第二天就production release了，都在freeze period里做好了。不懂就别乱说一通了。
你的造谣贴已经给推特工作人员打脸了，说什么一大堆bug release在production上！？ 推特都code freeze了，除了blueverified 其他根本没有release。
你写了一大堆我一看就是编的，先被我打脸还被推特人员打脸，还好意思露脸。
打啥脸？你很激动地回那个贴说了一堆，人家回你说你压根没看懂他在说啥。我在FAANG当manager的时候你还在廊坊踩缝纫机呢。
现在马斯克要求大家show code，所以每个人都在胡乱check in code，造成更多的bug。
别以为删了原帖，大家就看不到了。你说因为大家都要check in code，然后一大堆bug上production。还faang manager呢，哈哈哈。check in可以不是production release的branch那么基本的知识都不知道吗？还没说testing都过不了怎样release？ 最后戳穿你谎言的是一龙code freeze了。每句话都一大堆逻辑错误，完全是造谣贴，你真不要脸还在这里装作没看见继续耍泼耍赖啊。
都是错的