이번엔 docker를 이용한 Gitlab-CI 구축 방법에 대해 포스팅하려고 한다.
1. 왜 Gitlab 인가?
본 포스팅에 들어가기 앞서 아래 이미지에서 보듯이 최근 5년간의 트렌드를 보면 github가 압도적이다. 그런데 왜 git 저장소를 github가 아닌 gitlab으로 선택했는가?
git 저장소로서의 점유율은 github에 밀려 만년 2위 자리를 지키고 있지만 gitlab이 가지는 장점이 분명히 있다. github에서는 private repository는 유료이나, gitlab에서는 무료로 사용 가능하다. 따라서 github에서는 무료로 사용하기 위해서 모든 소스를 오픈해야하고 그에 따른 장점은 많은 사람들이 공유할 수 있게되므로 자연스레 시장 점유율도 올라갔던게 아닐까하고 생각해본다.
필자가 gitlab을 사용하려는 또 하나의 이유는 github에 비해 repository의 저장 공간을 많이 허용해준다는 점이다. (github는 프로젝트당 1gb / gitlab은 프로젝트당 10gb)
특히 오늘 포스팅하려는 CI 관련해서도 장점이 있는데 github에서는 자체적으로 지원하는 CI가 없기 때문에 젠킨스나 codeship과 같은 외부 CI 서비스를 사용해야 한다는 점에 반해 gitlab은 자체적으로 CI를 지원하고 있다.
2. 왜 CI인가?
그럼 CI가 무엇인지부터 알아보자.
CI란, Continous Integration의 약어로 지속적인 통합이라는 뜻을 가지고 있다.
고전적인 개발 방법으로는 작은 작업 단위를 쌓고 쌓아서 큰 작업 단위를 만들고, 큰 작업 단위를 기점으로 배포 파일을 만들어서 서비스에 적용시켰었다.
이러한 작업 절차의 가장 큰 문제는 기능별 패치가 아닌 여러 개발자들이 개발한 각 기능을 통합하여 한번에 패치하기 때문에 문제가 발생한다면 어디서 문제가 발생했는지 파악하는데 시간이 많이 걸릴 뿐아니라, 패치 작업을 일일히 수작업으로 진행해야하는 단순 작업의 반복으로 인한 효율적으로 일을 할 수가 없다. 통합의 지옥에 빠지게 되는 것이다.
이러한 고전적인 개발 방법의 문제점을 해결하고자 나온 것이 CI의 개념이다.
지속적인 통합, 즉 작은 작업 단위 별로 Commit을 실행하고 Commit된 파일을 빌드부터 테스트, 서비스 서버에 배포하기까지의 일련의 작업들을 자동화 해주는 것이다.
CI를 제대로 적용하고 사용하기만 한다면 개발에 있어서 불필요한 작업들을 정말 많이 없애줄 것이다.
'Git' 카테고리의 다른 글
| # docker 기반 Gitlab-CI 구축 4 - Backup & Restore (0) | 2020.03.30 |
|---|---|
| # docker 기반 Gitlab-CI 구축 3 - Gitlab-runner 실행 (0) | 2020.03.27 |
| # docker 기반 Gitlab-CI 구축 2 - Gitlab 실행 (0) | 2020.03.27 |