페이스북은 어떻게 개발하고 배포할까?

 [페이스북 부트캠프에서의 첫번째 코드커밋 분포]

 

빠른 배포가 코드베이스에 큰 변화를 초래하는 기능 개발과는 어울릴 것 같지 않지만, 큰 기능 개발이라는 것도 작고 안전한 절차로 구분하여 쪼개면 가능합니다. 또한 페이스북은 Gatekeeper를 통해서 사용자가 보게되는 코드의 기능들 통제함으로써 개발자가 신규 기능을 최종 사용자에게 바로 노출시키지 않고 배포를 점진적으로 증가시킬 수 있도록 만들어 줍니다. (dark release로 config flag를 통해 작은 규모의 사용자에게 신규기능을 노출하여 검증하고 릴리즈 확장)

 

모든 페이스북 프론트엔드 개발자는 단일 코드베이스에서 작업을 합니다. 따라서 코드를 따로 브랜치했다가 트렁크(trunk)에 모아 통합하는 수고를 하지 않아 빠른 개발이 가능해집니다. 이에 따른 장단점이 있겠지만 이런 대규모 코드베이스를 하나로 가져간다는 것은 비지니스 특성과 엄격한 엔지니어링 기반이 뒷받침되지 않으면 어렵겠죠. 일반적으로 지속적 배포에서는 통합의 비용과 복잡함을 증가시키므로 코드브랜치 대신에 UI 상에서 기능을 온/오프시키는 feature toggles이나 아키텍처에서의 변경이 필요하면 branch by abstraction을 사용할 것을 권장합니다. 페이스북 개발자는 깃(Git)을 통해 자신의 개발코드를 로컬에서 관리하고, 릴리즈할 안정적 코드는 서브버전(subversion)의 중앙 리파지토리에 커밋하게 됩니다. 

 

페이스북 엔지니어들은 주당 평균 2~3회 정도 커밋을 하는데 커밋 간격은 몇 시간 이내입니다. 커밋 성공율은 횟수가 늘어남에 따라 극격하게 줄어들며 주 10회 이상 커밋을 하는 엔지니어는 거의 없습니다. 최적의 배포 사이클은 배포 비용, 에러 발생 확률과 처리비용, 점진적 효익의 가치, 엔지니어의 기술과 문화 등 고려할 사항들이 많으며 페이스북와 같이 개인사생활을 다루는 경우 침해 우려도 있어 일간, 주간 배포를 섞어서 사용하고 있습니다. 

 

 

 

[페이스북 코 드커밋 주기]

 

2. Pushing New Features

푸시 프로세스는 혁신 수준을 어느 통제 수준에서 가져갈 것인 균형을 잡아야 합니다. 신규 소프트웨어 배포의 확장은 보다 많은 엔지니어, 보다 많은 코드, 보다 많은 사용자라는 관점에서 고려할 위험들이 많습니다. 위험을 없애는 것은 불가능하기 때문에 감시 기능을 중요한 부문에 보다 집중하게 되고 일간 및 주간 푸시에 따라서도 달라집니다. 주간 푸시는 기본이 되고 수천가지 변경사항을 포함하므로 일요일 오후에 서브버전 중앙 리파지토리에 코드들이 모여 릴리즈 엔지니어가 진행합니다. 수만개의 회귀테스트 (결함과 성능)를 포함하는 자동화 테스트를 거치고나면 최신 빌드의 일부에 포함되고 페이스북 직원들이 먼저 사용하고 이후 푸시는 화요일 오후에 이루어집니다.

릴리즈 엔지니어는 이전 성과에 기반하여 push karma로 엔지니어를 지명하는데 엔지니어가 나쁜 업보(문제를 자주 야기시키는 경향)를 갖고 있으면 푸시에 포함되기 전에 보다 엄격한 감독을 받게 됩니다. 코드 리뷰 과정에서 토론된 내용이나 코드 변화의 규모에 따라서도 얼마나 검토가 이루어질지 고려됩니다.

릴리즈 엔지니어는 작은 주기의 푸시를 하루 2번씩 수행합니다. 주간 혹은 일간 푸시에 포함되는 코드들은 개별 단위테스트와 코드리뷰를 반드시 거져야 합니다. 페이스북에서 코드리뷰는 중심적 위치를 차지하고 있는데, 모든 라인은 다른 엔지니어들에 의해 반드시 검토되어야 합니다.

Phabricator 코드 리뷰 도구 (http://phabricator.org)와 코드 테스트 자동화 도구 (사용자 인터페이스 포함) Watir (http://watir.com/)와 Selenium (https://code.google.com/p/selenium/)을 활용합니다. 아울러 페이스북을 사내에서 활발하게 사용하면서 모든 직원들이 발견하는 모든 버그들을 바로 리포트하고 있고 있습니다.

 

 

[Phabricator 코드 리뷰 도구]

 

[ Watir UI  테스팅 자동화 도구 ]

 

[ Selenium 테스팅 프레임워크: Unit, UI , 통합 테스팅 지원 ]

 

아울러  Perflab와 같은 성능테스팅 솔루션을 활용하여 엔지니어가 단시간에 해결할 수 없는 경우 변경된 코드를 서비스에서 제거하거나 다음번 푸시로 연기시켜 엔지니어가 문제를 해결할 수 있도록 활용합니다. 엔지니어들은 작은 성능 상의 이슈라도 지속적으로 관찰하고 문제가 축적되지 않도록 해결해야 합니다. 이런 이슈들이 방치되면 급격하게 용량과 성능 문제를 야기시키기 때문입니다. 

 

 

[페이스북 주중 커밋 분포]  

 

페이스북 커밋분포를 보면 주중에는 화요일, 일과중에서는 3시때가 가장 높습니다. 점심 시간에도 여전히 많은 커밋이 이루어지고, 저녁 8시 이후로는 거의 커밋이 이루어지지 않습니다. 

 

 

페이스북의 개발과 배포 프랙티스에 대하여 몇가지로 정리해보면 다음과 같습니다. 

• 최종적으로 잘 정의된 제품을 달성하기 위한 구체적 계획은 만들지 않는다. 
• 모든 엔지니어는 브랜치나 머지없이 하나의 공통된 코드기반에서 작업한다. 
• 테스팅을 책임지는 별도의 QA 조직은 없다.
• 매일 하루 2회 신규 코드를 릴리즈한다. 
• 엔지니어가 무엇을 할지 스스로 결정한다. 
• 실패에 대한 잘못을 묻지 않는다. 

• 제품이 미리 정의되지는 않지만 빠른 속도로 반드시 지속적으로 진화하여야 한다. 
• 엔지니어는 도메인에서 직접 경험해야하고 사용자들이 어떤 것을 좋아하는지 파악하기 위해 테스트 과정을 주도합니다. 
• 개인적 책임에 따라 엔지니어는 자신이 개발된 코드의 품질을 책임져야 합니다. 
• 사용자에 대한 테스팅은 범위를 정해 수행하고 가장 정확하고 빠른 피드백을 제공해야 합니다. 
• 누구의 잘못인지 책임을 따지는 것보다 경험을 통해 배우는 것이 가장 중요하고 이롭습니다.