Tizen Development Working Mechanism
소스코드 관리 시스템(SCM)은 아래 두가지로 구성 된다:
Git. Git은 버전 관리 시스템으로 특히 공동개발을 효과적이고 견고하게 만드는데 강하고, 유연하며, 부하가 적다. 더 자세한 정보는 다음 리소스를 참조 하세요:
Gerrit. Git 버전 컨트롤 시스템을 사용하여 프로젝트의 online코드 리뷰를 가능하게 하는 웹 기반 코드 리뷰 시스템. side-by-side display와 inline 주석을 통해 Gerrit은 코드리뷰 프로세스를 최적화 하고 리뷰 퀄리티를 향상 시킨다 . 뿐만 아니라 중앙 Git 저장소에 변경사항을 제출하는 권한이 부여된 사용자만을 허용하는 것을 통해 Git 기반 프로젝트 유지보수를 단순화 하고, Git의 중앙집중식 사용을 가능하게 한다.
open build Service(OBS)는 완벽한 공개 분산 개발 플랫폼으로, 서로 다른 하드웨어 아키텍처 상의 다양한 리눅스 배포판을 위하여 오픈소스 소프트웨어를 쉽게 만들고 배포하기위한 인프라를 제공한다. 또한 OBS는 협업환경을 제공하는데, 개발자 그룹이 다른프로젝트로 변경사항을 submit하고 build하는 것을 가능하게 한다.
더 자세한 정보는 다음 리소스를 참조 하십시오:
Git 저장소에 주어진 프로젝트는 두가지 branch를 가지고 있다 : master branch와 upstream branch
참고: master branch는 필수이고, upstream branch는 선택사항이다. 더 자세한 이유는 아래 항목을 참조 하세요.
Master Branch (필수)
Git은 저장소 초기화 시 master branch(development branch로 알려진)를 도입한다. 따라서 저장소에 있는 기본 branch는 master branch이고 대부분의 개발자는 저장소의 가장 견고하고 신뢰할수 있는 개발라인을 master branch에 유지 한다.
즉, master branch는 각 프로젝트의 full source tree의 host이고(C/C++, .h, makefile 등과 같은), upstream source와 Tizen local 변경사항을 포함 한다. master branch를 삭제하거나 이름을 바꿀 수 있지만, 그대로 두는 것을 권장한다.
참고: 개발자들은 각 Git tree의 "/packaging"폴더 내의 changelog를 유지하는데 책임이 있다.
- Upstream Branch (선택)
다른 한 쪽에서 복사한 두개의 저장소를 이야기 할 때, 부모 저장소를 보통 upstream이라고 한다.
기존 개념도 upstream에 적용 되는데, 더 구체적으로 부모 branch는 개발자들의 Git 프로젝트의 base를 말한다. upstream branch는 다음과 같은 시나리오에서 선택 사항이다 :
- Tizen의 순수한 native code만을 포함하고 base로 하는 upstream branch가 없는 프로젝트
- upstream 프로젝트의 최신 업데이트를 추적 할 필요가 없는 프로젝트
source 저장소에서 OBS로 code를 submit 하기 위해, 백엔드는 필요한 형식으로 패키지 파일을 생성하며, 다음 그림과 같다.
패키지 개발 작업 흐름은 다음과 같은 절차로 설명되고 아래 그림과 같다:
개발자들은 개발환경을 설정하고 개발도구를 설치한다.
개발자들은 소스코드를 복제하고, 필요한 개발을 실시하며, local build를 통해 local 검증을 실시한다.
개발자들은 모든 책임자들이 검토 하도록 Gerrit에 patch를 제출한다.
타이젠 백엔드 서비스와 리뷰어들은 자동 및 수동 테스트로 검증 한 뒤 패치의 퀄리티를 기반으로 -1, 0 또는 +1을 투표한다.
- Automated testing: Tizen back-end service는 원격 빌드를 실행하기 위해 자동으로 OBS에 patch를 submit하고 테스트 결과를 Gerrit에 post한다. .
- Manual testing: 테스터들은 직접 patch를 확인 한 뒤 Gerrit에 의견을 post한다.
maintainer들은 검증을 통과한 patch(Code-Review +2)를 승인 한 뒤 Gerrit 저장소에 code 변경사항을 merge 한다.
Maintainers/Developers는 gbs submit command를 사용하여 OBS에 패키지를 제출한다.
참고: 타이젠 프로젝트의 maintainer 역할을 하는 것은 아주 좋은 방안이고, maintainer들은 누락 가능성을 방지 하기 위해 모든 merge된 패키지가 제출 준비되자 마자 OBS로 패키지를 submit 해야 한다.
Tizen back-end service pre-release 와 normal release processes 동시에 활성화 한다. pre-release process 동안, 특정 패키지 통합 Tizen image는 release 엔지니어에게 검토를 위해 생성되고 제출된다.
Release 엔지니어는 패키지 퀄리티를 기반으로 submission을 허가 하거나 거부한다. submissions이 허가된 경우, 해당 소스코드는 OBS저장소에 merge 될 것이고, 그동안, the normal release process는 tizen image와 함께 repos를 발행하고 대체 한다
Developers'책임 :
- Git 프로젝트의 development branch에 code를 작성하고 submit한다.
- branch상의 프로젝트들을 위한 code 변경사항을 검증 및 검토 (vote "+1" or "-1") 해야 함.
Maintainers의 책임 :
- upstream, 프로젝트 프로파일용 development branch와 같은 추가 branch를 만듬
- upstream branch에 master branch를 rebase 한다.
- code를 검토 할 뿐만 아니라 patch를 승인(vote "+2") 하거나 거부(vote "-2") 한다.
maintainer를 위한 guidelines :
- 부여된 권한에도 불구하고, maintainer는 그들 자신의 변경사항을 peer 리뷰 ("+1") or ("+2")통과 없이 승인 하지 않아야 한다.
- code rebase를 다루기 위해 push권한이 maintainer를 위해 보장 된다. maintainer는 검토해야 할 패치 제출을 숨길 수 있는 권한을 남용해선 안된다..
Reviewers의 책임 :
- code를 검토할 뿐만 아니라 patch를 승인(vote "+2")하거나 or 거부 (vote "-2")한다.
Release Engineers' 책임 :
- OBS에 제출 승인.
- 결과 이미지의 smoke test를 수행한 후 추가 테스트를 수행하기 위해 QA엔지니어의 release영역으로 전달.
QA 책임:
- 역행이나 버그를 제거하기 위해 철저한 통합 및 image의 검증을 수행한다.
'Tizen > 개발자 가이드' 카테고리의 다른 글
| Typographic Conventions(문서 작성 규칙) (0) | 2014.08.19 |
|---|---|
| Getting Started Guide (0) | 2014.08.19 |