<aside> 💡 자세한 히스토리는 아래의 문서를 참고하도록 하자

Git Flow 전략(2022.02.09~2022.02.10)

</aside>

깃 변경 계획

• [x] 브랜치 생성

  • [x] release → 존재
  • [x] develop → 존재
  • [x] staging → 생성필요

• [x] 동기화

  (구)	(신)	완료여부
  develop	staging	⭕
  release	develop	⭕
  master	release	⭕

• [x] Jenking 수정

  현재 release branch를 바라보고 있으므로 이를 develop 브랜치로 수정하자.

• [x] 테스트

  • [x] develop 브랜치로 MR을 보내고 CI가 제대로 이뤄지는지 확인

마이그레이션 계획

마이그레이션 상황에서의 원칙은 다음과 같다.

• (PROD 서버를 재가동하는 상황) 마이그레이션 적용 확인
• (PROD 서버를 재가동하는 상황) 패키지 내용 확인

기존 방식

• 이미지를 보시려면 왼쪽 화살표를 클릭하세요.

1. release 브랜치에서 마이그레이션 파일 생성
2. 역으로 develop 브랜치로 MR을 날림
3. master에 적용하는 상황에서는 release → master로 MR 날림

새로운 방식

결론은 운영서버에서 직접적으로 마이그레이션 파일을 만들지 않고 충분한 테스트를 거쳐서 적용만 동일하게 될 수 있다면 문제가 없다!

• 이미지를 보시려면 왼쪽 화살표를 클릭하세요.

1. feature/ 브랜치에서 필요한 마이그레이션 파일 생성
2. develop 브랜치에서 테스트 진행