5 ms·

A lot of organization don't have continuous deployment because they can't risk breaking everything for any developers who is playing around. When they want to r

A lot of organization don't have continuous deployment because they can't risk breaking everything for any developers who is playing around. When they want to release, they review everything, test and go through QA. Facebook is not important. It has no impact when it's broken.

latchkey 9y ago
I helped build a business that did about $80m in gross revenue in the first year. We launched the initial version in 3 months (which we predicted to within a week). Started with 2 engineers (myself and another guy) and grew it to about 15. Zero QA, Zero DevOps. We had CI/CD and a full test suite. We deployed from master as many times a day as we needed / wanted. It can work if you open your mind to it and you hire the right people who know what they are doing.
- user5994461 9y ago
  And I was at business with $800M and 30 employees. Just because it releases quickly and has no QA doesn't mean it's a good thing. The only metrics that matters is calls from your users. Facebook doesn't even have a number to call when it's broken.
rb2k_ 9y ago
Keep in mind that the quarterly earnings report was 9.32 billion USD. That is approximately 100 million a day. I'd say downtime at that scale is important. Also: People tend to call the police: http://time.com/3071049/facebook-down-police/ http://time.com/3071049/facebook-down-police/
- user5994461 9y ago
  It's extremely low revenues per person and per page view.
renaudg 9y ago
Whereas I'm sure whatever you worked on had 1.32 billion active users everyday. Facebook is "7th most valuable company in the world" important.
- user5994461 9y ago
  1.32 billion FREE users.
  - gaius 9y ago
    1.32 billion units of inventory FTFY
breeny592 9y ago
Except to their own companies bottom line, generating millions in revenue? Releasing less often is a way to guarantee that bigger bugs will get through at some point, requiring hotfixes etc. The more you release, the higher quality releases you have, and the smaller production incidents. The point isn't to remove QA, it's to trust that the automation in place is high quality and will catch the majority of issues before they are issues (i.e. if something makes it through the automation, then it should be caught in the internal release, or at least the 3% canary group), and then on the back of issues, make the automation more robust. The more people who are introduced into a process, the more likely it is to fail at some point - the fact is that Facebook has a pretty low rate of huge production issues compared to most software companies, they must be doing something right.

latchkey 9y ago

I helped build a business that did about $80m in gross revenue in the first year. We launched the initial version in 3 months (which we predicted to within a week). Started with 2 engineers (myself and another guy) and grew it to about 15. Zero QA, Zero DevOps. We had CI/CD and a full test suite. We deployed from master as many times a day as we needed / wanted. It can work if you open your mind to it and you hire the right people who know what they are doing.

user5994461 9y ago
And I was at business with $800M and 30 employees. Just because it releases quickly and has no QA doesn't mean it's a good thing. The only metrics that matters is calls from your users. Facebook doesn't even have a number to call when it's broken.

rb2k_ 9y ago

Keep in mind that the quarterly earnings report was 9.32 billion USD. That is approximately 100 million a day. I'd say downtime at that scale is important. Also: People tend to call the police: http://time.com/3071049/facebook-down-police/ http://time.com/3071049/facebook-down-police/

user5994461 9y ago
It's extremely low revenues per person and per page view.

renaudg 9y ago

Whereas I'm sure whatever you worked on had 1.32 billion active users everyday. Facebook is "7th most valuable company in the world" important.

user5994461 9y ago
1.32 billion FREE users.
- gaius 9y ago
  1.32 billion units of inventory FTFY

breeny592 9y ago

Except to their own companies bottom line, generating millions in revenue? Releasing less often is a way to guarantee that bigger bugs will get through at some point, requiring hotfixes etc. The more you release, the higher quality releases you have, and the smaller production incidents. The point isn't to remove QA, it's to trust that the automation in place is high quality and will catch the majority of issues before they are issues (i.e. if something makes it through the automation, then it should be caught in the internal release, or at least the 3% canary group), and then on the back of issues, make the automation more robust. The more people who are introduced into a process, the more likely it is to fail at some point - the fact is that Facebook has a pretty low rate of huge production issues compared to most software companies, they must be doing something right.