'빌드란 실행 환경에 맞춰서 소스 코드를 실행 가능한 형태의 바이너리로 변경하고 패키징하는 일련의 과정을 말한다.'

• c/c++ : make 기반
• java : 아파치 앤트(ant) 혹은 메이븐(Maven)
• 기타 오픈소스 프로젝트 중심으로 gradle 사용

https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016/

◎ 유연성 관리

Ant : 자유도가 높음, 파일 복사, Shell 명령 실행 가능함, 스크립트 내에서 빌드, 패키징은 물론이고 배포, 테스트, 미들웨어에 대한 기동 저지까지 모든것이 가능 하나 반대로 표준화가 어렵다.

Maven : Ant의 단점을 보완, 템플릿 기반의 빌드 스크립트를 구성, 표준화된 환경에서 빌드 가능, 반대로 템플릿 이외의 기능에 대해서는 유연성이 떨어진다. (예를들어 파일을 특정 클라우드에 복사), 플러그인을 통해서 템플릿 기능을 확장 가능

◎ 의존성 관리

Ant : 소스 코드와 라이브러리 그리고 기타 의존된 리소스 파일등이 디렉토리에 있는 것을 가정하고 빌드 진행

Maven : 컴파일 하는데 필요한 라이브러리에 대한 의존성을 정의하고, 정확한 버전을 정의하면, 컴파일 타임에 원격에 있는 저장소로부터 명시된 버전의 라이브러리를 내려받아서 컴파일과 패키징을 진행하기 때문에 라이브러리의 버전 불일치가 발생할 염려가 없다.

VCS (Version Control System)

SCM (Source Code Management)

git flow(오픈소스) : 위 구조대로 Git의 저장소를 정의하고, 쉽게 사용할 수 있도록 하는 도구 (https://github.com/nvie/gitflow)

• 메인 브랜치(Master)에서는 개발을 진행하지 않고, 별도의 개발 브랜치(Develop Branch)를 만들어서 개발을 진행하다가, 기능별로 기능 브랜치(Feature Branch)를 별도로 만들어 개발을 진행하고 기능 기발이 완료되면, 개발 브랜치로 병합
• 마스터 브랜치와 개발 브랜치의 관계에 코드 리뷰(Code Review) 개념이 있는데, 개발자가 코드 수정을 하였을 경우, 젠킨스 등의 빌드 시스템에 통합돼서 빌드되고 테스트 되어야 동작 여부를 확인할 수 있기 때문에, 어딘가 코드를 공유할 수 있는 장소가 필요하다. 즉 개발이 완료된 부분은 먼저 개발 브랜치에 저장돼서 컴파일 및 테스트를 끝내고 코드 리뷰를 위해서 다른 개발자와 리뷰를 하고 승인이 되면 그때 마스터 브랜치로 반영이 되는 것이다.
• 릴리즈 시기가 되면 별도로 릴리즈 브랜치(Release Branch)를 만든 후에 릴리즈에 필요한 각종 설정 파일 정리, 기타 매뉴얼이나 문서 등을 합쳐서 릴리즈하고, 릴리즈가 된 버전은 메인 브랜치에 반영한 후 태깅을 한다.
• 만약 베인 브랜치를 통해서 공개된 버전이 문제가 있을 경우에는 별도로 버그 수정용 브랜치(Hot Fix Branch)를 만들어서 버그를 수정하고, 테스트를 끝낸 후에 버그 수정 내용을 메인 브랜치에 반영하고 또한 함께 개발 브랜치에도 반영한다.

TestLink : 오픈소스 도구 (http://testlink.org/)

1. Test Project : 테스트 팀 단윈로 분할 (클라이언트 테스트 팀, 웹 테스트팀, 한국 테스트팀등)
2. Test Specification : Test Case(소분류) + Test Suite(대분류), TestCase 버전 분류 가능, 저네 테스트 케이스 집합
3. Test Plan : Test Suite/Test Case를 모아 놓은 것
4. Test Execution : 실제로 테스트 엔지니어가 자기에게 할당된 테스트를 수행하고, 결과 여부를 체크
5. Test Report : 테스트 실패, 성공 여부, 주요 테스트 분류별 성공 실패 여부 등 

• BugZilla, Mantis, JIRA 와 같은 버그 트랙킹 도구와 연동이 가능하다. ('Issue Track Integration')