gitaction으로 ci/cd하기
스프링 프로젝트 Github action으로 CI 자동화하기 에서 CI자동화를 완성했는데, 이후 aws ec2로 배포하면서, 배포까지 자동화하였다. aws 자동화에 매우 다양한 방법이
스프링 프로젝트 Github action으로 CI 자동화하기 에서 CI자동화를 완성했는데, 이후 aws ec2로 배포하면서, 배포까지 자동화하였다. aws 자동화에 매우 다양한 방법이
온라인 도서관 프로젝트에서, 현재로서는 책 커버이미지(BookCover)는 book당 1개밖에 갖지 못한다. 그런데, test에서 실패하는데 그 이유를 보니 findByBookId로 찾은 요소가 db에서
CI(Continuous Integration, 지속적인 통합)란, 개발자가 코드 변경 사항을 커밋할 때마다 자동으로 빌드, 테스트 등을 실행하여 코드의 안정성과 통합성을 검증하는 단계
온라인 도서관 프로젝트에서 기능을 하나씩 확장할 때마다, 기능을 추가 하고 나서 천천히 사이트를 살펴볼 때, 갑자기 다른 곳 기능이 작동하지
db에서 삭제 실패 해도 파일 시스템에서는 삭제 성공?! 이 코드의 문제는 뭘까? Optional을 findById에서 반환받아서 uploadFile 객체를 반환받았을 경우에만 fileStore에서
JdbcTemplate을 사용하다가 Mybatis를 사용하니 편리하기는 한데, Repository에 사용되는 메서드와 중복되는 것이 많아서, 단순 위임하는 케이스가 많아서 좀 비효율적으로 느껴졌다. 기능상
페이지네이션은 구현하기 어렵다. 간단해보이는 기능인 페이지네이션은, 사실은 구현하기 어려운 기능이다. 등 여러가지로 복잡한 기능이다. 하지만, Spring Data에서는 Pageable, Page와 같은
지금은 조금 코드가 변경됐지만, 기존에 도메인 중심 설계를 위해 간단히 필드를 업데이트 하는 코드는 도메인 모델에 넣어두었다. 그런데, DB를 적용하자
RestApi로 파일 전송하기에서는 BeanValidation을 사용할 수 없다. 라고 이야기 했던 적이 있다. RequestBody 애노테이션은 @ModelAttribute처럼 MultipartFile까지 묶여 오지 않기 때문인데,
Validation 적용 회고에서 다양하게 Validation을 적용했었는데, 주요한 포인트는, 간단한 것은 BeanValidation으로, 복잡한 것은 Validator 구현으로 하자였다. 그런데, 작업하다보니 복잡한 경우,