refactor: application 추적에 다른 CICD 파이프라인 수정 & JWT 토큰 개별화로 클라이언트 접근 방지#163
Conversation
- application-dev.yml, application-local.yml, application-prod.yml, application-test.yml 파일 추가 - .gitignore에서 애플리케이션 파일 관련 항목 제거
- Swagger UI의 경로를 "/swagger-ui.html"로 변경하여 리소스 접근을 개선함.
- 새로운 워크플로우 파일인 individual-deploy-test.yml을 추가하여 pull request 시 자동으로 배포 테스트를 수행하도록 설정. - 개발 환경에 맞춘 JDK 설정, Gradle 캐싱, Docker 빌드 및 배포 스크립트를 포함함. - application-dev.yml, application-local.yml, application-prod.yml 파일에서 JWT 비밀 키를 환경별로 수정함.
jayn2u
changed the title
There was a problem hiding this comment.
해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.
There was a problem hiding this comment.
해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.
이 문제를 해결하기 위해서 git 명령어 중 skip-worktree라는 명령어를 사용해서 문제를 해결했습니다!
git update-index --skip-worktree src/main/resources/application.yml위의 명령어를 사용하면 로컬에서 변경이 일어나도 git이 변경사항을 스테이징 하지 않더라구요.
다시 추적을 하기 위해서는 아래의 명령어를 다시 사용하기만 하면 됩니다.
git update-index --no-skip-worktree src/main/resources/application.ymlThere was a problem hiding this comment.
이렇게 하면 github에는 application.yml이 되어 있어서, 새롭게 프로젝트를 clone 받아도 InteliJ에서 gradle이 정상적으로 인덱싱을 할 수 있어요.
There was a problem hiding this comment.
해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.
각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될것 같다고 해주셨는데, 그런 상황의 예시를 알 수 있을까요?
There was a problem hiding this comment.
예를 들어서 최종 커밋에서 local 프로필이 주석이 해제되어있었는데, 개발하다보니 마지막 시점에서 dev로 주석이 해제되어있으면 코드상 변경은 되어있지만, 유의미한 변경사항은 아니라서 이 부분을 매커밋마다 남기는 건 조금 별로이지 않을까? 이런 생각을 했습니다. 그렇다고 gitignore에 파일채로 추적을 하지 않는 것은 IDE에서 인덱싱을 하지 못하는 문제가 있기도 하구요. 그래서 위와 같은 방법을 생각했어요!
There was a problem hiding this comment.
오 좋은 아이디어네요!
그러면 이제 규칙을 만드는 것인데, 해당사항은 저희가 30일에 만나서 컨벤션 정할때 포함되면 좋겠네요!
개인적으로 규칙은 많아질수록 까먹기 쉽기때문에 노션에 꼭 문서화를 했으면 합니다!
There was a problem hiding this comment.
맞아요! 안그래도 작업하다가 컨벤션으로 명시화 할 게 좀 많더라구요!!
|
지금 PR에서 진행한 dev 서버 배포는 정상적으로 이루어지고 있습니다! GitHub Secrets에 값들을 전부 할당해두어서 자동 배포는 잘 이루어지고 있네요. |
- dev 브랜치 이름을 'develop'으로 변경 - dev 및 prod 프로파일 활성화 시 환경별 application.yml 파일 생성 방식 개선 - Docker 실행 시 환경 변수 추가로 보안 및 설정 강화
- 새로운 워크플로우 파일을 추가하여 main 및 develop 브랜치에 대한 CI/CD 파이프라인을 설정. - 환경별 application.yml 파일을 자동으로 생성하도록 구성. - Docker 이미지 빌드 및 푸시, 서버 배포를 위한 단계 포함.
|
지금 |
There was a problem hiding this comment.
확인했습니다.
전반적으로 CI/CD 파이프라인 구성을 잘해주셨네요~
저는 현재 코드로 머지해도 괜찮다고 생각합니다! 수고하셨어요!
[요청]
- 하나의 이슈에 대해서만 PR 만들어주시는걸 부탁드려요. 작업을 하다보면 섞이는 일들이 있을 수 있는데 리뷰하는 입장에서는 이슈 하나만 있는게 PR을 볼때 편합니다.
- 브랜치 만들때
refactor/#133_jwt알고리즘(refactor/#이슈번호_이슈설명) 과 같이 만들어주세요.fetch시 용이성을 위해서 입니다.
그러면 이렇게 두 개의 이슈가 연관이 있어서 하나의 PR로 처리하는 방법이 더 적절하다고 생각하면 이슈들을 정리하고 다시 만들면 될까요? |
jayn2u
requested review from
JjungminLee and
Copilot
and removed request for
Copilot
어떤 전략을 생각하고 계신지 궁금합니다! 우선 저는 분기문을 통해 main브랜치면 main에 해당하는 스크립트, dev브랜치면 dev에 해당하는 스크립트가 작동하고 actions도 그렇게 동작한다고 생각해서요! |
There was a problem hiding this comment.
Pull Request Overview
This PR centralizes sensitive configuration into environment-specific YAML files, isolates JWT secrets per environment, and replaces the old Gradle CI workflow with new GitHub Actions pipelines.
- Introduce
application-*.ymlfor test, prod, local, and dev profiles with environment variables - Enforce separate JWT secrets per environment to prevent cross-env access
- Remove old
.github/workflows/gradle.ymland add newdeploy.yml&deploy-test.ymlpipelines
Reviewed Changes
Copilot reviewed 9 out of 10 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/main/resources/application.yml | Set default profile to local, commented out others |
| src/main/resources/application-test.yml | New test profile configs with environment variables |
| src/main/resources/application-prod.yml | New prod profile configs including Hikari and management |
| src/main/resources/application-local.yml | New local profile configs |
| src/main/resources/application-dev.yml | New dev profile configs |
| src/main/java/ssu/eatssu/domain/auth/infrastructure/SecurityConfig.java | Whitelist swagger-ui.html in security resources |
| .github/workflows/gradle.yml | Removed old CI workflow |
| .github/workflows/deploy.yml | Added CI/CD pipeline for main & develop pushes |
| .github/workflows/deploy-test.yml | Added PR‐based deploy for develop branch |
Comments suppressed due to low confidence (3)
src/main/resources/application-test.yml:43
- The test profile is using production AWS credentials; switch to test-specific AWS secrets (e.g., EATSSU_AWS_ACCESS_KEY_TEST) to avoid accidental access to prod resources.
accessKey: ${EATSSU_AWS_ACCESS_KEY_PROD}
src/main/resources/application-local.yml:43
- The local profile is reusing DEV AWS credentials; consider defining separate LOCAL AWS environment variables for better isolation and clarity.
accessKey: ${EATSSU_AWS_ACCESS_KEY_DEV}
src/main/resources/application-test.yml:3
- Add a
server.env: testproperty to this profile (as in prod/dev/local) for consistent environment identification.
port: 9000
이번 PR만 이렇게 하고, 다음번 부터 하나의 PR로 처리해도 될것 같아요! 긍정적으로 생각해주셔서 감사합니다 :) |
CI와 CD를 어떻게 구성하느냐에 따라서도 다른 것 같아요. 이 부분은 생각이 조금 정리가 되면 노션이나 슬랙으로 다시 한 번 언급해드릴게요! |
아유 아닙니다~ 리뷰 꼼꼼히 해주셔서 오히려 제가 더 감사하죠~ |
|
지웅님 해당 PR 머지해주시면 될것 같아요! 수고하셨어요! |
#️⃣ Issue Number
📝 요약(Summary)
application파일들을 추적하면서 민감한 정보들은 OS 환경변수와 GitHub Secrets를 사용함.💬 공유사항 to 리뷰어
✅ PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.