엔지니어로 가는 길

Spring boot 버전을 올려보자 Spring boot 2.0을 사용 중인 프로젝트의 버전을 최신 버전으로 올려보려고 한다. 간단한 일은 아니겠지만 불가능한 일도 아니다. 수많은 문제를 끊임없이 만나게 될 텐데, 문제를 만나서 해결하거 live-everyday.tistory.com 담당하고 있는 프로젝트의 Spring Boot 버전을 2.0.1에서 2.7.6까지 올렸다. 위 글에서 Spring Boot 버전을 올려보고 싶다고 말하기는 했으나 이렇게 생각보다 빠르게 마무리될 줄은 몰랐다. 이 글에서는 Spring Boot 버전업 과정에서 만난 이슈를 정리하려고 한다. (버전을 올림에 따라 발생할 수 있는 모든 이슈가 아닌, 회사 프로젝트에서 발생한 이슈만 정리하였다.) 2.1.18 -> 2.2.13 A..

* 한 두 달 전쯤 진행했던 업무 빌드 타임 30분 담당하고 있는 서비스에서 의존성을 추가하거나 수정할 때마다 30분이 소요됐다. 처음엔 '원래 그런가 보다' 하고 넘어갔는데, 해당 서비스에 대해 알게 될수록 30분은 너무 과하다는 생각이 들었다. 의존성을 하나 추가하거나 수정하는 아주 간단한 수정이었고, 프로젝트도 그렇게 거대하고 복잡하지 않은 데 너무 오랜 시간이 걸린다고 생각했다. 그러던 차에 의존성을 수정할 일이 있는 업무를 맡게 되었고, 빌드 타임부터 개선해보기로 했다. 원인이 뭘까 해당 서비스는 gradle 멀티 모듈 프로젝트였고, gradle 버전은 4.X였다. 처음에는 build.gradle 파일을 보며 빌드 타임이 느린 원인을 몇 가지 추측해보았다. - deprecated 저장소 - 불필..

여유롭지 않으므로 의식의 흐름대로 작성하고 나중에 수정하기로 한다. 사용자에게 알려야 하는 특정 이벤트가 발생하면 문자, 알림톡, 앱 push 등의 수단을 이용하여 사용자에게 해당 이벤트가 발생했음을 비동기적으로 알린다. 사용자에게 알림을 보낼 때 관련 알림 서비스의 이슈로 인해 알림을 보내는 데 실패할 수 있다. 예를 들면, 특정 클라우드의 문자 발송 서비스를 이용하고 있을 경우 우리 서비스가 아닌 해당 클라우드와 관련한 이슈로 인해 알림을 발송하는 데 실패할 수 있다. 이러한 예외는 얼마든 발생할 수 있고, 재발송을 시도하면 되기 때문에 예외에 대한 처리도 명확하다. 또한 알림은 핵심 로직이 아니기 때문에 알림이 실패했다고 해서 이후에 있는 작업이 진행되지 않는 것도 적절하지 않다. 이러한 이유로 알..

Spring boot 2.0을 사용 중인 프로젝트의 버전을 최신 버전으로 올려보려고 한다. 간단한 일은 아니겠지만 불가능한 일도 아니다. 수많은 문제를 끊임없이 만나게 될 텐데, 문제를 만나서 해결하거나 또는 해결하지 못했다면 왜 해결하지 못했는지, 어디서 막혔는지를 잘 정리할 것이다. 최신 버전의 Spring boot를 사용하게 된다는 것은 결과이다. 어쩔 수 없는 이유로 당장 최신 버전을 사용하지 못할 수도 있다. 결과는 어쩔 수 없는 영역인데, 결과에 너무 집중하면 원하는 결과가 나오지 않았을 때 실망하게 된다. 이 일을 할 때는 Spring boot의 버전별 차이와 빌드툴에 대해 배우는 것을 목적으로 접근하려고 한다. 최신 버전을 사용할 수 있게 된다면 좋은 일이고, 그렇게 되지 않더라도 어디서 ..

기존 프로젝트에서 사용하고 있던 라이브러리나 프레임워크의 버전을 바꾸는 것은 간단한 일이 아니다. 하지만 JUnit5로 마이그레이션 하는 것은 예외인 것 같다. JUnit 4와 JUnit 5는 함께일 수 있다 https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 JUnit 5 User Guide Although the JUnit Jupiter programming model and extension model do not support JUnit 4 features such as Rules and Runners natively, it is not expected that source code maintainers will need..