조급하면 모래성이 될뿐

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 포트를 바라보고 있다면,..

Why? 배포 환경을 구축하다 보니 환경 구성도 분리해야 했다. 그 과정에서 dev환경(aws)의 접속 정보 또한 github에 올려야 했다. 사실 로컬에 대한 접속 정보도 올릴 때마다 찝찝했다.. 그리고 이번에 직접 RDS에 구성한 DB에 접속하기 위한 정보를 push를 해야 하는데.. 이건 아니다 싶었다. How? 이것도 여러 가지 방법이 있었다. 암호화, 서브모듈 운영체제 환경변수 암호화는 복호화 과정에서 필요한 key를 계속 관리해야 한다는 게.. 마음에 들지 않았다. 또 OS환경변수는 뭔가 너무 간단(?)했다. 그래서 서브모듈을 써봤다. 서브모듈을 통해 application-dev.yml 파일을 관리했다. 서브모듈? 쉽게 private repository를 만들고 거기에 중요한 파일을 올린다. ..

Why? 팀 프로젝트를 하면서 애플리케이션 코드에 문서화를 위한 코드를 추가하는 것이 마음에 들지 않아 RestDocs를 선택했다. 하지만 RestDocs는 별로이쁘지 않았고, Swagger처럼 바로 호출할 수 없다는 단점이 있었다. Need? plugins { // api-spec 플러그인 추가 id 'com.epages.restdocs-api-spec' version '0.16.0' } dependencies { // api-spec 의존성 추가 testImplementation 'com.epages:restdocs-api-spec-mockmvc:0.16.0' } // openapi3 task 추가, 문서화 할 때 아래 정보를 참조해서 만들어진다. openapi3 { server = 'http://3..

Why? 처음 프런트팀과 협업을 하기 전 완료된 API를 실시간으로 공유하고 싶었다. 완료된 API를 프론트에서도 바로 호출해볼 수 있으면 문제도 더 빨리 잡을 수 있고, 서로 생산성도 높일 수 있다고 생각했다. HOW? CI는 GithubActions를 사용했고, CD방식은 크게 2가지 중에 고민했다. 1. Docker 이미지를 만들고, EC2에서 이미지를 받아와서 실행. 2. S3에 Jar파일을 올리고, AWS의 CodeDeploy를 통해 배포한다. 결과적으로 2번을 선택했다. 두 방식의 장, 단점을 찾아보았을 때 모두 하지 마라!.. 또는 이건 쓰면 안 된다! 이런 내용은 딱히 못 찾았고, Docker에 익숙하지 않았기 때문에 2번을 선택했다. 간단하게 찾아보았을 때 1번 방식은 별도의 메모리 공간..