ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [SAP 시험관리] 프로젝트 DEV 서버 구축일기.
    학습/프로젝트 2024. 4. 24. 08:36

    프로젝트 구축 회고: 팀 작업과 기술 선택의 중요성

    프로젝트 개요

    프로젝트는 테스트 응시자 관리 시스템을 개발

    응시자의 계정 발급, 시험 성적 관리, 시험 문제 관리 등 백오피스 개발

    팀 구성과 역할

    • 퍼블리셔: UI 구현
    • 프론트엔드 개발자: React를 사용한 클라이언트 사이드 로직 구현
    • 백엔드 개발자 (나): 서버 사이드 로직 및 데이터베이스 관리

    기술스택

    • 프론트엔드: React(프론트엔드)
    • 백엔드: Spring Boot 3, Mybatis
    • DB: MySQL

    기술 선택 이유

    • 프론트엔드: 팀원 중 React에 능숙한 개발자가 있어 선택.
    • 백엔드: 복잡한 도메인 로직 관리가 필요 없어 JPA 대신 MyBatis 선택.
    • JWT 토큰: 시스템 간 통신과 인증에 JWT를 사용하여 보안 강화.
    • 기술 스택 축소: 초기에는 Redis와 Nginx를 고려했으나, 서버 용량 및 간소화를 위해 배제

    서버 구조 및 배포 전략

    초기 계획: Nginx, React, Spring Boot 3개의 서버와 Redis, Mysql 2개의 DB 운용

    상용: 서버 용량의 제약으로 인해 React 애플리케이션을 Spring Boot 내부에 포함시켜 배포하는 방식으로 전환

    더보기

    위 과정에서 반복되는 작업을 찾을 수 있었다.

     2.1 git pull 

     2.2 react 폴더 이동 (/frontend)

     2.3 react npm build ( npm run build)

     2.4 기존 static 삭제 ( ../src/main/resource/static/* )

     2.5 빌드파일 이동 ( mv .. .. )

     2.6 java version 충돌로 인한 자바 설정 ( export JAVA_HOME=/dir/java/jdk21/Contents/Home )

     2.7 spring boot build ( ../gradlew bootJar )

     2.8 깃으로 커밋 배포 (git add . -> git commit -m " [Auto build] react build and spring boot" -> git push)

     

    프로젝트 재실행

    배포는 끝났는데...

    이걸 scp로 파일을 전송해야되나.. 깃 훅을 사용해야되나 하다가 일단 ec2에서 직접접근해 쉘스크립트를 작성해서 사용하기로 했다.

     

    1. 기존 프로젝트 kill (build.jar kill ( ps HEAD^1 -> kill ))

    2. git pull

    3. 프로젝트 재실행 ( sudo nohup java -jar ./build.jar & ) 

     

    회고

    jenkins를 사용하다는게 너무 편하다는 걸 느꼇고, 좀 더 dev서버 간소화하는 방법을 고민해야겠다.

    인증과 인가

    Spring Boot 내의 인터셉터로 처리

    Security를 사용하기에는 Security에서 제공하는 기능이 부담스러워 제거하였으며, Spring내 interceptor로 처리

    협업 과정

    나와 프론트엔드 개발자 모두 본업을 하고 있어서 모든 작업에 대해 컨택하기가 힘든 상황

    따라서 외주담당자, 프론트엔드 개발자, 백엔드 개발자 (나) 세명이서 기획협의를 zoom으로 3차례 진행하였고, 해당 내용을 PPT로 만들어 구글드라이브로 공유하였고, 프로토타입(알파버전)을 만들어 사용하면서 수정사항을 반영하기로 협의

    회고 및 배운 점

    • 기술 선택의 중요성: JPA, Spring Security에 너무 신경안썼으면 좋겠다. 최근 JPA, JWT, Spring Security에 대해 많은 질문이 들어왔지만, 나도 무분별하게 위의 기능을 사용했던 것 같다. 이번 최소사양의 서버를 사용하게 되면서 불필요한 기능을 삭제하다 보니 통신시 필요한 내용을 이해하는게 핵심 기술을 사용하는 것 보다 우선이라는 생각이 들었다.
    • 팀워크와 커뮤니케이션: 문서화와 반복적인 작업은 자동화하며, 받아드리는 자세로 커뮤니케이션 한다면 개발이 실패하는 부분은 없다고 생각한다.
    • 코드리뷰: 코드리뷰가 없었던 점이 아쉽다. 정규화되지 않은 API들이 많이 배포되어 이번 프로젝트를 유지보수하며 다듬을 생각이다.

     

    댓글

Designed by Tistory.