해당 글은 DEPth IT 연합 프로젝트 동아리 활동의 일환인 서버 스터디에 관련되어 있습니다.🐧
페이지네이션
페이지네이션이란, 여러 개의 컨텐츠를 여러 페이지로 나누고 페이지 번호 버튼, 이전 버튼, 다음 버튼을 눌러서 페이지를 이동하는 기능입니다. 사용자가 특정 페이지 번호를 클릭했을때 그 페이지에 해당하는 내용만 사용자에게 보여줍니다.
페이지네이션 조건
- 한 페이지에 보여주고자 하는 페이지 버튼의 개수
- 한 페이지에 보여주고자 하는 컨텐츠의 개수
- 이전, 다음 버튼
위 조건 이외에도 처음으로 가는 버튼과 마지막으로 가는 버튼이 추가될 수 있습니다.
이를 그림으로 나타내면 위와 같습니다.
따라서, 페이지네이션에는 총 4개의 값이 필요합니다.
총 페이지 개수, 화면에 보여질 페이지 그룹, 화면에 보여질 첫번째 페이지 번호, 화면에 보여질 마지막 페이지 번호
Spring Data JPA를 사용하면 동적 페이징 쿼리가 쉬워집니다.
- 스프링 데이터 JPA는 쿼리 메소드에 페이징과 정렬 기능을 사용할 수 있도록 2가지 파라미터를 제공합니다.
- org.springframework.data.domain.Sort : 정렬 기능
- org.springframework.data.domain.Pageable : 페이징 기능(내부에 sort 포함)
- Pageable을 사용할 때 반환 타입
- org.springframework.data.domain.Page : 전체 데이터 건수를 조회하는 count 쿼리 결과를 포함하는 페이징
- org.springframework.data.domain.Slice : 추가 count 쿼리 없이 다음 페이지만 확인 가능 (내부적으로 limit + 1조회)
- List (자바 컬렉션): 추가 count 쿼리 없이 결과만 반환
Pageable은 인터페이스이므로 실제로 사용할 때에는 인터페이스를 구현한 PageRequest 객체를 사용합니다. 그렇게 파라미터로 넘기면 반환 타입에 따라 쿼리가 날아가고 totalCount 를 날릴지 안 날릴지도 결정됩니다. 또한 PageRequest 생성자의 파라미터는 현재 페이지, 조회할 데이터 수, 정렬 정보를 파라미터로 사용할 수 있습니다.
이때 현재 머물고 있는 페이지를 쿼리스트링으로 넘겨주는데 그 이유는 머물고 있던 자리를 기억하지 않으면 유저가 목록으로 돌아갈 때마다 첫번째 페이지로 가야하는 불편함이 생깁니다. 하지만 저장 중이라면 게시물 목록 클릭시 이전에 머물렀던 페이지로 돌아갈 수 있습니다. 페이징이 없다면 수많은 데이터가 계속 스크롤되는데 페이지가 저장되지 않음으로 원하는 위치로 돌아가기가 힘듭니다.
단위 테스트
소스코드의 독립된 특정 모듈을 개별적으로 검증하는 테스트입니다. 스프링에는 대표적으로 JUnit4가 있습니다.
테슽 하고 싶은 모듈이 있다면 해당 파일의 패키지 이름과 똑같이 테스트 폴더에 생성한 후에 독립적으로 수행할 메서드를 지정합니다.
테스트 성공, 실패 여부에 따라서 하단에 결과를 제공해 줍니다.
예상 값과 실제로 나온 값이 다른 실패 경우의 사진입니다.
빌드와 배포
빌드
컴파일된 코드를 실행할 수 있는 상태로 바꾸어주는 일
Intellj에서는 :build or :bootJar를 실행해서 빌드가 가능합니다. 이 경우 Jar 파일이 생성되는데 해당 파일은 로컬에서만 사용이 가능한 파일입니다.
:build는 Gradle에서 빌드를 위해 관련된 모든 task들을 실행시킵니다. 그리고 실행가능한 Jar 파일 이외에도 plain jar 파일을 하나 더 생성합니다.
:bootJar는 빌드를 위해 모든 task들을 실행시키는 것이 아니라, jar 파일을 생성하기 위한 task만 실행시킵니다.
IntelliJ를 사용하지 않고도 빌드를 진행 할 수 있습니다. 이 경우, 콘솔에 명령어를 직접 입력해서 빌드를 진행할 수 있습니다. 빌드가 완료되면 생성된 jar 파일을 java -jar Jar 파일명 으로 실행시킬 수 있습니다.
배포
빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일
전통적인 배포 방법은 다음과 같습니다. Spring Boot 기반의 Executable Jar 파일을 서버에 배포하는 가장 일반적인 방법은 scp와 같은 표준 유닉스 툴을 이용해서 서버로 간단히 전송하는 것입니다. 서버로 전송된 jar 파일은 JVM이 설치된 환경이라면 어디서든 손쉽게 실행할 수 있습니다.
클라우드 서비스를 위한 배포 방법
PaaS(Platform as a Service)
- 대표적인 PaaS 제공회사인 Cloud Foundry에서 제공하는 cf command line 툴을 사용하면 jar 파일을 손쉽게 배포할 수 있습니다.
IaaS(Infrastructure as a Service)
- jar 파일은 AWS Code Deploy, AWS Elastic Beanstalk, AWS Container Registry 같은 서비스를 이용해서 손쉽게 배포가 가능합니다.
- 또한, Microsoft의 클라우드 서비스인 Azure와 Google Cloud 역시 여러가지 Executable Jar 파일 배포 기능을 제공합니다.
CI / CD 플랫폼을 사용한 배포 방법
- GithubActions나 Circle CI, Jenkins 같은 플랫폼을 이용해 AWS나 Azure 같은 클라우드 서비스에 Executable Jar 파일을 자동 배포하도록 구성할 수 있습니다.
CI / CD AWS
CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Deployment)의 약자로서, 소프트웨어 개발 프로세스를 혁신적으로 개선하는데 중요한 역할을 수행합니다. CI/CD를 통해 코드 변경 사항을 자동으로 빌드, 테스트 및 배포함으로써 개발 속도를 높이고 안정성을 확보할 수 있습니다. 이러한 자동화 방법론은 개발자가 수동으로 빌드와 배포 과정을 반복하지 않아도 되게 하여 많은 시간을 절약할 수 있습니다.
위 방법을 사용하면 매번 새로운 커밋이 생길 때마다 서버에 새로운 버전으로 업로드하고, 기존에 실행 중이던 프로세스를 종료한 후에 새로 업로드한 프로젝트를 실행하지 않아도 됩니다.
- main 브랜치에 커밋이 발생하면 자동으로 테스트 및 빌드가 이루어진다.
- 빌드된 jar 파일이 배포 서버에 복사된다.
- 배포 서버에서는 기존에 실행되고 있는 서버를 중단한다.
- 새로 빌드된 jar 파일로 서버를 실행한다.
위와 같은 순서로 시행이 됩니다. 이떄 1-2초간 서비스가 다운되는 것을 막기 위해서 무중단 배포를 적용해주어야 합니다.
브랜치 전략
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있고 이후 병합이 가능합니다.
GIT-flow 전략은 소스코드를 관리하고 출시하기 위한 브랜치 관리 전략(branch management strategy) 중 하나입니다. Git flow는 Git이 활성화되기 시작하는 시기에 Vincent Driessen가 블로그 글에서 제안한 workflow 디자인을 기반으로 만들어졌으며 현재는 많은 기업에서 Git으로 개발을 할 때 표준으로 사용하는 개발 전략입니다.
git flow에서 사용하는 브랜치의 종류는 5가지이며 크게 항상 유지되는 메인 브렌치(Master, Develop)와 일정 기간 유지되는 보조 브랜치(feature, release, hostfix)로 나뉩니다.
- Master : 제품으로 출시될 수 있는 브랜치
- Develop : 다음 출시 버전을 개발하는 브랜치
- Feature : 기능을 개발하는 브랜치
- Release : 이전 출시 버전을 준비하는 브랜치
- Hostfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
전반적인 git flow 전략을 소스코드는 다음 이미지와 같이 관리를 하게 됩니다.
Github Flow
Github Flow는 깃허브(GitHub)를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것입니다. Github Flow는 Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미입니다.
