Yocto Rolling master model for production

Platform 및 플랫폼 개발을 하면서 오픈소스 처럼 개발 하기는 정말 어렵다. 여기서 오픈소스 처럼 개발 한다는 의미는 Yocto master branch를 계속 쫓아가면서 production branch (필자의 회사는 dunfell branch)를 유지하는 것이다. 즉 2개의 branch를 운영하고 개발자는 코드를 제출할 때는 master와 dunfell 모두 올려야하고 테스트도 물론 모두 함께 해야한다는 것을 의미한다.

 

필자의 회사에서는 Yocto 로 개발하는 Infotainment 플랫폼 및 제품에서 이를 시도하고 있다. 개발자들은 잘 지켜가고 있지만 현재 리소스 부족으로 테스트는 자동화만 돌리고 일부 매뉴얼 테스트는 대응하기 어렵지만, 필요할 때마다 요청해서 돌리고 있는 상황이다.

 

이 모델의 효용성에 대해서는 필자도 아래와 같이 유지하기 어려운 점들, 오픈소스와 플랫폼 개발/양산 개발 모델을 같이 할 수 있는지 등 때문에 아직 100% 확신을 하지 못하는 상황이라 일단 지켜보고 판단해도 늦지 않을 것 같다.

그러면 왜 master branch를 계속 쫓아가야하는가?

1. Yocto 버전을 올리는 bigbang은 많은 노력이 필요하다.
2. Yocto의 최신 수정 사항, 오픈 소스의 최신 버전을 사용할 수 있다.
3. 플랫폼 및 제품의 지속적인 업그레이드가 가능하다.
4. 컴포넌트는 가능하면 하나의 master branch로 master와 production branch를 대응할 수 있게 하여 사전에 gcc 버전 등에 대응할 수 있다.

이것을 유지하는 것은 왜 어려운가?

1. 개발자가 master branch와 production branch 모두 신경써야한다.
2. 테스트 리소스가 2배가 필요하다. 단 master branch의 경우 테스트를 단순화 시킬 수 있고, 모두 자동화 한다면 부담은 줄어단다.
3. 버그 관리/대응도 부담이 된다. 즉, 모든 면에서 리소스가 더 필요하다.
4. SoC 업체에서 제공하는 BSP layer가 필요하지만, 쉽게 동의해주지 않는다.
5. 4번과 비슷하게 ABI가 호환되지 않는다면 바이너리로 제공되는 서비스들에 대한 대응이 어려울 수 있다.
6. production을 중시하는 management를 설득하기 힘들다.
7. 모든 CI 리소스가 거의 2배로 필요하다. master branch의 각 target device들도 모두 대응해야한다.

Reference

• GENIVI: https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=11571841 
• Yocto Dev Day 2019 Europe: https://wiki.yoctoproject.org/wiki/YP_Summit_Lyon_2019