서론
최근에 프로젝트를 하나 시작하기로 했다. 서버와 Git repo를 따로 사용하면서 REST API만 연동한 경험은 있지만. 다른 프론트엔드와 협업을 하는 것은 처음이라 어떤 것들을 신경써야 하는지 되짚어봤다. 그동안 혼자 git을 사용하면서 merge나 rebase를 하는 과정에서 충돌나던 것들이 신경쓰였고. 코드를 병합할 때마다 온전히 코드가 돌아갈 수 있으면 좋겠다는 생각이 들었다. 어떻게 하면 좋을까 하다가 예전에 문득 CI/CD라는 말을 들어보았던 것이 생각나서 프로젝트 시작 전에 혼자 한 번 구축해보고 브랜치 전략을 세워서 프로젝트에 적용할 수 있다면 좋겠다고 생각했다.
CI/CD
CI/CD는 continuous integration/continuous deploy의 약자로, 번역하면 지속적 통합/배포이다. 한마디로 여러 사람의 코드를 합쳐서 배포하는 과정을 지속하고 용이하게 해주는 한 과정이라고 생각하면 된다. 일반적으로 우리가 작성한 코드를 배포하기까지 어떤 과정들이 필요한지 생각해보자.
1. 컴파일
쉽게 말하면, 우리가 작성한 코드를 기계가 이해할 수 있는 기계어로 번역하는 것.
javascript의 경우는 다음과 같다.
1) source code를 파싱하여 AST(Abstract Syntax Tree)를 만든다.
2) AST를 Ignition(javascript를 바이트 코드로 변환하는 인터프리터)로 넘긴다.
3) 바이트 코드를 실행하며 작동한다.
Modern JavaScript Compiler는 대부분 런타임 내에서 빠르게 컴파일 한다.(JIT, Just-In-time compilation)
대표적인 javascript 컴파일러는 Babel
2. 빌드
소스 코드를 실행 가능한 파일로 만드는 과정이다. 컴파일도 Build의 일부분이라고 할 수 있다.
js의 경우 보통 Webpack을 많이 사용한다.
필요없는 부분들은 다 처내고, 합쳐서 최대한 가볍고 실행가능한 소프트웨어로 만들어낸다.
npm run build를 하면 아래 사진과 같이 build폴더 안에 js파일들이 생성된다.
3. CI(Continuous Integration)
위에서 말했듯이 지속적 통합을 의미하며 개발을 진행하며 여러명의 코드를 합쳐도 지속적으로 문제없이 품질이 유지될 수 있도록 함을 의미한다.
CI라는 개념이 나오기 전까지는 개발-배포까지 하고 나서야 코드에 오류가 있는지 없는지, 올바르게 작동하는지 등을 체크할 수 있었다고 한다.
CI를 적용할 경우, 빌드, 테스트를 자동화하여 코드 일부분을 수정하여 병합하기만 하면 개발자가 신경 쓸 부분이 현저히 줄어든다.
다음은
마틴 파울러(리팩토링, 애자일 개발 방법론을 널리 퍼뜨린 개발자)가 제시한 CI의 4가지 규칙이다.
1.모든 소스코드가 살아 있고, 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것.2.빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드할 수 있게 할 것.
- 테스팅 자동화를 통해 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것.
4.누구든 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것.
요약
1. 기존 코드 + 새로 구현한 코드
2. 병합된 코드가 올바른지 빌드 및 검증
3-1. 문제가 있다면 수정하고 1번부터 다시.
3-2. 문제가 없다면 배포
4. CD(Continuous Deployment)
지속적 배포라는 뜻으로 소프트웨어가 항상 안정성이 검증된 상태에서 배포될 수 있도록 관리하자는 개념이다. 지속적 배포(Continuous Delivery)로 쓰이기도 한다.
출처: https://www.redhat.com/ko/topics/devops/what-is-ci-cd
