포스트

[blessflow] CICD 세팅

구현한 자동 배포:

프로젝트 깃에서 apps 또는 packages를 수정해서 push하면, 변경된 프론트나 백엔드+(예외적 추가로 gateway백엔드;빌드버전을 api로 확인하기 위해)만 재빌드하여 dev. 도메인에 올린다. biblecardai.dev.blessflow.com 개발서비스는 빠른개발을 위해서 변경한 마이크로서비스만 재빌드해서 올린다.

production 실서비스 도메인은 직접 tag를 붙여서 push해줘야만 재빌드된다. biblecardai.blessflow.com 실서비스는 dev와는 다르게, 안정성을 위해 전체 서비스를 다 새로 빌드해서 올리는게 관행이라고 한다.

배포된 버전 정보(개발/실서비스)

소감:

마이크로서비스가 일단 만들어 놓으면 좋긴 한데, 포트를 연결하고 에러 없이 처음 자동 배포 설정을 해놓는게 시간이 좀 많이 든다.

mvp면 굳이 마이크로서비스 아키텍처로 만들 필요는 없을 것 같다. 왜냐하면 아키텍처로 인해 챙겨줘야 하는 환경변수들이 더 많아지고 포트 관리도 많아져서, 그로 인한 디버깅에 소모하는 시간이 꽤 많아서 서비스 알맹이 개발에 쏟을 노력을 등한시 하게 될 수 있기 때문이다. 시간은 한정되어 있으니까.

하지만 이번 프로젝트는 마이크로서비스 아키텍처를 처음 구현하고 끝까지 트러블슈팅을 하면서 자동화까지 그 학습의 한계를 확장하는 데에 의의가 있었다.

새로운 컴퓨터 환경에서 CD를 할 때 kubernetes와 인증서를 항상 세팅하는 건 개발환경에서는 다소 무거운 세팅이다. 그래서 로컬 프로젝트는 통합서버 방식과 localhost 도메인으로 개편하고, 더 가볍게 어디든 실행할 수 있도록 리팩토링해놓을 예정이다.

그리고 추후 프로젝트도 통합서버(모놀리스)로 개발을 하려고 한다. 빠르게 알맹이를 개발하고, 인프라는 뒤로 미뤄도 된다.

실서비스 전에 microservice로 리팩토링하고 kubernetes로 cicd 하는 건 이제 어렵지 않기 때문이다.

#cicd #devops #blessflow

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.