빠르게 진화 하고 변화 하는 현대 시대에 어떻게 하면 시장과 고객의 요구에 빠르게 반응해서, 제품을 출시하고 업데이트 할 것인가?
이러한 고민에서 나온 해결법이 CI/CD를 개발 프로세스로 사용하는 것이다.
CI/CD란 어플리케이션 개발 단계부터 배포 까지 모든 단계들을 자동화를 통해서 효율적이고 빠르게, 사용자에게 빈번하게 배포할 수 있도록 만드는 것을 말한다.
CI/CD에 대해 들어가기 전에 개발 환경의 종류에는 무엇이 있는지 알아보자!
📌 개발 환경의 종류에는 무엇이 있을까?
-
Local 환경 : 개발자가 개발을 하는 환경
-
Development 환경 : 개발자들끼리 개발 내용에 대한 통합 테스트를 하는 환경
-
QA(Quality Assurance) 환경 : 개발이 끝나고 QA 엔지니어 및 내부 사용자들이 사용해 보기 위한 QA 환경
-
Production 환경 : 실제 유저가 사용하는 환경
- 여러 배포 환경의 관리는 어떻게?
여러 배포 환경의 관리에서 핵심은 인프라를 모듈화 하여 어떤 것이 변수인지 잘 설정하고 이를 잘 설계하는 것이다.
예를 들어, REACT_APP_ENV와 같은 환경 변수처럼 현재 배포하고자 하는 것이 무슨 환경인지 설정하고 앱 내에서 사용하는 다양한 변수들을 잘 가져다 쓰는 것이 핵심이다.
서비스 내부의 변수 뿐만 아니라 클라우드 리소스를 활용하여 개발하는 요즘에는 클라우드 리소스 내에서 인프라별 키관리가 매우 중요해서
AWS system manager의 parameter store와 같은 키 관리 서비스를 쓰는 것을 추천한다고 한다.
📌 CI (Continuous Integration)
지속적인 통합을 의미한다.
지속적 통합은 프로세스 역학과 자동화를 기반으로 하는 개발 철학이다.
다시 말해, 버그 수정이나, 새로 만드는 기능들이 Main Repository에 주기적으로 Build되고 Test되고 Merge되는 것을 말한다.
(이러한 방식은 1991년 Grady Booch에 의해 처음으로 사용되어 지다가, 나중에는 EP(Extreme Programming)에 채택되어 사용되었다고 한다.)
- CI 동작 프로세스의 2가지 Point
1. 개발자는 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.
최대한 작은 단위로 나눠서 개발하고 통합하는 것이 필요하다.
그 이유는 장기간에 걸쳐 개발된 큰 코드보다 작은 규모로 작게 변화된 코드에서 결함과 기타 소프트웨어 품질 문제를 파악하기가 더 쉽다는 데 있다.
2. 통합을 위한 단계 (Build, Test, Merge)의 자동화
- CI의 장점은?
-
개발 생산성 향상 : Conflict를 최소화 할 수 있음
-
문제점을 빠르게 발견 : 모든 코드들은 자동화되기 때문에 코드의 결함이나 문제점을 빠르게 발견
-
버그 수정 용이 : 문제점을 빠르게 발견 할 수 있으므로 버그 수정에 용이하다.
-
코드의 퀄리티 향상
📌 CD (Continuous Delivery)
혹은 CD(Continuous Deployment, 지속적인 배포)로 사용하는 경우도 있지만, Delivery와 Deployment 차이는 자동화의 유무에 따른다.
- Continuous Delivery Vs. Continuous Deployment
Continuous Delivery is the automation of steps to safely get changes into production. Where Continuous Deployment focuses on the actual deployment, Continuous Delivery focuses on the release and release strategy.
지속적 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻한다.
최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.지속적 배포란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.
즉, 짧은 주기로 소프트웨어를 개발하는 소프트웨어 공학적 접근의 하나로, 소프트웨어가 언제든지 신뢰 가능한 수준으로 출시될 수 있도록 보증하기 위한 것이다. 소프트웨어를 더 빠르게, 더 주기적으로 빌드하고 테스트하고 출시하는 것을 목표로 한다.
📌 CI/CD의 Pipeline
-
개발자가 자신의 PC에서 개발을 진행한다. (Local)
-
다른 개발자가 작성한 코드와 차이가 발생하지 않는지 내부 테스트를 진행한다.
-
진행한 내용을 다른 개발자들과 공유하기 위해 git과 같은 SCM에 올린다.
💡 SCM(Software Configuration Management)
소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것
형상 관리와 버전 관리에 대한 참고 자료
-
Dev브랜치의 내용을 개발 환경에 배포하기 전에 테스트와 Lint 등 코드 포맷팅을 한다.
-
배포하기 위한 빌드 과정을 거친다.
-
코드를 배포한다.
-
테스트를 진행한다.
-
위 모든 과정을 DEV, QA, PROD 환경에서 모두 하고, 각각에 맞는 환경에 배포한다.
📌 CI/CD의 Tool
Jenkins, Buildkite, GitLab CI/CD, GitHub Actions, Bitbucket Pipelines, Travis CI, Circle CI, BITRISE 등 다양한 CI/CD Tool이 존재한다.
💡 Jenkins의 장점은?
- 무료 사용
- 사용자 정의 옵션
- 방대한 양의 플러그인
- 다양한 적용 사례 및 풍부한 레퍼런스
- Remote Access API 제공 등이 있다.
📌 요약
정리하자면, 지속적 통합은 소프트웨어 빌드를 패키징 및 테스트하고 변경이 단위 테스트를 통과하지 못할 경우 개발자에게 알린다. 지속적 제공은 애플리케이션과 서비스 및 기타 기술 배포를 런타임 인프라에 제공하고 경우에 따라 부가적인 테스트를 실행하기도 하는 자동화다.
CI/CD 파이프라인 개발은 애플리케이션을 수시로 개선하고 안정적인 제공 프로세스가 필요한 기업에서 표준적인 개발 방식이다. CI/CD 파이프라인을 구축하면 팀은 애플리케이션을 향상시키는 데 더 초점을 두면서 이를 다양한 환경으로 제공하기 위한 세부 사항에 대해 신경을 덜 쓸 수 있다.
데브옵스팀이 CI/CD를 시작하기 위해서는 기술, 작업 방식 및 우선순위에 대한 협업이 필요하다. 팀은 비즈니스와 기술에 대한 적절한 접근 방식을 합의해야 한다. 파이프라인이 구축된 이후에는 CI/CD 방식을 일관적으로 따라야 한다.
REF.
드림코딩 CI/CD 영상
SKplanet T아카데미
CIOKorea CI/CD Column
우아한 형제들 기술 블로그
