![[AWS] 8. GitHub Actions CI](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2025-11-28T21%3A04%3A14.822Z-b6904c78-efad-44df-93e6-01ca5f2f34f0&w=3840&q=75)
ec2,rds,elb 창 켜두기
rds -
elb-
rds-elb 그룹을 허용
healthcheck는 복잡한거 말고 그냥 db 에서 pk 하나 조회되는 정도로 간단한걸로 만들기 “/”
직접 jar를 구워서 던질거 아니니까 application.yml에 dev를 prod로 바꾸지 않아도 된다.
sql문 필요하면 로그로 따로 남기는 게 낫다.
개발 완료 후
1. 통합 테스트 코드 작성하기
- 통합 테스트 전체 실행해보기
- jar 파일 dev 모드로 local에서 build
- jar 파일 직접 실행해보기 (여기까지 jar tool & 직접 실행해본 것)
왜 checkout? 그 환경에 가야 내가 원하는 버전을 설치할 수 있기 때문 v1으로 가면 21 설치 못함
깃헙 액션 = cd 도구 = 코드 받으면 jar로 구워서 elb에 던져주는애
깃헙 액션이 테스트 서버 만듦 → 우분투 설치해줌(내가 그렇게 설정했으니까)→checkout해서 jdk-21 설치함 → build하면서 라이브러리 전부 다운로드 받음 → 다운 받은 gradle 파일들 다음번에 내가 push하면 서버 새로 만들어지니까 다시 build하면 새로 만들어지니까 오래걸림 → cache해두면 다른 컴퓨터에 내가 다운 받은 gradle을 캐싱해둔다. (실무에서는 사용하지 않도록 생략한다.)
내가 명령어를 실행하고 있는 context 어디? (pwd 위치)
⇒ home/내 ID 폴더
(기본 사용자 이름이 뭔지는 문서 찾아봐야 됨)
⇒ 궁금하면 -name 하나 파서 where is my name / run : pwd 하면됨
여기까지는 테스트 서버에 build해서 잘됐는지 확인하는 것까지
일단 여기까지 확인해보자
= build가 된다는거는 test 서버 환경과 실제 배포환경이 같으니까 실제 aws에 던져도 된다는 의미
Share article