백엔드가 이정도는 해줘야 함 - 13. 웹 어플리케이션 개발

PlanB·2019년 2월 12일

Backend

백엔드가 이정도는 해줘야 함

목록 보기

15/21

개발 다 하고 나서 그냥 스냅샷 링크만 던져줘도 되겠지만 여기도 '일러두기' 설명을 좀 하는 게 좋을 것 같아서 챕터를 나눴다.

일러두기

API 스펙의 변경

2019년 3월 7일 이전에 6. API 스펙 설계와 문서화 방식 결정 - (1) 챕터를 읽었다면, 사용자의 ID를 이메일로 두고자 하는 시도가 있었음을 기억할 것이다. 실제로 구현하려고 보니, 개인적으로 가지고 있는 도메인이 없어서 회원가입 인증 메일을 전송하기 위한 이메일을 확보할 수 없었다. 나름 서비스 구현을 하는 것이라서 구글 계정을 만들어서 gmail SMTP를 쓰고 하는 것은 좀 꺼림칙하길래, 그냥 문자열 ID를 사용하는 것으로 선회했다. 그러나 이메일에 관련된 구현은 배울 것들이 꽤 있으므로 나중에 도메인 관련 챕터 진행 후, '기획 변경에 대응하기'같은 챕터를 만들어서 사용자 ID를 이메일로 다루도록 변경하는 작업을 진행하고자 한다.

변경되기 전의 API 스펙을 기준으로 DB Schema 정의 이슈까지를 진행했고, API 스펙을 변경한 후에 해당 이슈에 관련된 커밋들을 hard reset하고 새롭게 작업한 것들을 master로 push하긴 했으나, 해당 이슈에 대해 이미 merge된 PR의 커밋에는 이메일에 관련된 내용이 포함되어 있는 상태다. hard reset으로 인해 해당 커밋은 master 기준으론 '없는 커밋'으로 처리되었다. 이에 대한 괴리는 너그러이 이해해 주기 바란다.

이슈 라벨의 변경

3. 개발 프로세스 정립 챕터에서 이슈 라벨을 minor/major, feature/bug/enhancement로 설정해 두었으나, 이슈 라벨을 선택하기가 너무 애매해서 minor/major/urgent, Non-code work/On-code work로 변경했다. 추가적으로, '보류된' 이슈임을 나타내기 위해 hang이라는 라벨을 추가했다.

작업의 진행

3. 개발 프로세스 정립 챕터에서 이야기했던 프로세스를 그대로 가져와서, 리뷰 단계만 제외시키자.
1. 알맞는 라벨과 함께 이슈 생성, Project 선택

작업 진행자 assign
master에서 작업 브랜치(issue/<이슈 번호>) 체크아웃
작업 완료 후 master로 pull request 후 merge
이슈 close
작업 브랜치 제거

저장소가 다뤄지는 workflow

일반적으로 저장소 하나를 두고 여러 사람이 협업하는 것은 push의 대상 저장소를 결정하는 것과 같은 관점에서 여러 형태의 workflow를 대입할 수 있는데, 이는 분산 환경에서의 Workflow를 대충 읽어보면 감이 올 것이다. 대표적으로 아래 2가지 방식이 사용된다.

메인 저장소 하나를 두고, 모든 작업자는 해당 저장소를 clone받아 작업한다. push가 즉시 메인 저장소에 반영된다.
메인 저장소 하나를 두고, 모든 작업자는 해당 저장소를 fork해서 자신의 저장소로 만든다. 작업자는 이 fork된 저장소를 clone해서 작업하고, 여기에 push한다. 메인 저장소에 작업이 반영되는 시점은 pull request가 merge되는 순간이다.

당장은 전자의 workflow를 사용할 것이다(비교적 이해하기 쉬운 구조라서, 독자 여러분이 불필요한 러닝커브를 감당하지 않았으면 하는 마음에). 그러나 내 관점에선 그리 바람직하지 않다고 생각한다. 나중에 저장소를 협업에 용이하게 변경하는 챕터를 작성하게 될 때 다시 다뤄보도록 하겠다.

CodeBuild webhook 잠시 제거

나는 제거하지 않겠지만, CodeBuild가 제공하는 free tier 범위를 초과하는 것이 걱정스럽다면 webhook을 잠시 제거하자. 빌드 프로젝트에 접속해 편집 - Source에 들어가서, webhook과 관련된 설정을 비활성화 시켜두면 된다.

스크린샷 2019-02-23 오후 6.29.28.png

SECRET_KEY

Flask Large Application Example에서 배포용 Flask application을 제공하는 production_app.py에서는 환경 변수에 SECRET_KEY가 없으면 Warning을 raise한다. 따라서 Lambda Management Console에 접속해 SECRET_KEY 환경 변수를 추가했다. 이제 '환경 변수' 섹션은 아래와 같은 상태다.

스크린샷 2019-02-23 오후 7.28.31.png