이 작업일지는, 기술적인 부분보다는 특정 결과를 얻는데 까지 겪은 과정과, 고민의 흔적을 남기고자 쓴 글입니다. 따라서, 기술적인 부분에 대해서는 다소 내용이 추상적일 수 있습니다. 이번에는 저번 일지에서도 언급했듯이, 배포 프로세스를 익혀보고, 익혀본 프로세스를 자동화하는 과정을 가져보았다. 배포 자동화를 하기 위해 github action을 사용해보았다. jenkins와 같은 ci툴을 활용하지 않은 이유는, 따로 ci 서버를 운영하는 것이 취준생으로서는 조금 부담스러웠고, jenkins의 사용법보다는 자동화 프로세스에 대한 나의 논리를 확립시키는 것에 더 집중하고 싶었다. 배포 자동화는커녕, 배포 자체를 스스로 해본 적이 없었기 때문에, 이번 작업은 점진적인 반복과 스스로에게 질문을 하고 그 질문의 ..

프로젝트의 완성도는 아직 많이 부족하지만, 우선은 배포를 진행 해보기로 했다. 부족한 부분은 배포를 한 후에도 계속 적용이 가능하고, 오히려 완성이 덜된 상태에서 배포를 하고, 수정을 하는 과정에서 CI/CD를 구축하고 통합 및 배포의 자동화가 제대로 적용되는지 확인할 수 있는 요소가 될 수 있으니, 우선은 배포 환경을 구성하는 쪽으로 진행해볼까 한다. 따라서, 현 시점에서는 도메인 서비스 구현을 멈추고, 대략적으로 마무리를 하고자 한다. 먼저 마무리 되어야하는 부분은 예외처리를 에러 메세지로 연결하는 작업일 듯 하다. SpringMVC에서는 기본적으로 예외가 발생하면, 자동으로 메세지를 처리해준다. 이 기능만 놓고보면, 개발자는 그냥 맘편히 비즈니스 로직을 짜며, 예외처리를 하기만 하면, 다 될 듯 하..

한 동안 작업일지를 작성하지 못했다. 기존 팀원이 이탈하고, 이제 혼자서 프로젝트를 마무리하는 상황이 생겨, 일정에 차질이 생겼기 때문이다. 우선은 팀원이 구현하지 못한 부분인 주문, 장바구니 도메인을 구현을 내가 맡아서 해야하는 것도 있지만, 정해진 일정 내에 마무리를 하기 위해선, 우선 프로젝트를 축소 시켜야할 필요가 있어 보인다. 축소를 한 방향은 다음과 같다. 서비스의 성격이 달라도, 구현하는 방향이 같다면, 우선 보류한다. 예를 들자면, 일반 사용자의 상품 검색 및 주문, 관리자의 상품 검색 및 재고 관리를 비교해보면, 서로 서비스의 성격이 다르지만, 결국 두 기능 모두, 상품을 검색하고, 상품의 재고를 확인하는 작업을 거친다. 이 경우에는 구현을 하면서 좀 더 고민을 많이 할 것 같은 &#39..

개요 저번 일지에서는 테스트의 종류를 살펴보았다. 이번 일지에서는 기존의 테스트 코드를 살펴보고, 그 테스트 코드의 문제점을 파악하고, 개선하는 작업을 기록해보겠다. 분석 우선 현재 작성된 테스트 코드부터 살펴보자. @SpringBootTest @TestMethodOrder(MethodOrderer.OrderAnnotation.class) class ItemRestControllerTest { @Autowired private MockMvc mockMvc; @Autowired private ObjectMapper objectMapper; @Autowired private ItemService itemService; @Autowired private CategoryService categoryService..

개요 그동안, 프로젝트를 진행하면서, 테스트는 그저 서비스 로직이 스프링 컨테이너 안에서 제대로 작동하고 있는지를 확인하는 수단으로 생각했다. 물론, 테스트 코드가 많으면 많을수록, 서비스 로직의 안정성을 보장하는 안전장치가 더 탄탄해진다는 뜻이기도 하니, 작업자의 심신을 안정시키는 데에는 큰 기여를 해준다고 볼 수 있다. 하지만 한가지 문제가 발생했다. 바로 빌드시간이 증가하고 있다는 것이다. 이번 게시글에서는 이 빌드 시간이 증가하고 있는 원인을 찾고, 개선하는 과정을 정리하고자 한다. INDEX 현상 파악 원인 파악 테스트의 종류와 툴의 종류 현상파악 우선 가장 먼저해야할 내가 인식한 문제가 정말로 발생하고 있는 문제인지를 검증해야한다. 검증하는 방법들 중 가장 간단한 방법으로는 빌드 기록을 살펴보..

개요 지금까지는 인증 로직에 보안이 왜 필요한지, 그리고 인증의 종류와 로직의 흐름과 스프링 시큐리티의 구조를 간략하게 알아보았다. 이번에는 내가 설계했던 로그인, 회원가입, 리소스 접근 통제 관련 로직의 흐름을 스프링 시큐리티로 적용해보도록 하겠다. INDEX 로그인 회원가입 인증 리소스 접근 로그인 저번 작업일지에서 Security가 필요한 서비스의 로직의 플로우 차트를 간단하게 정리한 적이 있었다. 그 중에서 로그인과 관련된 플로우 차트는 다음과 같았다. 로직의 흐름을 간략하게 설명해보면, 최초 로그인시 아이디/비밀번호를 입력 받으면, 해당 회원 정보가 있는지, 조회하고, 없으면 예외를 던지고, 있으면, 입력한 비밀번호가 저장된 회원의 비밀번호가 일치한지 확인한다. 비밀번호 검증이 이상없이 완료되면..