feat: CI/CD workflow 추가

[hyh1016]

📌 관련 이슈

closes #16

📝 작업 개요

github action 기반 CI/CD 구축

✅ 작업 사항

CI는 PR이 생성되었을 때, 머지되었을 때 실행되도록 구성
CD는 Actions 탭에서 직접 트리거링하도록 구성 (논의 필요)

💭 고민한 점들(필수 X)

일단 workflow를 main에 올린 뒤 제대로 동작하는지 한 번 체크해보고, 문제 있으면 fix로 후속 대응 예정

📸 스크린샷(필수 X)

[pythonstrup]

Claude Code를 사용한 리뷰

CI/CD 워크플로우 구현에 대한 리뷰입니다.

👍 잘 구현된 부분

1. CI/CD 분리: CI와 CD를 별도 워크플로우로 분리하여 관심사를 명확히 구분한 점이 좋습니다
2. 트리거 설정: PR과 main 브랜치 push에 대한 CI 트리거가 적절하게 설정되었습니다
3. Gradle 캐싱: Gradle 의존성 캐싱으로 빌드 시간 단축을 고려한 점이 좋습니다
4. Docker 멀티 플랫폼: linux/amd64 플랫폼 명시로 배포 환경 호환성을 고려했습니다

🔍 개선 제안

1. CD 워크플로우 보안 강화

• 컨테이너 이름을 고정하여 더 안전한 컨테이너 관리가 가능합니다

2. 테스트 결과 개선

• CI에서 테스트 실패 시에만 결과를 퍼블리시하는데, 성공 시에도 결과를 볼 수 있도록 하는 것이 좋겠습니다

3. 환경별 배포 고려

• 현재는 수동 트리거만 가능한데, 향후 dev/staging/prod 환경별 배포 전략도 고려해보시면 좋겠습니다

💡 추가 제안

1. 헬스체크 추가: 배포 후 애플리케이션이 정상적으로 시작되었는지 확인하는 헬스체크 로직
2. 롤백 전략: 배포 실패 시 이전 버전으로 롤백하는 메커니즘
3. 알림 설정: 배포 성공/실패에 대한 Slack 등 알림 연동

전반적으로 CI/CD의 기본 구조가 잘 잡혀있어서 좋은 시작점이라고 생각합니다! 👏

[pythonstrup]

리뷰 확인 부탁드립니다~

[pythonstrup]

pn1. java24를 사용하기로 했던 것 같은데, openjdk26을 사용한 이유는 무엇인가요?

[hyh1016]

omg 이거는 제일 최신태그 복사하다가 early access 버전이 들어갔네용. 바로 수정했습니다

[pythonstrup]

Dockerfile에서 builder를 구성하지 않고 GithubActions 머신에 자바 환경을 설정하여 그 안에서 build를 돌리는 선택을 한 이유가 무엇인가요?

[hyh1016]

좋은 질문이네요, 나도 깊게 생각해본 적은 없는 것 같은데
Dockerfile 내에 빌더를 구성하면 build+runtime을 캡슐화할 수 있다는 장점이 있지만,
GitHub Action runner 방식으로 구성할 때보다 전반적인 캐시 효율성이 낮다고 하네요.

1. Gradle cache 효율성 - CI 단계에서의 캐싱이 빌드 속도 개선 면에서 더 좋다고 함
2. Dockerfile 내에서 빌드하면 소스 코드 변경 시마다 전체 layer가 다시 쌓이니 빌드 타임이 길어짐 (layer 캐싱에 실패하는 게 action의 gradle cache가 miss되는 것보다 정말로 매우 비효율적인지?는 테스트해봐야 검증할 수 있을 듯하지만)

혹시 Dockerfile builder가 더 좋다고 생각하는 이유가 있다면, 후속 이슈에서 반영하겠습니다~!

[pythonstrup]

고생했어~