WASD BLOG

 최근 어플리케이션 개발을 거의 마치고 배포 단계에 들어섰는데, 나중에 버전 관리나 배포 자동화를 위해 Git 의 브랜치부터 체계적으로 잡고 가야한다는 생각이 들었다. 그래서 git-flow 전략을 찾아봤고, 프로젝트에 어떻게 적용할 것인지 흐름을 정리해 보고자 한다. git-flow 의 내용을 설명하기보단 개발 -> 배포까지의 흐름 위주로 정리했다. develop 브랜치 master 브랜치에서 분기되는 브랜치로, 해당 master 브랜치 버전의 기능 개발을 develop 브랜치에서 하게 된다. feature 브랜치 develop 브랜치에서 분기되는 브랜치로, 특정 기능을 개발하기 위한 브랜치이다. feature/{기능} 으로 이름지으며, 기능이 완성되면 develop 브랜치에 병합하고 feature 브랜치는 지운다. release 브랜치 기능 개발이 어느정도 이루어지고, 정식 배포가 얼마 남지 않았을 때, 테스트를 위해 develop에서 분기하는 브랜치이다. - 이번 프로젝트에서 release 브랜치를 테스트 브랜치로 두고, release 브랜치에 코드가 푸시되면 테스트 및 빌드 후 테스트 서버에 자동으로 배포되게끔 적용하려 한다.  정식 배포 기간이 되면 master, develop 두 브랜치에 모두 병합해야 한다. (버전을 태깅해 커밋하면 버전 관리에 용이함) hotfix 브랜치 release 나 master 브랜치에서 빠르게 고쳐져야 할 사항이 생길 경우 만들고, 수정 후 master, release, develop 모두에 병합해야 한다. master 브랜치 정식 출시가 되는 브랜치로, 버전이 업데이트 될 때만 병합되어야 한다. 정식으로 릴리즈된 내용을 기록하고, 버전을 관리하는 브랜치이다. 브랜치를 개발 흐름대로 정리해 보았다. 즉, 1. develop 브랜치에서 feature 브랜치로 기능을 개발하고 2. 기능 개발이 완료되면 release 브랜치로 테스트 3. hotfix 브랜치로 오류 수정 후 4. master 브랜치로 정식 출시 까지의 흐

개발중인 앱의 테스트 서버를 Springboot, EC2로 구축했다. 하지만 매번 테스트 서버를 배포할 때마다 빌드, 배포 코드를 똑같이 쳐주는 게 번거로워 이 작업을 한 번에 해 줄 수 있는 쉘 스크립트를 짜보려고 한다.(쉘 스크립트 연습 겸!) 먼저, 빌드, 배포 순서는 다음과 같다. 1. BackEnd 폴더에서 github 코드를 pull 한다. (1번은 수동으로 진행하기로 했다. 어차피 이후에 github actions와 연동할 계획이므로) 2. gradle로 빌드한다. 3. 미리 실행 중인(실행 중이 아니라면 생략) nohup 프로세스를 종료한다. 4. build/libs 의 .jar 파일을 배포한다. 위 과정을 쉘 스크립트 실행 한 번으로 대체해보자! 쉘 스크립트 파일 생성 vi deploy.sh 스크립트 파일 권한 부여 chmod +x deploy.sh  => 실행 권한 부여 쉘 스크립트 파일의 맨 위에 쉘 스크립트임을 알려주는 코드를 넣어주어야 한다. #!/bin/bash   => 스크립트 상단에 작성 스크립트 파일을 만들었으니, 그 동안 터미널에서 사용한 명령어들을 넣어주자 1. 수작업 2. gradle 빌드 필자의 빌드 커맨드는 다음과 같다. 스크립트에 그대로 추가해 주자. sudo ./gradlew bootjar 3. 실행중인 nohup 프로세스 종료 바로 nohup 명령어를 실행해주면 이전에 실행중인 프로세스와 충돌이 일어나 배포가 진행되지 않는다. 따라서 기존 nohup 프로세스를 종료하는 로직을 추가해주자. sudo kill -9 $(ps -ef | grep {실행중인 파일 명} | awk '{print $2}') - 명령어 정리 kill : 해당 프로세스 id 의 프로세스를 종료한다. ps -ef | grep : ps로 현재 실행중인 프로세스를 검색하는데, grep으로 원하는 문자열이 포함된 프로세스만 검색할 수 있다. awk : 테이블 형태로 된 값들을 조작하는 명령어이다. $1, $2, $3... 들