CI CD
github action → s3 → code deploy → ec2
- 도커나 젠킨스를 이용하는 방법도 있지만, 이 방법이 제일 익숙할것이라 생각
추가적으로 nginx 리버스 프록시를 이용해 무중단 배포도 가능 (이것도 해보면 좋을 듯)
무중단 배포 구조
무중단 배포 포함 전체 구조
스프링 부트와 AWS로 혼자 구현하는 웹 서비스 일부 발췌
Branch 전략
github flow (https://velog.io/@kw2577/Git-branch-전략)
- 원격 저장소에 브랜치(브랜치 이름은 자세한 작업명을 적어야한다)를 만들어서 작업
- 브랜치 이름은 issue 번호로 해도 될 것 같다고 생각
- issue에 자세한 작업명이 등록되있을거니까
- feature, hotfix의 브랜치를 없애고 위에 자세한 브랜치 이름으로 작업을 나타낸다.
- 피드백, 도움, merge 준비가 완료되면 PR을 생성해서 해결한다.
- PR이 바로 main 브랜치로 반영되므로 배포 주기가 짧아진다.
- 무중단 배포를 한다면 위 전략이 어울릴 것 같음
자세한 사용법
- master 브랜치는 어떤 때든 배포가 가능하다
- master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
- 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
- merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다
- master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성하자
- 브랜치는 항상 master 브랜치에서 만든다
- Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
- 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
- 커밋메시지를 명확하게 작성하자
- 원격지 브랜치로 수시로 push 하자
- Git-flow와 상반되는 방식
- 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
- 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다
- 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다
- pull request는 코드 리뷰를 도와주는 시스템
- 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
- merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자
- 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다
- 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
- 물론 CI도 통과해야한다!
- master로 merge되고 push 되었을 때는, 즉시 배포되어야한다
- GitHub-flow의 핵심
- master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다