소프트웨어 개발과 테스트 -소스코드 관리/빌드

소프트웨어 개발과 테스트 국내도서 저자 : 조대협 출판 : 프리렉 2015.01.15 상세보기

◎ 소스 코드 관리 : 소프트웨어 개발에서 소스 코드의 관리는 중요한 포인트 중의 하나이다. 다양한 버전과 변경 관리, 협업을 위해서는 소스 코드를 저장 및 관리할 수 있는 시스템이 필요하고 이를 VCS 또는 SCM 시스템 이라고 한다. 

◎ 브랜치 : 먼저 소스 코드 관리에 대한 개념 이해를 위해서는 브랜치의 개념 이해가 필요하다. 소프트웨어 개발을 할 때, 하나의 저장소에 소스 코드를 저장해서 개발하고, 개발자 간의 공유를 해서 협업을 진행한다. 개발을 진행하다가 특정 목적에 의해서 별도의 작업에 의해 새롭게 만들어진 소스 코드의 복사본을 브랜치라고 하고 원래 소프트웨어를 개발하던 소스 코드 저장소를 메인 브랜치라고 한다. 

◎ 태깅 : 태깅이란, 코드를 개발 중에 특정 시점의 이미지에 표시해놓는 것을 의미한다. 예를 들어, 매일 소스 코드에 대한 태그를 달아놓으면 개발 중에 문제가 생겼을 경우에 특정 날짜의 소스 코드로 다시 돌아갈 수가 없다. 

◎ 중앙집중형 저장소 : 중앙집중형 저장소는 코드가 저장 서버 단 한군데만 저장된다. 개발자가 코드를 받아서 수정하고 저장하면, 그 내용이 바로 중앙 저장소에 반영된다. 즉 서버에는 항상 마스터 버전의 소스 코드가 저장되어 있다. 그리고 서버가 다운 되거나 네트워크에 접속할 수 없다면 당연히 코드를 커밋하거나 최신 코드를 내려받을 수 없다. 

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

◎ 스테이징 : 또 다른 재미있는 기능 중의 하나는 스테이징 개념을 지원한다는 것이다. 즉 개발자가 컴포넌트나 라이브러리를 개발하여 넥서스에 배포하면 다른 개발자나 사용자들이 바로 그 라이브러리를 사용하는 것이 아니라, 일종의 워크플로를 통해서 릴리즈 절차가 끝나면 일반 개발자들이 사용할 수 있도록 프로세스를 조정할 수 있다.

◎ 소프트웨어가 개발의 결과이고, 개발 방법론이 그 결과물을 만들기 위한 공정(프로세스)이라면, 소프트웨어 개발 환경은 소프트웨어를 만들기 위한 환경이자 도구이다. 프로세스를 준수하고 소프트웨어 자체를 만들어 내는 것도 중요하지만, 공장에서 물건을 만들어내는 기계들이 중요하듯이 소프트웨어 개발도구도, 개발 공정과 개발하고자 하는 소프트웨어에 따라서 최적화된 도구를 잘 선택하고 배치하는 것이 중요하다. 

◎ 소프트웨어 개발에서 소스 코드의 관리는 중요한 포인트 중의 하나이다. 다양한 버전과 변경 관리, 협업을 위해서는 소스 코드를 저장 및 관리할 수 있는 시스템이 필요하고, 이를 VCS 또는 SCM 시스템이라고 한다. 소스 코드 관리 시스템의 주요 기능은 다음과 같다. 

- 협업을 위한 코드 공유

- 접근 제한

- 다양한 버전(형상)관리

- 특정 시점 추적

- 변경 추적

◎ 먼저 소스 코드 관리에 대한 개념 이해를 위해서는 브랜치의 개념 이해가 필요하다. 소프트웨어 개발을 할 때 하나의 저장소에 소스 코드를 저장해서 개발하고, 개발자 간의 공유를 해서 협업을 진행한다. 개발을 진행하다가 특정 목적에 의해서 별도의 작업에 의해, 예를 들어 영문으로 된 버전을 중국어나 한국어로 제공하려면 기존 개발 소스 코드의 복사본을 만들어서 중국어 개발용으로 하나 사용하고, 한국어 개발용으로 하나 사용한다. 이렇게 새롭게 만들어진 소스 코드의 복사본을 브랜치라고 하고 원해 소프트웨어를 개발하던 소스 코드 저장소를 메인 브랜치라고 한다. 

◎ 중앙집중형 저장소는 코드가 저장 서버 단 한군데만 저장된다. 개발자가 코드를 받아서 수정하고 저장하면 그 내용이 바로 중앙 저장소에 반영된다. 즉 서버에는 항상 마스터 버전의 소스 코드가 저장되어 있다. 그리고 서버가 다운 되거나, 네트워크에 접속할 수 없다면 당연히 코드를 커밋하거나 최신 코드를 내려받을 수 없다.

◎ 분산형 저장소는 말그대로 소스 코드가 하나의 중앙 서버가 아니라 여러 개의 서버나 여러 개의 개발자 PC에 저장될 수 있으며, 각각이 소스 코드 저장소가 된다. 각 저장소에 저장되는 소스 코드는 같은 버전의 코드가 아니라 제각기 다른 브랜차 코드가 저장된다. 즉 서버 A에는 브랜치 A, B, C버전이 서버 B에는 브랜치 A, C, D 버전과 같이 다른 브랜치 버전을 저장할 수 있다. 즉각 저장소에 브랜치 버전이 모두 틀리고 소스 코드에 접근해서 가지고 오는 장소도 모두 다르기 때문에 시스템 자체에서는 마스터 버전의 개념이 없다. 

◎ 일반적인 서버 개발 환경은 다음과 같이 로컬 개발, 서버 개발, 통합 개발, 테스팅, 스테이징, 운영 환경 등으로 나누어진다. 각자의 개발 과정에 따라 각자의 역할과 목적이 다르고 따라서 시스템의 크기도 다르다. 꼭 모든 환경을 갖출 필요가 없으며 프로젝트 환경에 따라서 각 환경을 합치거나 생략해도 된다.

각 환경을 운영할 때 또 다른 고려 사항은 개발자, 테스터, 운영자 등 각각 역할에 대해서 어디까지 접근 환경을 제공할 것인가이다. 일반적으로 개발 환경과 통합 개발 환경은 개발자들이 접근 권한을 가지고, 테스팅 환경, 스테이징 환경은 QA 엔지니어까지 접근권한을 가질 수 있다. 

그러나 제품 운영 환경의 경우 운영팀만 접근 권한을 가지도록 하여 사용자의 데이터나 중요 정보가 유출되거나 환경 설정이 원하지 않게 깨지는 것을 방지할 필요가 있다. 성능이나 장애 추적 등을 위해서 제품 운영 환경 접근이 필요한 경우 한시적으로 운영팀으로부터 권한을 받아서 접근을 허가하도록 하는 것이 좋다.

◎ 자동 빌드(CI)는 6년 전부터 유행하기 시작한 개념이다. 개발의 주요 단계가 끝나면 소스 코드를 모아서 주기적으로 빌드했던 것과 달리 CI의 개념은 매일 또는 매번 커밋할 때 마다 변경된 코드를 받아서 매번 빌드하고 테스트 하는 개념이다. 

◎ CI의 특징

- 소스 코드 일관성 유지

- 자동 빌드

- 커밋에 따른 자동 빌드

- 시간 간격에 의한 빌드

- Silent Period

◎ 서비스에 대한 배포 시 테스트를 아무리 잘했다 하더라도 에러가 발생할 수 있다. 에러가 발생하였을 때는 이전의 버전으로 신속하게 롤백할 수가 있어야 하는데 이렇게 하려면 애플리케이션의 이전 버전을 반드시 저장하고 있어야 하고, 배포 스크립트 역시 예전 버전을 다시 배포할 수 있는 기능을 구현해야 한다. 

◎ 릴리즈 노트는 배포되는 대상(독자)에 따라서 다르게 작성돼야 하는데, 내부 릴리즈 노트는 다음과 같은 내용이 포함되는 것을 권고한다. 

- 릴리즈 버전, 날짜 및 빌드 넘버

- 새로운 기능 및 설명

- 버그 넘버 및 버그 수정 내용