문제점
초기에 CICD를 적용하지 않아 백엔드 서버를 업데이트 하려면 서버를 내려야 하는 문제점이 발생했다.
발생한 문제를 정리하니 다음과 같다.
- 업데이트를 하려면 무조건 서버를 관리한는 컴퓨터만 업데이트가 가능하다.
- 서버를 내리게되면 프론트 개발자분들의 작업성이 떨어진다.
- 시간적 소모가 크다.
일를 해결하기위해서 CICD의 필요성을 느꼈으며, 종류와 구현방법을 고민했다.
CICD란?
- CI(Continuous Integration) : 어러 개발자들의 코드를 계속해서 통합하는 것.
- CD(Contiunous Delivery) : 개발자들이 코드를 작성하면, 사용자및 내부 사용자들이 사용할 수 있게 만드는 것 → 지속적으로 배포가능한 상태를 유지하는 것.
CICD 어떤 방법들이?
- docker와 GitHub Actions을 활용한 방법
- CodeDeploy와 AWS S3그리고 GitHub Actions를 활용하는 방법
이와같은 두가지 방법정도를 고려했으며 선택은 CodeDeploy를 선택.
- 선정이유 : docker의 경우 사용성이 좋고 컨테이너를 통해 높은 호환성을 유지할 수 있으나 프로젝트의 규모를 고려했을 때 꼭 필요한 작업은 아니라고 생각했기 때문이다. 따라서 AWS에서 제공해주는 서비스들과 git을 연동해서 서버에 재배포해주는 방법을 선택했다.
어떻게 이루어지나?
다음과 같은 아키텍쳐 구조를 가지며 1-5번과 같은 플로우를 따른다.
적용과정은 아래 블로그를 참조해서 가능했다.
참조 :
적용후 문제점!
-
처음 CodeDeploy를 적용하고 이미지를 게시판에 업로드할 때 에러가 발생.
→ IOException : permission denied 권한문제 발생
→ 리눅스와 권한문제 를 참조. -
ReadMe를 수정해도 재배포가 이루어지는 현상.
Main 브랜치에서 ReadMe를 수정 → Main 브랜치에 코드가 통합(변경)되었다고 판단해서 서버에 재배포를 반복하는 문제가 발생했다.
ReadMe의 경우 다른 브랜치나 IDE내부에서 수정을 완료한 다음 업로드 하도록 변경.
후기
CICD는 편리함과 동시에 정확성을 요구한다.
업데이트를 정해진 단위(기능의 완성 또는 버전변경)에 따라 하지 않는다면 오히려 서버를 계속해서 재배포하는 낭비가 될 수 있단는점을 알았다.
또한 다양한 방법이 있으며 완전한 무중단이 아니기 때문에 실제로는 서버를 1개가 아닌 2개 이상의 서버를 동시에 제어할 필요성을 알게되었다.
다만 코드를 누구나 수정하고 업데이트할 수 있는점은 분명한 강점이며 프론트 개발자분들에게 더이상 서버를 잠시 내려도 되는지 물어보지 않아도 되는점이 최고의 장점이라고 느꼈다..
