CI/CD 란?

CI - Continuous Integration, 지속적인 통합

💡 CI 라는 개념이 와닿지 않아서, 
리팩토링의 저자 마틴 파울러의 블로그를 번역하며 공부해보았다. 
아래 글은 출처를 밝힌 사이트의 번역 글이다.

지속적인 통합은 조직의 구성원들이 빈번하게 - 평균적으로 최소 하루에 한 번 -자신의 작업을 통합하여 하루에 여러 번 통합이 일어나게끔 하는 소프트웨어 개발 루틴이다. 각 통합은 최대한 빠르게 통합 시의 에러들을 파악하기 위해 빌드 자동화 (테스트를 포함하는) 를 활용한다. 많은 조직들은 이 접근방법이 통합 과정에서의 문제를 현저하게 감소시키고 더 빠르게 일관된 소프트웨어를 개발할 수 있게 한다는 것을 발견했다.

CI 활용의 이점

• CI 를 활용한 소프트웨어의 개발 과정은 다음과 같다:

통합되어 있는 현재의 소스 코드의 복사본을 나의 컴퓨터에 저장하는 것으로 일을 시작한다. 즉, 소스 코드 관리 시스템 (Git 과 같은) 을 사용해서 현재 시점에서 동작 중인 코드의 복사본을 가져온다. 이제 이 복사본을 가지고 나에게 배정된 업무를 한다. 코드의 변경 뿐만 아니라 테스트의 추가 또는 변경도 일어날 것이다. CI 는 소프트웨어 내에 자동화 되어 있는 테스트가 많다는 것을 가정한다. 업무 중간 또는 마친 후에는 개발하고 있는 컴퓨터에서 자동화된 빌드를 실행한다. 빌드 과정에는 내 컴퓨터 내의 복사본을 가져가서, 컴파일 후 실행 가능한 파일로 만든 후 자동화된 테스트를 실행하는 일들이 포함된다. 모든 테스트들을 포함한 과정을 에러가 없이 마치면 빌드가 성공한 것이다.

이제 성공적인 빌드를 했으니, 리포지토리에 내가 한 업무를 커밋할 수 있다. 물론, 다른 사람이 내가 최초 복사본에 변경을 하여 커밋하기 전에 이미 같은 복사본에 다른변경을 한 후 커밋을 했을 수 있다. 그랬다면 먼저 나는 다른 사람의 변경 내용을 적용한 뒤에 다시 빌드를 한다. 내 변경과 충돌이 일어나면, 컴파일 과정이나 테스트에서 확인될 것이다. 이 충돌을 해결해서 메인 브랜치의 작업과 동기화된 소프트웨어를 빌드할 때까지 반복하는 것은 나의 몫이다.

결국 빌드를 성공한다면, 이제 진짜 커밋 및 푸시 또는 PR을 할 수 있다. 하지만 이로서 모든 일이 끝난 것은 아니다. 이 시점에서 우리는 다시 빌드를 하는데, 이번에는 내 컴퓨터가 아니라 통합 개발을 위한 컴퓨터에서 업데이트된 프로젝트의 빌드를 진행한다. 이 빌드까지 성공해야, 업무를 마친 것이다. 코드를 변경한 후 컴퓨터에서 커밋하여 리포지토리를 업데이트 할 때 혹시라도 무언가를 놓친 것이 있을 수 있기 때문이다. 이 통합 개발 컴퓨터에서의 빌드는 내가 직접 할 수도 있고, Cruise (CruiseControl, CI 도구이다) 에 의해 자동화될 수도 있다.

만약 두 개발자들 사이에 충돌이 일어난다면, 더 나중에 커밋한 개발자가 빌드하면서 발견하는 경우가 많다. 만약 이 시점에서 발견이 안되더라도 통합 컴퓨터에서 발견될 것이다. 어쨌든 에러는 빠르게 발견된다. 이 시점에서 가장 중요한 업무는 에러를 고치는 것이다. CI, 지속적인 통합 의 환경에서는 절대로 실패한 통합 빌드를 오래 놔둬선 안된다. 좋은 조직에서는 하루에 올바른 빌드가 많이 일어나야 한다.

이 과정의 결과는 적은 오류들을 가지고 잘 작동하는 안정적인 소프트웨어이다. 모든 개발자들은 안정적인 기반 코드 (메인 브랜치의 변경 전 코드) 위에서 작업하고, 이 코드에서 변경 시 통합 빌드가 어려울 정도로 멀리 벗어나는 변경을 하지 않는다. 에러는 잦은 빌드로 인해 빠르게 나타나기 때문에 빠르게 발견된다.

✍🏼 위 글에 의하면, CI 는 어려운 개념이 아니라 
지속적으로 리포지토리를 업데이트 하면서 함께 일하는 동료 개발자들의 코드와의 충돌을 피해 빌드하고, 
통합하는 일련의 개발 루틴 전체를 말하는 것이다. 
또한 장점을 살리기 위해서 자동화된 테스트의 존재 여부가 중요하다.

CD - Continuous Delivery / Deployment, 지속적인 제공, 배포

Continuous Delivery, 지속적인 제공

지속적인 제공은 지속적인 통합의 연장선이다. 빌드가 완료된 후에 모든 코드의 변경사항을 테스트 + 릴리즈 가능 환경, 즉 코드가 실제로 서버에 배포되기 직전까지의 과정을 자동화한다. 즉 CI 는 모든 단계에서 사람이 개입되지만, 지속적인 제공에서는 테스트 후 릴리즈할 수 있는 소프트웨어의 상태까지 만드는 과정이 자동화 된다.

이는 언제든지 버튼 클릭이라는 개입 한 번으로 어플리케이션을 배포할 수 있음을 의미한다.

그래서 이론상으로는, 비즈니스 요구사항에 맞게 아무 때나 배포를 할 수 있다. 하지만 동작하는 프로덕션 소프트웨어까지의 배포는 최대한 빨리 진행해야 한다. 그래야 문제 시에 쉽게 디버깅이 가능한 작은 크기의 배치를 릴리즈하게 되기 때문이다.

Continuous Deployment, 지속적인 배포

지속적인 배포는 지속적인 제공보다도 한 걸음 더 나아간다. 생산 파이프라인의 모든 단계를 거친 변경사항들 모두는 자동적으로 고객들에게 릴리즈된다. 릴리즈마저 자동화된 것이다. 사람이 개입하는 곳은 없다. 테스트가 실패했을 때에만 새로운 변경사항이 릴리즈되는 것을 막는다.

지속적인 배포는 고객들과의 상호작용을 가속화한다. (그도 그럴 것이, 테스트만 통과하면 바로 고객들 눈 앞까지 배포되니까) 그리고 동시에 ‘배포 날’ 과 같은 개발자들을 압박하는 무언가가 사라진다. 개발자들은 소프트웨어 개발에 집중할 수 있고, 업무를 마칠 때마다 서버에 배포되어서 고객들에게 전달된 것을 볼 수 있다.

Jenkins vs GitLab

Jenkins

1. 스크립트를 짜서 관리하기에 좋다. (구조화가 잘 되어있고, 이해하기 쉽고, 가독성이 좋다.)
2. JAVA로 개발되었기 때문에 JRE가 설치된 환경에서 구동해야 하고, MIT 라이센스를 따른다.
3. 약 1,000여개의 플러그인이 있다.
4. Credntials Command와 같은 플러그인도 사용할 수 있어서 이를 활용하여 숨겨진 인증 자격 증명 등을 스크립트에 쉽게 추가할 수 있다.
5. 쉽게 설치하고, 자동화된 빌드 프로세스를 제공하며 구글에 매우 많은 Document가 있다.
6. REST API를 제공한다.
7. 병렬 처리를 지원한다.
8. GUI 관련된 작업을 진행할 때 분산 처리가 가능하다.
9. Sonarqube 등의 플러그인을 통해 코드 품질을 살펴볼 수 있는 기능을 제공한다.

GitLab

1. 젠킨스보다 최근의 도구이다.
2. 25,000명 이상의 사용자를 관리할 수 있다.
3. Ruby와 GO로 개발되어 있고, MIT 라이센스를 따른다.
4. Repository를 제공한다.
5. 설치와 설정이 쉽다.
6. 통계 웹사이트를 생성해주는 Jekyll 플러그인을 지원한다.
7. Milestone을 설정할 수 있다.
8. Auto-Scaling CI Runner를 제공한다. 이는 EC2에서 90%의 비용 절감 효과를 가져다 주기 때문에 되도록 사용하면 좋다.
9. 이슈 트래킹과 이슈 셔플링을 제공한다.
10. Git repository에 대한 Access Control 기능을 지원한다.
11. 커뮤니티가 활발하다.
12. REST API, GraphQL API를 지원한다.
13. 코드 품질을 살펴볼 수 있는 기능을 제공한다.

결론

Jenkins 같은 경우는 세팅이 매우 매우 오래 걸리는 반면, GitLab은 SaaS(Software as a Service: 서비스형 소프트웨어) 형태로 제공해 준다. ⇒ 그냥 사용하면 됨

GitLab을 처음 사용하면 어렵다고 느낄 수 있지만 Jenkins에 비하면 쉬운 편이다.

GitLab의 장점: 설치와 세팅이 필요 없다. 유료 버전이 있는데 가격이 합리적인 편(한 달에 1,000분 무료, 예를 들어 하나를 빌드하는 데 4분이 걸린다고 치면 250번 빌드 할 수 있는 시간)