목차

Continuous Integration(CI)

git을 활용해 협업 할 때, 다음과 같은 개발 방식으로 작업을 하는 사람이 있다.

1. 개발을 위한 dev 브랜치와 배포를 위한 main 브랜치를 갖고 있다.
2. 기능 개발을 위해 feature 브랜치를 생성해 작업을 한 후, dev 브랜치에 Pull Request
3. dev 브랜치의 Pull Request에 대한 리뷰 후, 문제가 없다면 merge
4. 배포를 할 때 dev 브랜치를 main 브랜치에 merge

위와 같은 방식의 세 번째 단계에서, 리뷰어는 Pull Request가 올라올 때마다 변경된 코드가 의도대로 잘 동작 하는지, 기존 기능에 문제가 생기지 않았는지 확인해야 하는 과정이 필요하다.

만약 작성된 테스트 코드를 있다면, 리뷰어는 해당 브랜치를 내려받아 테스트가 모두 통과하는지 확인하는 것으로 위 과정을 수행할 수 있다.

하지만 리뷰어가 직접 테스트 코드를 실행하고, 모든 테스트를 통과 했는지 확인하는 과정은 너무 간단해서, 굳이 사람이 하지 않고 이를 자동화 할 수 있다.

코드의 변경 사항이 생기면 이를 자동으로 테스트 하고, 결과에 이상이 없을 경우에 변경 사항을 반영하는 과정을 Continuous Integration이라고 한다.

Continuous Deployment

1. 개발을 위한 dev 브랜치와 배포를 위한 main 브랜치를 갖고 있다.
2. 기능 개발을 위해 feature 브랜치를 생성해 작업을 한 후, dev 브랜치에 Pull Request
3. dev 브랜치의 Pull Request에 대한 리뷰 후, 문제가 없다면 merge
4. 배포를 할 때 dev 브랜치를 main 브랜치에 merge

위 절차에서 배포를 위한 main 브랜치에 변경 사항이 생겼다면, 서버가 이 변경 사항을 반영하도록 해줘야 한다. 이 역시 개발자가 변경을 확인하고, 서버에 접속해서 코드를 업데이트 할 필요 없이 자동화 할 수 있다.

코드의 변경 사항이 생기면 서버가 이 변경 사항을 자동으로 반영하도록 하고, 배포하는 것을 Continuous Delivery이라고 한다.