일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Spring Cloud Gateway
- netty
- Invalid property 'principal.username' of bean class
- interface
- S3
- springsecurity
- jpa
- 낙관적 락 롤백
- kotest testcontainers
- ObjectOptimisticLockingFailureException
- 소수찾기 java
- 낙관적 락 재시도
- RefreshToken
- ObjectOptimisticLockingFailureException 처리
- OptimisticLock
- spring aop
- redissonlock aop
- java
- AccessToken
- 알고리즘
- multimodule testcontainers
- TestContainers
- 백준
- DI
- aop
- 멀티모듈 테스트컨테이너
- @transactional
- 우아한 테크러닝
- spring DI
- 형상관리
- Today
- Total
목록분류 전체보기 (66)
조급하면 모래성이 될뿐
현재 프로젝트에서는 RDS를 mariadb로 구성하여 사용하고 있다. 이를 위해 mariadb 테스트 컨테이너 환경을 구축했다. 또한 테스트 라이브러리로는 kotest를 사용하고 있다. 1. 테스트 컨테이너 의존성 추가. build.gradle.kts testImplementation("org.testcontainers:testcontainers:$testContainerVersion") testImplementation("org.testcontainers:junit-jupiter:$testContainerVersion") testImplementation("org.testcontainers:mariadb:$testContainerVersion") 2. mariadb 테스트 컨테이너 설정 TestCont..
Why? 테스트 코드를 작성하고, 프로젝트를 완성해 나가면서 항상 테스트 환경에 대한 고민을 하게 되었다. 대표적으로 Repository는 어디를 붙어야 할지.. 또 특정 서버와 연결을 해두었다면 (test 서버), 해당 DB의 데이터를 비워주거나 누적되지 않게 따로 관리를 해야 할지... -> 멱등성이 깨지는 것에 대해 계속 신경이 쓰였다. in-memory DB를 사용해도 좋지만, 이 경우 운영환경에서 예상하지 못한 예외가 발생할 수 있다. 지난 프로젝트에서는 H2 DB로 테스트를 하다가 운영배포를 할 때 예약어로 인한 문제가 발생했다. (user, row, column) - MySQL 예약어 목록 때문에 운영환경과 최대한 유사하게 테스트 환경을 구축하고자 했다. 처음에는 Docker-Compose를..
Why? 프로젝트를 하며 배포 과정에서 아래와 같이 이미 존재하는 포트를 띄우는 상황이 종종 발생했고, 그때마다 서버가 죽어버렸다. 서버가 죽게 되면 프런트팀에서 슬랙을 통해 요청했고, 그때마다 서버에 접속해서 다시 애플리케이션을 구동시켰다. 이런 경우를 최소화하고자 무중단 배포를 적용했다. How? AWS CodeDeploy를 사용했기 때문에 블루 그린 무중단 배포를 적용하는 방식 이 경우는 ec2를 여러 개 생성해서 사용한다고 이해했다. 현재 프로젝트에서는 조금 오버스럽다고 느껴서 다른 방식을 선택했다. Nginx를 통한 무중단 배포 - 이걸로 적용함 2개의 애플리케이션을 실행한 후(8080, 8081), Nginx를 통해 포워딩한다. 포워딩 규칙은 현재 Nginx가 8080 포트를 바라보고 있다면,..