기존의 배포방식 문제점

FrontEnd

1. npm 패키지를 통하여 직접 로컬에서 수동 빌드 npm run build
2. build 폴더 내부 파일들을 S3 버킷에 수동 업로드
3. 정적 리소스 변경에 따른 CloudFront 캐싱 무효화처리 작업 수동 진행

BackEnd

1. gradle을 통해 직접 로컬에서 수동 빌드 gradlew clean build -x test
2. 빌드된 .jar 파일을 ssh접속을 통하여 EC2 내부에 .jar파일 업로드
3. EC2 내부에서 실행되고있던 애플리케이션 중단 후 업로드한 .jar파일 재실행

기존 배포 방식의 한계

1. 오류 가능성
   • 수동 배포 과정에서 파일 누락, 잘못된 설정 변경 등 실수 발생 위험
   • 배포 단계별 체크리스트 관리 필요
2. 비효율적인 시간 소요
   • 빌드부터 배포까지 모든 단계를 직접 수행하며 대기 시간 발생
   • 배포 과정에 직접적인 개입
3. 일관성 부족
   • 배포 환경에 따라 배포 과정과 결과가 달라질 수 있음
4. 롤백의 어려움
   • 배포 실패 시 이전 버전으로 신속하게 복구하기 어려움
   • 수동 롤백 과정에서 추가적인 오류 발생 가능성
5. 보안 위험
   • SSH를 통한 서버 직접 접속으로 인한 보안 취약점 존재
   • 접속 정보(비밀번호, 키 등) 공유와 관리의 어려움

개선된 배포 자동화

<aside> 💡

**파이프라인 구성

[GitHub Repository] → [GitHub Actions] → [AWS S3/CodeDeploy] → [배포 대상(S3/CloudFront/EC2)]**

</aside>

FrontEnd

1. GitHub main 브랜치에 frontend 코드 변경사항 Push
2. GitHub Actions workflow 자동 트리거