TIL - 0510
git
- 버젼관리시스템 : 파일의 버젼을 직접 관리하지않고, 명령어를 통해서 관리 프로그램을 사용함
- 기본 work flow : 아래 사진을 보면서 아래 내용을 참고해본다
로컬 기준 버젼관리(파일 추적)는 3개 공간(단계), 2가지 작업으로 나뉜다
3개 공간
- working tree(space) : 작업 공간, 보통 프로젝트 디렉토리
- staging area : 변경 추적하고 있는 파일의 공간
- local repository : 변경 기록(commit == save data)을 보관하고 있는 공간
2가지 작업
- add : git을 통해서 파일관리를 하기위해서는 등록해야함, add 명령어를 통해 등록(Staged)함
- commit : 작업 단위이자 세이브 기록, git에서 핵심
- 링크드리스트 형태 : commit 명령어를 통해서 새로운 커밋객체가 생성되고, 현재 HEAD 브랜치가 가리키고 있는 커밋과 연결됨
- 새로운 커밋 생성 : 새로운 커밋(객체)는 HEAD 브랜치가 가리키고 있는 커밋으로부터 생성됨
브랜치는 참조변수
- 브랜치는 커밋을 가리키는 참조변수 역할만 함 : 커밋 객체를 직접 다루지않고 브랜치를 통해서 커밋을 다룸(직접 다뤄야할 때도 있음 - ID값을 통해)
- 메모리 주소값을 직접 다루지않고, 참조변수(명)로 다루는 것
- HEAD 브랜치는 현재 작업 중인 브랜치를 가리키는 참조변수, 브랜치는 현재 커밋의 참조변수
- checkout : 현재 작업 중인 브랜치의 커밋 기록(repo에서)을 찾아 워킹트리에 적용시킴 -> 파일이 해당 커밋으로 변경됨
협업하기 - remote repo
github으로 시작하기
- git commit 기록을 공유하는 서비스 : 공개/비공개 모두 가능함, 협업을 위해 주로 사용함
- github에 repository를 만들고, 로컬 git repository에서 git remote add 명령어를 통해 원격저장소와 연결해두면 준비 끝
$ git remote add $remote_repo_alias $remote_addr
github 업로드하기
- 푸시 하기위해선 local repository에 commit이 1개 이상 되어있어야함
- git log로 체크했을 때, HEAD 브랜치의 위치와 origin/브랜치와 같은 위치라면 같은 commit이기때문에 push 되지않음
- 모든 commit을 푸시하는게 아니라 원격 저장소와 비교했을 때 다른 commit만 푸시됨
$ git push $remote_repo_alias $remote_branch_name
팀원이 작업한 내역 로컬로 가져오기
- 팀원과 협업을 한다면 수정한 작업 내역을 가져와야함 이때 사용하는 전략은 2가지가 있음
- 첫번째 : 작업한 내역을 가져와서 나의 working tree에 바로 반영하기
- 두번째 : 작업한 내역을 local repository에 가져오기만하기
/* 첫번째 전략 */
$ git pull $remote_repo_alias $remote_branch_name
/* 두번째 전략 */
$ git fetch $remote_repo_alias $remote_branch_name
$ git merge $remote_branch_name 혹은 git rebase $remote_branch_name
- 첫번째와 두번째 전략의 차이점은 local repo에 커밋 기록을 가져와서 작업공간(working tree)에 바로 적용하는가, 하지않는가의 차이
- 핵심은 commit 을 가져온다는 것 : git work flow에서 가장 중요한 것은 commit
리눅스
리눅스와 친해지기
- 유닉스를 본떠서 만든, 유닉스와 닮은, 오픈소스 OS
- 리눅스 커널 : 리눅스 OS의 핵심부
- 리눅스 배포판 : 커널에 시스템 프로그램을 추가해서 배포한 것
- 레드햇 : 엔터프라이즈용 OS, 페도라(레드햇에서 무료로 배포한 OS), 서버용 OS로 주로 사용함(사후 서비스 - 레드햇)
- Centos : 무료 OS, 레드햇과 같지만 무료 버젼, 사후 서비스를 보장하지않는 것에 차이점이 있음
- AMI : Centos를 aws에 맞게 최적화 시킨 버젼, aws에서 사용할 땐 AMI를 사용하는 것이 좋다함
- 쉘(Shell) : 사용자와 OS(커널)을 이어주는 프로그램이자 명령어 인터프리터, 껍데기라는 뜻
- 커널(Kernel) : OS의 핵심부, 알맹이 라는 뜻
- 쉘과 커널 : 알맹이를 감싸고 있는 껍데기
- API : 프로그래밍을 통해서 어떤 기능을 사용할 수 있게 해주는 것, 내부적으로 어떻게 돌아가는지는 모르지만 기능은 사용할 수 있음
- OS API : 프로그래밍을 통해서 운영체제의 기능을 사용할 수 있게 해줌
- /dev/null : 리눅스의 블랙홀과 같은 곳, 보내버리면 없애버림
- 명령어를 여러개 배웠는데, 계속 써봐야할 것 같음 : 모든 공부가 그런게 아닐까!
배포
스프링부트 어플리케이션 배포하기
- 개발환경에서 개발한 어플리케이션을 사용자들이 요청할 수 있게 배포해야함 : 배포서버에 개발한 어플리케이션을 옮기고, 빌드 후 실행시켜야함
- 위의 작업을 수동으로 배포한 것을 레벨3과정 첫째날에 해보았음, 오늘은 쉘스크립트 + 배치프로그램을 통해 배포를 자동으로 할 수 있게함
- 쉘스크립트 : 쉘을 통해 실행시킬 명령어들의 모음 - 하나의 파일에 일련의 동작을 모아두고 실행하면됨
- 해당 작업을 통해 명령어 또한 프로그래밍을 할 수 있음을 알게됨, 똑같이 문법을 알아야함
- 스크립트에 작성할 명령 실행 flow
- 원격저장소 commit 내역 받아오기
- 로컬저장소 HEAD 브랜치 commit ID와 원격저장소 commit ID 비교
- 서로 다른 ID값이라면, build 디렉토리(gradle build 결과 디렉토리) 삭제 -> 받아온 commit merge
- 빌드툴(gradle)로 프로젝트 빌드 : 서버 다운타임을 줄이기위해서 현재 돌아가고 있는 서버의 프로세스를 kill 하기 전 빌드
- 서버 어플리케이션(spring-boot, tomcat - jar)의 프로세스 ID 찾음
- kill을 통해 해당 프로세스 킬
- 다시 빌드한 jar 파일 실행
/* deploy.sh */
#!/bin/zsh
# refresh git repo
git fetch
local=`git rev-parse imjinbro`
origin=`git rev-parse origin/imjinbro`
if [ ! $local = $origin ]; then
rm -rf ./build
git pull origin imjinbro
./gradlew build
target_pid=`jps | grep jar | cut -f 1 -d ' '`
echo "$target_pid shell die.."
kill -9 $target_pid
java -jar ./build/libs/java-qna-1.0.0.jar &
else
echo "No Update"
fi
- 리눅스 배치프로그램(crontab)을 사용한 정기적으로 빌드-배포 스크립트가 실행되도록 함
- 주의할 점 : crontab을 통해서 실행될 스크립트의 디렉토리까지 붙여서 써줘야함, 실행 권한까지 줘야함(chmod +x)
- 참고 : 호눅스 crontab 간단 사용법
스프링부트
템플릿엔진
- templates 를 사용하려면 템플릿 엔진을 사용해야함 : 템플릿 엔진 dependency 설정해야함
- dependency 삭제된채로 빌드해도 아무런 문제는 없지만, 컨트롤러에서 return할 때 비로소 문제가 발생함 : 1시간 삽질했음!
자바빈 규약
- 정보를 담는 객체는 클래스에서 디폴트 생성자를 반드시 가지고 있어야함(약속임)
AWS
IAM
- 루트 계정을 하나 만들어두고, 아래에 새끼 계정을 만드는 서비스
- 새끼 계정을 이렇게 만드는 이유는 권한 제어를 위해서임 : 예를 들어 DB 관리자에게 계정을 발급할 때 EC2에 작업을 하지못하도록 막고 발급해줄 수 있음
참고자료
- 코드스쿼드 레벨3 과정
- pro git 읽기 - 한글판