전체 응용의 구성
프로젝트 개발과정의 설계를 미리 구성하는 방법
FE
React 응용으로 만들어져 UI 에 해당하는 부분을 서비스
BE로 향하는 api 호출은 브라우저의 JS 실행에 의해서 이루어짐 > 이 코드를 FE가 제공
- FE 에서 call(post, get, put, delete) 하는것처럼 보이지만, 호출은 브라우저의 실행에 의해서 이루어지는것이다!
BE
Express 응용으로 만들어져 데이터베이스를 이용한 데이터 모델을 서비스
JWT 를 이용한 사용자 인증을 통해 데이터 접근을 보호 : 로그아웃으로 인한 인증정보 해제, 기존 사용자의 정보 접근 제한
CORS 정책을 통한 악의적인 접근을 방지
DB
prgms_notes 라는 이름의 데이터베이스에 두개의 테이블을 포함
설정해야 할 것
FE
BE의 API URL 주소 : 코드에 포함하여 endpoint 를 구성할 수 있도록
BE
DB(host, database, user, password) : 직접 connector 를 이용하여 데이터베이스 접근을 할 수 있도록
FE의 URL : CORS 정책에 의해 접근을 허용할 수 있도록
아키텍처
Forward Proxy : 클라이언트 대신 프록시 서버가 목적 서버에 통신해주는 구성. 1차로 프록시 서버를 호출하고, 없다면 클라이언트가 웹서버에 직접 액세스 할 수 있다.
Reverse Proxy : 웹서버쪽에 위치해 클라이언트의 접근을 최초로 받아 리퀘스트에 해당하는 웹서버에 배분하는 역할
: 하나의 인스턴스 EC2 내부에 구성되어있어서, /api url 이후의 구성하는건 BE로 연결, /*url 이후의 구성은 FE로 포트다이랙트 되도록 클러스터를 구성하였다.
이러한 부분을 개발 이후에 아키텍처 정리하는 과정을 했는데, 설계에서부터 아키텍처를 짜니 프로젝트 전반에 대해 이해가 되는 것 같다.
Production 설정
https 연결이 가능하다.
BE URL 엔드포인드는 프로젝트도메인/api
로컬 테스트 환경
staging area 서버 : 배포환경과 동일한 서버 하나를 더 만들어서, 배포서버에 업로드 전에, staging 서버에 업로드 해서 인수테스트를 진행한다. 자원, 인스턴스 타입, 사양으로 똑같이 설정한다.
비슷한 쿠버네티스 서버 환경을 구성하기는 하지만, 개발 단계에서 검증하기에는..
- 웹서버를 사이에 두지 않고, FE,BE 접근 URL 설정에 차이가 있다.
- 인터넷 domain name 을 통하여 접근하는 것이 불가능하다. : 로컬 테스트 환경이기 때문이다.
- 데이터베이스 인스턴스도 동일한 쿠버네티스 컬러스터 내에 배치한다
- SSL 인증 없다. http 도메인. JWT 쿠키 처리 방식에 대해 차이점이 발생한다.
개발 환경의 구성
코드를 변경할 때마다 로컬 테스트 환경에 배포하는 것은
- 시간 소요
- 환경설정, 디버깅의 번거로움
따라서! 가볍고 빠른 테스트를 위한 환경 설정 필요하다
- 단위 테스트 작성 및 활용 : CI/CD 를 위해서도 매우 중요한 일
- 간단한 사용자 테스트 : npm 을 이용해서 FE, BE 각각을 서로 다른 포트에서 서비스하도록 하고 테스트
- 이 단계의 코드 !== 프로덕션 빌드 코드
- 배포모델을 염두하고, 유연한 설정을 적용할 수 있는 코드를 개발하는 것이 중요하다.
개발이 진행될수록 규모 등이 무거워진다. 시간이 더 많이 소요된다 > 테스트 자동화의 중요성!
운용이 배포될때 가지는 순서 및 구조
개발, 배포 환경
코드 구현의 이전에, 다른 부분의 코드 동작을 확인하는 것이 매우 유리하다. 초기일경우 변경이 빈번하기 때문!
테스트케이스를 먼저 구성하면, 효율을 높일 수 있다.
구조, 인터페이스의 요구사항 변경 시 테스트 코드 정비도 어려움. 사용자 인터페이스를 다루는 코드는 단위테스트로 검증하는데 어렵기때문에,
코드의 동작을 눈으로 확인할 수 있는 환경을 구축하는 것이 필요하다!
데이터베이스 준비
처음에는 의존성을 없이 개발하는게 수월하다.
어느 순간부터는 코드의 검증을 위해 데이터베이스의 상태가 필요하다.
인증 or CRUD 등..
스키마가 확정이라면, 미리 마련하는 것도 ㄱㅊ. 변경가능성 낮은경우 ok
* 프로덕션 DB를 테스트에 활용하는 것은 안된다!!
로컬 환경에서 테스트에 이용할 수 있는 DB를 따로 만들어야한다.
계획 수립
- 역할 분담
- 기획, 디자인, 코드개발, 테스트, 운영자원 : PM의 역할
- BE,FE의 분리
- 통일된 개발 방법, 팀 사이의 인터페이스 : 결과물에 대한 구체적인 예상으로부터
- 프로젝트 일정 및 지연 발생에 대한 대응책
멘토들과 적극적인 코드리뷰 계획
릴리스 정책과 방법, 운영계획, 유지보수에 대한 고려해야 할 요소들
- TDD : 부담스러울 수 있지만, 결과물에 대한 예측이 명확하기에 프로젝트에 연습으로 좋다.
- CI 지속적 통합 : 어느 단계에서부터 도입? FE+BE+DB 가 통합되고, 인수 테스트가 적용되기 시작할 시점
- CD 지속적 배포/인도 : 첫 릴리스 타겟 시점에 파이프라인 구축을 완료하는 계획으로
계획 테스트
- 단위 : mock 목 데이터 사용 테스트케이스 철저할수록 도움이 됨
- 통합 : 통합이 올바른지, 자동화 방법을 어떻게 할지 > 데이터베이스의 상태 관리 방법에 주의
- 인수
- 스모크 : 배포상태가 올바른지 검사 > status code 를 체크한다.
개발 외의 일들
- 배포 및 운영 구조 설계 및 구현
- 도커를 이용한 컨테이너화 및 테스트 검증 방법 : 순차적 구조 설계 및 구현
- 자동배포 도구 설정, 인프라 설계 및 설정
- 빌드 및 통합 환경에 필요한 요소의 개발
- 빌드 에이전트 구현 및 적용(node), 파이프라인 설계 및 구현(jenkins)
- 통합 인수 테스트를 위한 시자리오 개발 및 이에 적용할 데이터
- 코드 품질 확보
- 코드의 정적 분석을 통한 규액 준수 검사
- 각 단계 테스트에서 산출하는 리포트의 유지관리, 보고, 알림
- 서비스 운영 모니터링 계획 : 엄밀히는 개발팀의 역할이 아니지만..! 운영팀의 역할,,
일정계획
마일스톤 설정, 작업 병렬화, 도구 활용
순서와 시간의 배분은 자율적
사전점검(실현 가능성 검토)가 중요하다. > 멘토
for 문서화
- 기술적 요소
- 일정 계획
- 진척상황
- 동적 대응
- 가이드라인
- 합의사항