요즘은 채용에서도 git을 얼마나 잘 활용할 수 있는가의 여부가 매우 큰 가점이 됩니다. 이는
개발자 뿐만 아니라 퍼블리셔, 디자이너까지 그 대상이므로 효과적인 협업의 방법으로 git을 활용할 수 있어야겠지요.
! Git으로 무엇을 할 수 있을까
git을 단순 분업도구,
형상관리(version control)로 생각하기에는 Git의 장점이 너무나 많습니다. Project 관리, 소스 관리, 버전 관리 그리고 효과적인 배포 역시 git을 활용한 방법이 많이 사용됩니다.
# Gitflow를 활용한 효과적인 배포방안
웹어플리케이션을 실제 EndUser에게 제공하려면 Client가 접근 가능한 서버에
배포(Deployment)가 반드시 필요합니다.
아무리 잘 만들어진 앱이라도 배포가 잘 이루어지지 않으면 더 나은 서비스를 제공할 수 없겠죠. 실제로 배포는 모든 과정 중에서도 가장 무섭고 신중을 기해야합니다. 자칫 애써 작업한 모든 과정이 배포가 안되면 쓸모없는 일이 되버리죠...
GitFlow은 기획부터 디자인, 개발등을 거쳐 마지막 단계 배포까지가는 일련의 과정들 ... 그 안에서 효과적인 프로세스를 정립 및 수행합니다. 이런 것들 모두 git안에서 가능한 이유는 git이 제공하는 다양한 기능들 때문입니다. 특히
포크 및 브랜치(Fork & Branch)를 사용할 수 있고
태그(Tag)를 사용하여 배포를 구분, 관리할 수 있기 때문이죠.
# Gitflow의 배포방안
먼저 운영중인 서비스부터 개발, 테스트 및 신규프로젝트등을 수행할때 각각의 구분된 브랜치를 활용합니다. 일반적으로 4, 5개로 구분 및 운영되는데 아래의 4가지는 가장 기본적인 개별 브랜치입니다. 아래서는 각각의 브랜치를 각각의 서버로 구분하여 설명합니다.
- Project
- Hotfix
- Test, QA
- Stage or Push
- Operation
! Project 서버
다음 버전의
고도화작업이나 신규 프로젝트를 진행할 경우 생성하는 Project 브랜치입니다. 이 곳에는 마지막 릴리즈된 버전을 기준으로 신규 프로젝트를 개발하게됩니다.
! Hotfix
Projevt를 진행하더라도 기존의
상용버전을 관리 수정 등의 작업이 필요할 수 있죠. 이런 부분은 모두
Hotfix 브랜치를 사용, 이루어지게됩니다.
! Test, QA
개발이 끝나 검증이 필요하거나 테스트 등이 필요한 경우 이를 수행하기 위한 목적입니다.
! Stage or Push
개발이 완료되어 상용에 올라가기 전.. 즉 배포가 이루어지기 이전에
한번 더 테스트 및 검증을 위한 목적으로 사용됩니다. 데이터베이스가 서버별로 구분된 경우 해당 서버의 데이터베이스를 적용하여 또 다른 검증이 필요로합니다.
! Operation
마지막인 운영서버입니다. 운영서버는 엔드유저의 접점이므로 실제 코드 수정이나 테스트 등의 목적을 배제한
Client에게 앱을 제공하는 최소한의 목적만 가지게됩니다.
참고로 git은 git-flow라는 작은 plugin을 제공합니다. 이를 사용하면 몇 가지 과정들을 한 번에 처리할 수 있도록 도와줍니다. 아래 명령어는 일부 git-flow를 사용한 것들 입니다.
$ git flow feature start feature_001
// feature 브랜치 생성
$ git flow feature finish feature_001
// develop 브랜치로 변경
// develop에 feature 브랜치 머지 후 삭제
배포관련
git flow release start 0.0.1
// release 브랜치 생성, 이름 release/0.0.1
git flow release finish 0.0.1
// 머지, 태그, 삭제의 과정들
그 외 hotfix 등의 명령어도 있습니다.
# 마치면서
여기까지 GitFlow에 대하여 간단하게 알아보았습니다.
Docker를 사용한 배포 방법 역시 많이 활용되지만 단독 사용되기보다 Git과 함께 사용되는 경우가 많은 것도 Git이 기능면에서... 그리고 사용면에서도 쉽고 편리하기 때문이겠죠.