CI/CD 도입 배경
프로젝트에 GitHub Actions를 적용하기로 했다.
이 결정의 가장 큰 이유는 매번 코드 변경 사항을 AWS에 배포하는 것이 귀찮기 때문이다..
또 프론트와 협업을 하면서 프로젝트를 진행하고 있는데 프론트분들이 mock 데이터를 사용할 수도 있지만 배포를 미리 진행해서 개발이 완료된 API에 대해서 직접 API 호출을 해보며 문제를 빠르게 파악하자는 목적도 있었다.
이전에 배포를 진행해본 경험이 있는데, 그 때는 GitHub Actions와 같은 CI/CD 툴을 사용하지 않았었다.
당시 GCP를 사용해서 Compute Engine에 인스턴스를 만들고 해당 인스턴스에서 github에 올려둔 프로젝트 소스 코드를 전부 땡겨와 인스턴스에서 docker comopse를 통해 스프링 서버를 올렸었다.
이 과정들은 지금 생각해보면 비효율적인 것 같은데 그렇게 생각하는 이유는
1. 코드가 변경될 때 마다 매번 해당 인스턴스 터미널에서 gitpull을 하거나 vim 에디터로 코드를 변경해줬었다. 심지어 배포 브랜치랑 개발 브랜치를 나누지도 않았어서 갑자기 서버에 에러가 생기면 뭘 고쳐서인지도 왜 생긴 문제인지도 파악하기 어려웠다.
2. 스프링을 사용하는데 jar 파일만 당겨오는게 아니라 모든 프로젝트를 github에서 땡겨와 불필요한 파일들도 가져오기 때문에 속도가 느렸다.
3. 롤백에 관한 고려가 전혀 없었다.
이정도인 것 같다.. 그래도 이렇게 삽질해본 경험이 있으니까 CI/CD가 필요하다는 것도 직접 느끼게 되고 배우려고 노력하게 된 것 같다.
그럼 왜 CI/CD 툴 중에서 GitHub Actions를 선택하게 됐을까?
우선 프로젝트를 개발하는 기간을 약 2달 정도로 잡고 있는데 GitHub Actions가 배우는 러닝 커브가 낮다고 들었기 때문이다.
그리고 무료로 사용할 수 있고, 빌드용 서버도 따로 필요 없으며 프로젝트를 GitHub에서 진행하기 때문에 접근성도 좋다고 생각했다.
GitHub Actions 사용이 익숙해지면 Jenkins와 같은 툴도 공부해볼 예정이다.
그리고 CI/CD 툴이라고 하지만 GitHub Actions는 CI에 주로 사용되고 CD용 툴은 다른 툴을 사용하기도 하는 것 같아서 일단 GitHub Actions에 익숙해지고 나면 다른 툴도 익혀보는게 좋지 않을까 싶다.
공부 방법
일단 무작정 공식 문서를 보고 프로젝트에 적용하는 방법도 있지만 필자는 전체적으로 어떻게 사용하는지 공부하고 나서 적용하는걸 선호하는 편이라 인강을 참고해 먼저 GitHub Actions에 대해 공부했었다.
수강했던 강의는 비전공자도 이해할 수 있는 CI/CD 입문·실전
라는 인프런 강의인데 강의시간도 짧고 CI/CD 공부를 시작할 때 큰 그림을 잡을 수 있을 것 같아서 수강하게 되었다.
프로젝트에는 이 강의에서 배운 내용과 GitHub Actions 공식 문서를 참고하며 진행할 예정이다.