refactor: application 추적에 다른 CICD 파이프라인 수정 & JWT 토큰 개별화로 클라이언트 접근 방지 #163

jayn2u · 2025-06-24T01:47:42Z

#️⃣ Issue Number

📝 요약(Summary)

application 파일들을 추적하면서 민감한 정보들은 OS 환경변수와 GitHub Secrets를 사용함.
이와 동시에 개발서버와 운영서버에서 사용하는 JWT 키 값을 달리해서 개발서버에서 발급받은 토큰을 가지고 운영서버에 접근을 하지 못하게 막음

💬 공유사항 to 리뷰어

✅ PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요.

커밋 메시지 컨벤션에 맞게 작성했습니다.
변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).

- 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 · 2025-06-24T02:07:20Z

src/main/resources/application.yml

해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.

해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.

이 문제를 해결하기 위해서 git 명령어 중 skip-worktree라는 명령어를 사용해서 문제를 해결했습니다!

git update-index --skip-worktree src/main/resources/application.yml

위의 명령어를 사용하면 로컬에서 변경이 일어나도 git이 변경사항을 스테이징 하지 않더라구요.
다시 추적을 하기 위해서는 아래의 명령어를 다시 사용하기만 하면 됩니다.

git update-index --no-skip-worktree src/main/resources/application.yml

이렇게 하면 github에는 application.yml이 되어 있어서, 새롭게 프로젝트를 clone 받아도 InteliJ에서 gradle이 정상적으로 인덱싱을 할 수 있어요.

해당 파일을 어떻게 추적할지는 조금 더 방법을 한 번 찾아봐야겠습니다! 각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될 것 같은데, 무의미한 행위라서 그렇지 않도록 한 번 연구를 해봐야겠어요.

각각 개발하고 커밋할 때 마다 이 파일이 계속 변경될것 같다고 해주셨는데, 그런 상황의 예시를 알 수 있을까요?

예를 들어서 최종 커밋에서 local 프로필이 주석이 해제되어있었는데, 개발하다보니 마지막 시점에서 dev로 주석이 해제되어있으면 코드상 변경은 되어있지만, 유의미한 변경사항은 아니라서 이 부분을 매커밋마다 남기는 건 조금 별로이지 않을까? 이런 생각을 했습니다. 그렇다고 gitignore에 파일채로 추적을 하지 않는 것은 IDE에서 인덱싱을 하지 못하는 문제가 있기도 하구요. 그래서 위와 같은 방법을 생각했어요!

오 좋은 아이디어네요!
그러면 이제 규칙을 만드는 것인데, 해당사항은 저희가 30일에 만나서 컨벤션 정할때 포함되면 좋겠네요!
개인적으로 규칙은 많아질수록 까먹기 쉽기때문에 노션에 꼭 문서화를 했으면 합니다!

맞아요! 안그래도 작업하다가 컨벤션으로 명시화 할 게 좀 많더라구요!!

jayn2u · 2025-06-24T02:08:20Z

지금 PR에서 진행한 dev 서버 배포는 정상적으로 이루어지고 있습니다! GitHub Secrets에 값들을 전부 할당해두어서 자동 배포는 잘 이루어지고 있네요.

- dev 브랜치 이름을 'develop'으로 변경 - dev 및 prod 프로파일 활성화 시 환경별 application.yml 파일 생성 방식 개선 - Docker 실행 시 환경 변수 추가로 보안 및 설정 강화

- 새로운 워크플로우 파일을 추가하여 main 및 develop 브랜치에 대한 CI/CD 파이프라인을 설정. - 환경별 application.yml 파일을 자동으로 생성하도록 구성. - Docker 이미지 빌드 및 푸시, 서버 배포를 위한 단계 포함.

jayn2u · 2025-06-24T08:41:45Z

지금 develop 브랜치로 병합하려고 시도할 때, 모든 상황에서 배포 스크립트가 동작하게 되어있네요. 파이프라인 전략도 다시 한 번 생각을 해봐야 할 것 같습니다.

JjungminLee

확인했습니다.
전반적으로 CI/CD 파이프라인 구성을 잘해주셨네요~
저는 현재 코드로 머지해도 괜찮다고 생각합니다! 수고하셨어요!
[요청]

하나의 이슈에 대해서만 PR 만들어주시는걸 부탁드려요. 작업을 하다보면 섞이는 일들이 있을 수 있는데 리뷰하는 입장에서는 이슈 하나만 있는게 PR을 볼때 편합니다.
브랜치 만들때 refactor/#133_jwt알고리즘(refactor/#이슈번호_이슈설명 ) 과 같이 만들어주세요.fetch시 용이성을 위해서 입니다.

jayn2u · 2025-06-24T11:52:44Z

확인했습니다. 전반적으로 CI/CD 파이프라인 구성을 잘해주셨네요~ 저는 현재 코드로 머지해도 괜찮다고 생각합니다! 수고하셨어요! [요청]

하나의 이슈에 대해서만 PR 만들어주시는걸 부탁드려요. 작업을 하다보면 섞이는 일들이 있을 수 있는데 리뷰하는 입장에서는 이슈 하나만 있는게 PR을 볼때 편합니다.

브랜치 만들때 refactor/#133_jwt알고리즘(refactor/#이슈번호_이슈설명 ) 과 같이 만들어주세요.fetch시 용이성을 위해서 입니다.

그러면 이렇게 두 개의 이슈가 연관이 있어서 하나의 PR로 처리하는 방법이 더 적절하다고 생각하면 이슈들을 정리하고 다시 만들면 될까요?

JjungminLee · 2025-06-24T11:57:08Z

지금 develop 브랜치로 병합하려고 시도할 때, 모든 상황에서 배포 스크립트가 동작하게 되어있네요. 파이프라인 전략도 다시 한 번 생각을 해봐야 할 것 같습니다.

어떤 전략을 생각하고 계신지 궁금합니다! 우선 저는 분기문을 통해 main브랜치면 main에 해당하는 스크립트, dev브랜치면 dev에 해당하는 스크립트가 작동하고 actions도 그렇게 동작한다고 생각해서요!

Copilot

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-*.yml for 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.yml and add new deploy.yml & deploy-test.yml pipelines

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: test property to this profile (as in prod/dev/local) for consistent environment identification.

  port: 9000

JjungminLee · 2025-06-24T11:58:08Z

확인했습니다. 전반적으로 CI/CD 파이프라인 구성을 잘해주셨네요~ 저는 현재 코드로 머지해도 괜찮다고 생각합니다! 수고하셨어요! [요청]

하나의 이슈에 대해서만 PR 만들어주시는걸 부탁드려요. 작업을 하다보면 섞이는 일들이 있을 수 있는데 리뷰하는 입장에서는 이슈 하나만 있는게 PR을 볼때 편합니다.

브랜치 만들때 refactor/#133_jwt알고리즘(refactor/#이슈번호_이슈설명 ) 과 같이 만들어주세요.fetch시 용이성을 위해서 입니다.

그러면 이렇게 두 개의 이슈가 연관이 있어서 하나의 PR로 처리하는 방법이 더 적절하다고 생각하면 이슈들을 정리하고 다시 만들면 될까요?

이번 PR만 이렇게 하고, 다음번 부터 하나의 PR로 처리해도 될것 같아요! 긍정적으로 생각해주셔서 감사합니다 :)

jayn2u · 2025-06-24T11:58:47Z

지금 develop 브랜치로 병합하려고 시도할 때, 모든 상황에서 배포 스크립트가 동작하게 되어있네요. 파이프라인 전략도 다시 한 번 생각을 해봐야 할 것 같습니다.

어떤 전략을 생각하고 계신지 궁금합니다! 우선 저는 분기문을 통해 main브랜치면 main에 해당하는 스크립트, dev브랜치면 dev에 해당하는 스크립트가 작동하고 actions도 그렇게 동작한다고 생각해서요!

CI와 CD를 어떻게 구성하느냐에 따라서도 다른 것 같아요. 이 부분은 생각이 조금 정리가 되면 노션이나 슬랙으로 다시 한 번 언급해드릴게요!

jayn2u · 2025-06-24T11:59:47Z

확인했습니다. 전반적으로 CI/CD 파이프라인 구성을 잘해주셨네요~ 저는 현재 코드로 머지해도 괜찮다고 생각합니다! 수고하셨어요! [요청]

하나의 이슈에 대해서만 PR 만들어주시는걸 부탁드려요. 작업을 하다보면 섞이는 일들이 있을 수 있는데 리뷰하는 입장에서는 이슈 하나만 있는게 PR을 볼때 편합니다.

브랜치 만들때 refactor/#133_jwt알고리즘(refactor/#이슈번호_이슈설명 ) 과 같이 만들어주세요.fetch시 용이성을 위해서 입니다.

그러면 이렇게 두 개의 이슈가 연관이 있어서 하나의 PR로 처리하는 방법이 더 적절하다고 생각하면 이슈들을 정리하고 다시 만들면 될까요?

이번 PR만 이렇게 하고, 다음번 부터 하나의 PR로 처리해도 될것 같아요! 긍정적으로 생각해주셔서 감사합니다 :)

아유 아닙니다~ 리뷰 꼼꼼히 해주셔서 오히려 제가 더 감사하죠~

JjungminLee · 2025-06-24T12:04:52Z

지웅님 해당 PR 머지해주시면 될것 같아요! 수고하셨어요!

jayn2u added 3 commits June 23, 2025 22:45

feat: 애플리케이션 환경 설정 파일 추가 및 .gitignore 수정

efb85cd

- application-dev.yml, application-local.yml, application-prod.yml, application-test.yml 파일 추가 - .gitignore에서 애플리케이션 파일 관련 항목 제거

feat: Swagger UI 경로 수정

ab2fd95

- Swagger UI의 경로를 "/swagger-ui.html"로 변경하여 리소스 접근을 개선함.

jayn2u self-assigned this Jun 24, 2025

jayn2u added the refactoring 리팩토링 label Jun 24, 2025

jayn2u changed the title ~~Refactor/133+134~~ refactor: application 추적에 다른 CICD 파이프라인 수정 & JWT 토큰 개별화로 클라이언트 접근 방지 Jun 24, 2025

jayn2u commented Jun 24, 2025

View reviewed changes

jayn2u requested review from JjungminLee and Copilot June 24, 2025 02:07

This comment was marked as outdated.

Sign in to view

jayn2u added 2 commits June 24, 2025 11:12

JjungminLee approved these changes Jun 24, 2025

View reviewed changes

jayn2u requested review from JjungminLee and Copilot and removed request for Copilot June 24, 2025 11:52

Copilot AI reviewed Jun 24, 2025

View reviewed changes

JjungminLee approved these changes Jun 24, 2025

View reviewed changes

jayn2u merged commit e619c3e into develop Jun 24, 2025
1 check passed

jayn2u deleted the refactor/133+134 branch June 24, 2025 12:41

refactor: application 추적에 다른 CICD 파이프라인 수정 & JWT 토큰 개별화로 클라이언트 접근 방지 #163

refactor: application 추적에 다른 CICD 파이프라인 수정 & JWT 토큰 개별화로 클라이언트 접근 방지 #163

Uh oh!

Conversation

jayn2u commented Jun 24, 2025 • edited by JjungminLee Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

#️⃣ Issue Number

📝 요약(Summary)

💬 공유사항 to 리뷰어

✅ PR Checklist

Uh oh!

jayn2u Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

jayn2u Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

jayn2u Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

JjungminLee Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jayn2u Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

JjungminLee Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

jayn2u Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

jayn2u commented Jun 24, 2025

Uh oh!

jayn2u commented Jun 24, 2025

Uh oh!

JjungminLee left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jayn2u commented Jun 24, 2025

Uh oh!

JjungminLee commented Jun 24, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

JjungminLee commented Jun 24, 2025

Uh oh!

jayn2u commented Jun 24, 2025

Uh oh!

jayn2u commented Jun 24, 2025

Uh oh!

JjungminLee commented Jun 24, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jayn2u commented Jun 24, 2025 •

edited by JjungminLee

Loading

JjungminLee Jun 24, 2025 •

edited

Loading

JjungminLee left a comment •

edited

Loading