blueprint
워크 플로우를 구축하기 전에 프로젝트의 일정과 참여 인원, 목표에 대해 생각해 보고 설계를 해보도록 하겠습니다.
프로젝트 이해하기
우선 프로젝트에 대해 이해해 보겠습니다.
- 해당 프로젝트는 졸업과제로써 진행되면서 기간은 약
2021.03.10~2021.12.18까지 진행되므로 거즘1년동안 진행된다고 생각하면 됩니다. - 인원은 저를 포함하여 총
4명에서 진행되며 팀원 모두 자신있어하는 stack이 다릅니다. - 제품 형태는 웹 서비스 제품군을 개발하기로 정하였습니다.
이외 자세한 주제가 궁금하면 belf 를 참고해주세요!
- 1명을 제외한 팀원이 모두 회사에 근무하고 있기 때문에 해당 프로젝트에 온전히 쏟아부울 수 없는 상태다
특히 야근 이벤트가 지속적으로 발생하므로...
- 금요일 저녁과 토요일은 학교에 가므로 이때 동안은 full로 프로젝트에 쏟아부을 수 있으며 오프라인 미팅도 가능하다.
정리하자면 1년동안 진행되며 웹 서비스를 개발할 것이고 팀원 대부분이 회사에서 근무를 하고 있음으로 해당 프로젝트에 돌발 이벤트가 발생할 확률이 높다 입니다.
조금 더 깊게 이해해보자
사실 제품군을 정하더라도 주제에 대해서는 프로젝트 초반에만 해도 계속 변하고 있었습니다. 그 와중에도 웹 서비스라는 제품을 정하게된 이유는 팀원들이 이해도도 높고 한번씩 해봤기 때문이였습니다.
이에 따라 반복적으로 요구사항(주제) 가 바뀔 것이 불보듯 뻔하였고 공통적으로 겹치는 stack이 있기도 했지만 서로 선호하는 언어와 프레임 워크가 조금 씩 달라서 애자일 방식의 MSA 형태로 아키텍처를 잡기로하였습니다.
어짜피 stack도 다른 상태라 하나의 repo에 branch를 찢어서 작업하려면 다른 팀원의 stack도 이해해야되서 비용이 크다고 판단하였고 팀원이 1인분 이상 할 것으로 기대하여 서비스를 하나 줘서 알아서, 반복적 으로 개발해 나가는 것이 좋다고 판단하였습니다.
특히, 대부분이 회사에서 근무를 하고 있었기 때문에 feature를 하루안에 끝나는 것은 고사하고 언제끝날지 예상하기도 어려웠기 때문에 모놀리식 하게 작업은 팀원 서로서로의 작업이 끝나지 않아 기다리는 상황이 많이 연출될 것이 예상되었습니다. 차란히 MSA 으로 서비스를 분리해서 줘서 알아서 잘 처리하고 관리해줘 라는게 관리포인트를 줄일 수 있는 방법이라고 판단되었습니다.
왜 회사를 근무하기 때문에 처리속도가 늦어지는가? 라고 말한 이유는 저 또한 아직 정시에 퇴근할 정도로 일을 파워풀 하게 처리할 수 없는 상태이기도 했고 회사 이외 학교 관련 온라인 수강, 과제 등 학교 등교 기간 이외는 feature 기간을 산출하는게 무의미한 상태이였기 때문이였습니다.
개발 도구를 정의하자
프로젝트에 사용되는 개발도구는 아래와 같이 정의하였습니다.
| 용도 | 도구 | 이유 |
|---|---|---|
| 클라우드 | Azure | 사용 경험이 있고 크래딧이 존재하기 때문 |
| 컨테이너 오케스트레이션 | k8s | MSA 이므로 각각의 서비스를 컨테이너로 관리할 것이며 그중 컨테이너를 손쉽게 관리하기 위하여 |
| Git 저장소 호스트 | Github | 익숙하고, 개발된 Source Code는 Public하게 Open 할 것 이라서 |
| CI/CD | Github Action | 이전에 Jenkins 으로 Pipeline를 만들어본 경험이 있는데 agent PC가 필요한 것과 레거시 스러운 UI로 인하여 클라우드형태의 CI/CD를 원하였습니다. 후보로 Github Action, Azure Pipelines 있었는데 깃 호스트로 Github를 사용하기 때문에 Github Action 으로 결정하였습니다. |
| 매신저 | Slack | Bot 연동도 쉽고 사용이 많이 사용되는 서비스라서 |
| 위키 | Notion | 제가 사용해 봤을 때 너무 편리하기도 하고 팀원에게 추천해줄 겸 notion으로 협업을 경험해보고 싶어서 |
| Code Editing | VSCode | 다양한 stack을 하나의 Editing로 통합하기 위함 |
워크플로우는?
실 서비스에 문제가 가지 않도록 제품 출시 전 내부적인 태스트를 위하여 k8s 의 namespace를 사용하여 qa, prod 환경을 논리적으로 구분할 것이고 이에 따른 도메인도 분리할 것 입니다.
Standard한 GitFlow는 반복적인 통합과 배포에 걸림돌이 된다는 판단하에 저희 프로젝트에 맞는 GitFlow를 정의하였습니다. 여기서 짧게 저희 GitFlow를 소개드리면 main, develop, feature/{기능 이름} 총 3개로 관리할 것입니다.
feature 에서 기능 개발과 관련된 실질적인 개발이 이뤄질 것 이고 feature 에서 develop branch으로 PR이 걸릴 때 qa 환경으로 CI/CD를 하도록하여 feature가 정상적으로 처리되었는지 qa 환경에서 지속적으로 테스트를 할 것이고 이에 문제가 없다면 develop 으로 Squash and Merge 될 것이며 이 시퀀스는 반복적으로 이뤄질 것 입니다.
자연스럽게 feature에 대한 코드 검수와 함께
qa테스트까지 자연스러운 flow를 도출할 수 있으며 사실 feature branch의 commit 내용은 크게 궁금하지 않습니다. 어떤 것이 개발되었는지가 중점이므로 feature commit를 하나로 묶어 merge 하도록Squash and Merge하는 것이 유리합니다.
develop 에는 qa 에서 통과한 검증된 기능단위의 commit들이 있을 것이며 팀원이 한자리에 모이는 토요일마다 release를 가지기로 했으며 토요일이 되면 develop 을 main 에 Rebase and Merge 후 Github의 Releases 기능을 통하여 releases 하면 prod 환경에 자동으로 배포되도록 할 것 입니다.
자연스럽게 Github Release 기능을 통하여 프로그램 버전에 맞게 git tag도 생성되고 Github을 아는 누구나 프로그램 Release 상태 추적을 쉽게 만들고
developbranch가main으로 merge 된다는 것은 하나의 개발 사이클이 끝난 것을 의미하며 이후 이뤄지는 새로운develop는 release된main에서 부터 분기를 시작하는 것이 맞기 때문에Rebase and Merge를 하였습니다.
마무리
자, 이렇게 프로젝트를 이해하고 개발 방법론과 아키텍처를 정리하고 워크플로우를 정의하는 시간을 가져봤습니다.
위에서 말한 내용은 아직 추상적이기 때문에 다음 챕터 부터 실제로 적용하는 방법을 가져보도록 하겠습니다.
끝까지 읽어주셔서 감사합니다 :) 다음 챕터에서 봬요~