이제 내일부터 팀프로젝트 작업을 시작하게 된다.
일단 내일 할 작업은 도메인 모델 설계 및 프로젝트 셋팅작업이다. 팀원 모두 시간이 많지는 않아서 하루 4시간 정도를 작업시간으로 정하고 작업할 에정이다.
그런데 문득 생각해보니 개인프로젝트를 할때와 다르게 팀프로젝트 때는 빌드 및 테스트 관리를 어떻게 해야할까 감이 잡히지 않았다. 그래서 찾아본 결과 ci, cd라는 개념에 대해 알게 되었다.
매번 개발자가 코드를 수정하고 빌드와 테스트를 하고 배포까지 한다면 상당히 많은 시간이 소요된다. 하지만 ci, cd를 이용하면 git에 코드를 올리는 것만으로도 빌드와 테스트, 배포까지 해주기 때문에, 쓸데없는 시간을 단축시키고 개발에 더 많은 시간을 투자할 수 있다.
CI는 간단히 요약하자면 빌드/테스트 자동화 과정이다. 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.
지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 하다.
CI의 간단한 순서는 아래와 같다.
CD는 간단히 말하면 배포 자동화 과정이다. CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.
지속적 배포는 또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 한다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 된다.
이상으로 CI/CD에 대해 알아봤다. 내일은 CI/CD를 어떻게 적용해야할지 알아보자