💡 배경
ISMS 및 내부회계감사 정책에 따르면 개발자는 운영서버에 직접 소스 배포가 불가능하다
현재 팀에는 개발자들로만 구성되어 있는데 배포운영자는 개발자여서는 안된다는 정책때문에
이와 같이 티오를 마련하지 못한 회사들의 경우 팀장 등 배포운영자에 준하는 권한자 승인 하에
배포가 가능해서 일반적으로 사용하는 브랜치 전략과는 조금 다른 방식을 고안했다
📝 AS-IS
- develop에서 feature 생성
- 개발 후 develop에 feature merge 및 push
- 배포승인 후 master에 develop merge
- master push
이 경우 develop브랜치에 테스트중인 미승인 건들이 같이 존재하는데
develop브랜치를 master에 직접 merge하면 미승인 건들까지 함께
합쳐져 보안감사정책에 위배된다
develop과 master 사이 release를 운영할까 했지만 release는 develop에서 따는데
미승인 건은 지우고 master에 merge한다? 그리고 develop에 release를 merge할 것이고
그럼 develop에 있는 미승인된 건들은 삭제될 것이다
develop과 master 내용이 다른 시점에서 이미 고려할 사항이 아니라 판단했다
아니면 배포시점을 컨트롤 해야될 부분이지만 여긴 배포운영자가 없다
또 개발자들에게 실수하지말고 항상 배포가능여부를 서로에게 확인하게 하는 것은
맞지 않다고 생각해서 아래와 같이 전략을 수정했다
📝 TO-BE
- develop에서 feature 생성
- 개발 후 develop에 feature merge 및 push
- 배포승인 후 master에 feature merge
- master push
master에 merge하는 브랜치를 feature로 하여
자기 개발 내역만 적용할 수 있도록 하며
develop과 master는 직접 만나지 않게 한다
더 좋은 방식이 있다면 전략을 바꿔야겠지만
배포운영자가 공석인 지금으로선 최선이라 생각하는데
더 나은 방향이 있다면 수정하고 수정내용에 대해 포스팅하겠다
