GitHub와 AWS를 사용한 협업 사례

협업에서 기획이 끝난 후 개발에 들어가기 전

GitHub와 branch, 배포환경 등의 초기 세팅을 하고 들어가게 된다

 

 

 

GitHub

제일 기본적인 github의 레포지토리를 생성하고 연결해준다

이 후 git branch 전략을 통해 develop를 추가해주는 등의 설정을 한다

 

 

· git branch 전략? 

브랜치 생성에 규칙을 만들어 개발자들간의 혼란을 방지하는 방식

 

main → 사용자들에게 배포한 최종 상태

develop → 배포하기 전 최종 개발 상태

feature → 개발자들 각자의 개발 공간

 

위는 제일 심플하고 기본적인 규칙이다

더 큰 회사에서는 좀 더 복잡한 branch 규칙을 정하는 등의 예시가 있다

 

 

 

· feature 생성 

개발하기 위해 feature branch를 생성할 때도 규칙이 존재한다

git checkout -d feature/1

feature/1에서 숫자부분은 Issues의 일련번호다

각 issue에 조그맣게 #숫자로 되어있는 걸 확인할 수 있다

 

개발자간 중복된 branch를 생성하면

매우 곤란해지기 때문에

절대 중복되지 않는 issues번호를 입력하는 식으로 한다

 

 

 

· Git Issues 

초기환경 세팅이 끝나고 GitHub의 isseus를 통해

어떤 기능을 구현할지 리스트를 작성한다

구현 리스트 예시

 

 

 

 

개발에 들어가면 개발자들은 각자 구현하고자 하는 기능에서

우측의 Assignees를 클릭하여

"이 기능은 내가 구현할거야!" 알려준다

 

개발자들이 기능을 중복으로 개발하는 등

불필요한 시간 소모와 코드 꼬임을 방지할 수 있다

 

 

· Pull Requests 

feature branch에서 구현한 기능을 develop에 합치기위해선

두가지의 방법이 존재한다

• develop branch에 직접가서 mege 하는 방법
• github의 Pull requests하는 방법

두 방법의 허락의 차이로

1번은 강제 합침 방식, 2번은 허락을 구하고 합치는 방식이다

때문에 대부분의 협업에서는 2번째 방법을 채택한다

 

Pull Requests는 줄여서 pr이라 부르며

pr하여 본인의 구현기능과 Issues번호를 입력해 팀원과 소통하거나

팀장에게 허락을 구할 수 있다

 

또한 pr로 mege해도 develop의 코드가 변화되기 때문에

develop의 actions이 활성화된다

 

develop에서 main으로 mege할 때도 똑같다

 

 

 

GitHub + AWS 초기 설정

이전 포스팅에서 AWS 배포에서 자동화까지 정리한 적이 있다

웬만한 협업에서도 이를 따르지만

위 git branch 전략으로 약간의 차이가 존재한다

 

1. main, develop 각 branch의 Github Actions 적용
2. main전용 버킷,배포 생성
3. develop전용 버킷,배포 생성
4. 한 도메인에 main, develop 연결
   • develop는 도메인 앞꼬다리 dev. 추가
5. 사용자 인증서 생성 후 각각 액세스 연결
   • 사용자 인증서는 하나만 생성해도 된다

dev 액세스 연결할 땐

CNAME 이름 뒤에 붙어있는 .dev까지 붙여줘야한다

 

그리고

main, develop 버킷 이름은

앞에 각각 prod, dev 등을 붙여 구분하면 편하다

 

※ 배포환경(main)과 개발환경(develop)는 어떻게든 동일한 상태로 개발되어야 한다 ※