Conversation
SPRING_PROFILES_ACTIVE 변경
Batch 작동되게 변경
WalkthroughGitHub Actions 기반 AWS ECS 배포 워크플로우 추가, 컨테이너/런타임 설정 조정, Redis 비밀번호 설정 추가 및 쿼리 정렬 로직의 반환 누락 버그 수정 등 배포·런타임·비즈니스 로직 관련 변경을 포함함. Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub (push)
participant Actions as GitHub Actions
participant AWS as AWS (CLI)
participant ECR as Amazon ECR
participant ECS as Amazon ECS
GH->>Actions: 워크플로우 트리거 (push to main)
Actions->>AWS: AWS 자격증명 설정 (assume-role)
Actions->>ECR: ECR 로그인
Actions->>ECR: Docker 빌드 & 이미지 푸시 (latest)
ECR-->>Actions: 이미지 업로드 완료
Actions->>ECS: 현재 태스크정의 조회 (describe-task-definition)
ECS-->>Actions: task-definition.json
Actions->>Actions: task-definition.json 내 컨테이너 이미지 URI 교체 (jq)
Actions->>AWS: register-task-definition (새 ARN 수신)
Actions->>ECS: update-service (새 태스크정의 적용) and wait-for-stable
ECS-->>Actions: 배포 상태 응답
Actions-->>GH: 워크플로우 완료 상태 보고
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
.github/workflows/deploy.yml (1)
39-45: ✅ AWS 인증 방식은 좋은 보안 관행 (OIDC 사용)Lines 28-33에서 GitHub Secrets 대신 OIDC를 사용한 AWS 인증은 보안 모범 사례입니다.
그러나 Lines 44-45의 Docker 이미지 태깅 방식에 대한 권장사항:
현재:
latest태그만 사용
문제점:
- 배포 이력 추적 불가
- 롤백 시 어느 버전으로 돌아가야 할지 불명확
- 동시 배포 시 이미지 겹침
권장사항:
docker build -t $ECR_REGISTRY/${{ env.ECR_REPOSITORY }}:${{ github.sha }} . docker build -t $ECR_REGISTRY/${{ env.ECR_REPOSITORY }}:latest . docker push $ECR_REGISTRY/${{ env.ECR_REPOSITORY }}:${{ github.sha }} docker push $ECR_REGISTRY/${{ env.ECR_REPOSITORY }}:latestmonew/Dockerfile (1)
25-25: Spring 프로파일 환경 관리 전략 개선 권장검증 결과, 리뷰 의견의 우려사항이 사실입니다:
monew/Dockerfile라인 25의SPRING_PROFILES_ACTIVE=local이.github/workflows/deploy.yml을 통해 AWS ECS 프로덕션 환경에 배포됩니다.현재 상황:
- Dockerfile에서 "local" 프로파일을 하드코딩
- deploy.yml이 이를 프로덕션에 그대로 배포 (프로파일 오버라이드 없음)
- application-local.yml 파일이 없어 현재 실질적 영향은 제한적
- 모든 설정값이 환경변수 사용 (기본값 포함)
권장사항 (선택적 개선):
- 환경별 프로파일 생성:
application-dev.yml,application-prod.yml- Dockerfile 수정:
ENV SPRING_PROFILES_ACTIVE=${SPRING_PROFILES_ACTIVE:-prod}
- deploy.yml에서 프로덕션 배포 시 오버라이드:
docker build --build-arg SPRING_PROFILES_ACTIVE=prod -t ...구성 전략 일관성과 유지보수성 향상을 위해 검토 및 적용을 권장합니다.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/deploy.yml(1 hunks)monew/Dockerfile(1 hunks)monew/src/main/resources/application.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build-and-test
🔇 Additional comments (1)
.github/workflows/deploy.yml (1)
3-6:⚠️ GitHub Actions 트리거 브랜치 불일치Line 3-6에서 workflow는
main브랜치 푸시 시에만 트리거되지만, 이 PR은develop브랜치로 병합될 예정입니다.현재 상황:
- PR: feature/#93 → develop 브랜치 대상
- Workflow: main 브랜치 푸시 시에만 배포
이로 인해 develop 브랜치로 머지되어도 워크플로우가 실행되지 않을 것으로 보입니다.
권장 검토 사항:
- 배포 전략이 명확한지 확인 (develop/staging/main/prod 관계)
- 각 브랜치에 대한 배포 규칙 정의 필요
- 현재 배포 대상 환경(AWS ECS) 확인
| enabled: true | ||
| jdbc: | ||
| initialize-schema: never | ||
| initialize-schema: always |
There was a problem hiding this comment.
🧩 Analysis chain
Line 44에서 batch.jdbc.initialize-schema를 never에서 always로 변경하면, 애플리케이션이 시작될 때마다 스키마가 초기화됩니다. 이는 다음과 같은 문제를 야기할 수 있습니다:
- 배포할 때마다 반복적인 스키마 초기화로 인한 성능 저하
- 프로파일별 설정이 제대로 분리되지 않은 경우 프로덕션에서 예상치 못한 동작 발생 가능
- Dockerfile에서
SPRING_PROFILES_ACTIVE=local로 설정되어 있으므로, 프로덕션 배포 시에도local프로파일이 활성화될 수 있음
권장사항:
- 프로덕션(
prod) 프로파일을 별도로 생성하여initialize-schema: never로 설정 - Dockerfile의 SPRING_PROFILES_ACTIVE를
local에서 환경 변수로 제어 가능하도록 수정 - 데이터베이스 마이그레이션 도구(Flyway/Liquibase) 사용 검토
🏁 Script executed:
#!/bin/bash
# Find all application configuration files
fd 'application.*\.yml' --type f
# Show the main application.yml with context around line 44
echo "=== Main application.yml around line 44 ==="
cat monew/src/main/resources/application.yml | head -60 | tail -25
# Look for Dockerfile
echo "=== Dockerfile content ==="
fd 'Dockerfile' --type f -x cat {}
# Look for deployment configuration
echo "=== Deployment configuration files ==="
fd 'deploy' --type f | grep -E '\.(yml|yaml|sh)$'Length of output: 1238
🏁 Script executed:
#!/bin/bash
# View full application.yml to see profile setup
echo "=== Full application.yml ==="
cat monew/src/main/resources/application.yml
echo -e "\n=== Check for profile-specific configs ==="
fd 'application-' --type f
echo -e "\n=== Search all YAML files for profile configuration ==="
fd '\.(yml|yaml)$' --type f | head -20
echo -e "\n=== Look for docker-compose or k8s configs ==="
fd -E 'node_modules' -E '.git' '(docker-compose|kubernetes|k8s|kube)' --type f
echo -e "\n=== Check for migration files (Flyway/Liquibase) ==="
fd '(db/migration|liquibase)' --type fLength of output: 2892
🏁 Script executed:
#!/bin/bash
# Check docker-compose configuration
echo "=== docker-compose.yml ==="
cat monew/docker-compose.yml
echo -e "\n=== Look for deployment or production scripts ==="
fd '\.(sh|bash)$' --type f | grep -iE '(deploy|prod|start|run)' | head -10
echo -e "\n=== Check for GitHub Actions or CI/CD config ==="
fd -E 'node_modules' -E '.git' '(github|gitlab|workflow|ci)' --type d
echo -e "\n=== Look for gradle or maven configuration that sets profiles ==="
cat build.gradle | grep -iE '(profile|spring|active)' -A 2 -B 2 || echo "No profile config in build.gradle"Length of output: 2930
배치 스키마 초기화 설정 수정 필요
batch.jdbc.initialize-schema: always 설정이 애플리케이션 설정과 docker-compose.yml에 명시되어 있어서, 컨테이너가 시작될 때마다 배치 스키마(테이블)가 삭제되고 다시 생성됩니다. 이는 다음 문제를 야기합니다:
- 애플리케이션 재시작 시 배치 실행 기록 손실
- 진행 중인 배치 작업 중단 가능성
- 배포 간 배치 메타데이터 미보존
필수 개선사항:
- docker-compose.yml에서
SPRING_BATCH_JDBC_INITIALIZE_SCHEMA: always제거 - application.yml의
initialize-schema: always를never로 변경 - Flyway 또는 Liquibase를 통한 데이터베이스 스키마 관리로 전환
- 프로덕션 환경 프로필(application-prod.yml) 생성하여
initialize-schema: never설정
🤖 Prompt for AI Agents
In monew/src/main/resources/application.yml around line 44, the batch JDBC
schema is set to "always" which causes tables to be dropped/recreated on
container start; change this to "never" to preserve batch metadata, remove
SPRING_BATCH_JDBC_INITIALIZE_SCHEMA: always from docker-compose.yml (so
containers don't force reinitialize), add a production profile file
monew/src/main/resources/application-prod.yml containing initialize-schema:
never, and migrate schema management to a proper tool (Flyway or Liquibase) with
migrations applied during deploy rather than relying on Spring Batch
initialize-schema.
There was a problem hiding this comment.
docker-compose.yml에서 SPRING_BATCH_JDBC_INITIALIZE_SCHEMA: always 제거
여기를 제거 안해서 그런거 같은데 docker-compose는 편의성을 위해서 그렇게 해놔서 신경 안쓰셔도 될것 같습니다.
There was a problem hiding this comment.
@Namsoo315, docker-compose.yml이 로컬 개발 환경을 위한 것이라는 점 명확히 해주셔서 감사합니다!
알려주신 대로 docker-compose.yml의 설정은 개발 편의성을 위한 것이니 문제없습니다. 다만 application.yml(Line 44)의 initialize-schema: always 변경은 기본 프로파일 설정이라서, 프로덕션 배포 시에도 영향을 줄 수 있습니다.
혹시 프로덕션 환경에서는 다른 프로파일(예: application-prod.yml)을 사용하시거나, 환경 변수로 이 설정을 오버라이드하실 계획이신가요? 그렇다면 전혀 문제없을 것 같습니다! 👍
✏️ Learnings added
Learnt from: Namsoo315
Repo: codeit-monew/sb05-monew-team7 PR: 95
File: monew/src/main/resources/application.yml:0-0
Timestamp: 2025-11-11T10:45:48.445Z
Learning: In the codeit-monew/sb05-monew-team7 repository, docker-compose.yml is used for local development convenience, and its Spring Batch schema initialization settings (SPRING_BATCH_JDBC_INITIALIZE_SCHEMA: always) are intentional for the development environment.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
monew/docker-compose.yml (1)
85-89: 리소스 예약(reservations) 추가를 권장합니다.limits만 설정하고 reservations를 설정하지 않으면, 시스템 부하가 높을 때 앱 컨테이너가 필요한 최소 리소스를 보장받지 못할 수 있습니다. postgres 서비스(lines 26-28)와 동일하게 reservations를 추가하여 일관성을 유지하고 안정적인 리소스 할당을 보장하세요.
다음 diff를 적용하여 reservations를 추가하세요:
deploy: resources: limits: cpus: "2.0" memory: 4g + reservations: + cpus: "1.0" + memory: 2gmonew/src/main/resources/application.yml (1)
36-36: Redis 비밀번호에 기본값 추가를 고려하세요.
SPRING_DATA_REDIS_PASSWORD환경 변수가 설정되지 않으면 애플리케이션이 시작되지 않을 수 있습니다. 다른 Redis 설정(host, port)과 일관성을 유지하고 개발 환경에서의 안정성을 위해 기본값을 추가하는 것을 권장합니다.다음 diff를 적용하여 빈 문자열을 기본값으로 설정하세요(비밀번호 없는 Redis 허용):
- password: ${SPRING_DATA_REDIS_PASSWORD} + password: ${SPRING_DATA_REDIS_PASSWORD:}또는 docker-compose.yml의 Redis 비밀번호와 일치하는 기본값을 설정하세요:
- password: ${SPRING_DATA_REDIS_PASSWORD} + password: ${SPRING_DATA_REDIS_PASSWORD:redis-password}
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/deploy.yml(1 hunks)monew/docker-compose.yml(1 hunks)monew/src/main/java/com/spring/monew/interest/repository/impl/InterestRepositoryCustomImpl.java(1 hunks)monew/src/main/resources/application.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/deploy.yml
🔇 Additional comments (1)
monew/src/main/java/com/spring/monew/interest/repository/impl/InterestRepositoryCustomImpl.java (1)
169-175: 버그 수정이 정상적으로 적용되었습니다.
subscriberCount정렬 요청 시OrderSpecifier가 이제 올바르게 반환됩니다. 이전에는if문 내에서 생성되지만 반환되지 않아 항상name으로 정렬되던 버그가, line 172에 추가된return문으로 수정되었습니다. 메서드 호출처(line 56)에서 정렬이 정상 동작합니다.
1 participant
Issues
✔️ Check-list
🗒️ Work Description
실제 배포도 끝 CI/CD도 구현됨
📷 Screenshot
EC2 구성 [DB 서버, 모니터링 서버, ECS 클러스터 인스턴스]
S3 구성
ECR, ECS 환경 구성
ECR은 프라이빗 리포지토리로 구성하였고 latest로 연결하면 CD가 Task에 올라감.
ECS는 서비스로 구성하여 CD까지 연동 끝남.
📚 Reference
Summary by CodeRabbit
릴리스 노트
Chores
Bug Fixes