이전에 회사에서 githubActions 를 도입해본 경험이 있지만 PR 이전에 Integration 작업 도입해 본 적이 없다. 마침 스프링으로 사이드 프로젝트를 만들어보면서 테스트 코드를 작성해보고 있기 때문에 PR 이전에 테스트 코드가 모두 통과하도록 하는 CI를 만들어 보도록 하겠다. 여러 CI/CD 툴이 있겠지만 GitHubActions를 선택하였다. 현재 레포를 github에 포스팅하고 있기 때문에 연동하기 쉽고, 사용 방법이 간단하다는 장점이 있기 때문이다. 결국 CI/CD 툴도 컴퓨팅 리소스가 필요한데. 다른 툴을 도입하려면 컴퓨팅 리소스를 자체적으로 마련해야 하지만 githubActions는 컴퓨팅 리소스를 따로 마련하지 않고 무료로 사용할 수 있다는 점도 장점이다.

문제 상황 downloadFile 기능을 테스트 코드로 작성하던 중 테스트를 위한 임시 파일 생성과 다운로드 기능에서 계속된 에러가 발생했다. 임시 파일 생성하고 해당 파일을 다운로드 받아야 하는데. 생성된 파일 경로를 읽어 오지 못했기 때문이다. 테스트하기 어려운 구조로 짜여져있다는 것을 깨닫고 고칠려고 했다. 그러다보니 해당 테스트는 메타 데이터에 관한 테스트인데. 실제 파일 생성과 다운로드를 테스트 과정에 집어넣는 것이 잘못된 것이라고 깨닫고 분리하려고 했다. 요약하자면 테스트하기 어려운 구조로 변경하려다가 서비스 레이어 코드에서 분리가 필요하다고 느꼈다.

문제 상황 Controller 테스트 코드 작성시에 성공과 실패 코드 짜는 중에 서비스 레이어에서 단순히 String 타입으로 리턴하기 때문에 비정상적인 결과를 표기할 수 없었다. 테스트 코드 @Test public void testUpload() throws Exception{ MockMultipartFile file = new MockMultipartFile( "file", "hello.txt", MediaType.TEXT_PLAIN_VALUE, "Hello, World!".getBytes() ); when(metaDataService.uploadFile(file, "test")).thenReturn("File uploaded successfully"); mockMvc.perform( multipart("/file/upload").file(file) .param("user", "test") ).andExpect(status().isOk()) .andExpect(content().string("File uploaded successfully")); } 이전 Controller 코드 if (file.isEmpty()) { return ResponseEntity.badRequest().body("Please select a file to upload"); } String body = metaDataService.

#multithread #java #JVM 본 글은 자바 웹 프로그래밍 Next Step를 읽으면 마주한 문제에 대해서 다룹니다. (책 추천합니다!) 문제 상황 서블릿 컨테이너에 의해서 Controller 인스턴스는 하나만 생성된다. 그러나 멀티 스레딩 환경에서 여러 스레드가 하나 컨트롤러에 진입하면 문제가 생길 수 있다. 아래 코드를 보자. 눈 여겨볼 지점은 3~4번째 줄에서 question, answers 변수이다. 해당 변수는 인스턴스 변수로 여러 스레드가 해당 변수를 공유할 수 있다. 자세한 설명을 하기 위해서 JVM 메모리 구조에 대해서 알아보자

이 글은 “자바 웹 프로그래밍 NextStep” 을 참고하였습니다. 세션이란? 세션의 필요성 HTTP는 무상태 프로토콜이다. 클라이언트와 서버 사이 상태를 유지할 수 없다. 클라이언트와 서버 사이 통신 맥락을 모두 공유할 수 없다는 뜻이다. 만약 클라이언트가 로그인을 성공하더라도 서버는 클라이언트가 로그인을 성공한 것인지 알 수 없다. 이 때문에 유저별 권한이 설정된 웹 사이트라면 매번 인증을 통해서 클라이언트가 원하는 동작을 수행해야 한다. 이러한 비효율을 줄이고자 세션과 같은 서버가 클라이언트를 식별할 장치가 필요하다. 세션 기본 구조 쿠키를 사용하는 이유?

CV를 업로드하면 기술 인터뷰를 연습해 볼 수 있는 프로젝트 에 합류하게 되었다. 이미 백엔드 서버가 구성되어 있었기 때문에 퍼블릭 레포로 변경하면서 필요한 작업과 자동 배포 위주로 기여하였다. 기존 문제 보안 이슈 : 퍼블릭 레포로 변경하면서 하드 코딩되어 있는 보안 키 노출 자동 배포 : AWS EC2에 SSH로 접근하여 수동 배포 기존 문제를 정의해보면 위와 같았다. 문제해결 방향 보안 이슈 노출되면 안될 보안키를 .env파일로 옮겨두고 dotenv 라이브러리로 환경변수를 불러오는 식으로 변경하였다. 레포를 검토하고 보안 이슈가 생길 코드를 이슈로 제보하였다.