클라이언트 배포
1. 클라이언트 웹 앱 배포
다양한 웹 호스팅 서비스
Amazon Web Service (AWS) S3
: Infrastructure 자체를 제공하는, 다소 복잡한 서비스들의 집합
Vercel
: 코드 연결과 빌드, 배포까지의 과정을 매우 단순하게 만들어줌
Google Cloud Storage
GitHub Pages
Netlify
Heroku
로컬 환경에서 개발한 코드를 실제 서비스로 만들기 위해선 빌드 과정과 이를 웹에 노출시키는 배포 과정 필요
빌드를 통해 만든 정적 파일이 웹을 통해 제공(serve)되려면 정적 파일을 제공하는 웹 서버가 필요
일반적인 웹 서버 : 웹 서비스를 제공하는 모든 종류의 서버
호스팅 서비스 : 특별히 정적 파일을 제공할 수 있도록 서버의 공간을 대여해주는 서비스로 단순 파일을 웹에서 접근 가능하게 만들어 줌
*동적 웹사이트나 express 등을 사용한 API 서버를 제공하려면 별도의 클라우드 컴퓨팅 서비스 필요
클라이언트 앱이 아닌 서버 앱(API 서버)의 경우는, 실제로 node.js를 실행할 수 있는 컴퓨터가 필요
SSR과 CSR
차이 : 서버에 데이터를 요청했을 때 html파일이 어디서 조작되는가
브라우저의 작동 원리 참고
1) SSR
장점 : 초기 랜딩 속도가 빠르며 검색 엔진 최적화(SEO)가 가능
웹 사이트가 검색 결과에 더 잘보이도록 최적화하는 과정
단점 : 페이지를 요청할 때마다 새로고침이되며, 요청이 많아지면 서버에 부담
2) CSR
장점 : 초기 요청을 제외하면 페이지 랜딩 속도가 빠르며 서버에 부담이 적고, 사용자 경험이 좋음
단점 : 최초 로딩 속도가 느리며 검색 엔진 최적화(SEO)에 불리
정적 웹사이트 vs 동적 웹사이트
1) 정적 웹사이트
: HTML 파일(코드) 자체로 배포되는 사이트 (CSR, Client Side Rendering)
: 서버는 미리 만들어진 HTML, JS 파일을 전달하기만 함(서버 자원과 무관)
2) 동적 웹사이트
: 서버에 의해 HTML 파일이 동적으로 생성되는 사이트 (SSR, Server Side Rendering)
: 서버는 늘 HTML 파일을 만들어 응답해주어야 함(서버 자원에 따라 페이지의 형태 바뀜)
현대의 2-tier Architecture에서는 정적 웹사이트의 사용이 더욱 보편적
SSR의 장점을 살리기 위해서 다양한 방법으로 동적 웹사이트가 만들어지기도 함
성능의 향상을 극대화하기 위해 CCR, SSR의 하이브리드 형태로 구성하는 경우도 많음
github action으로 클라이언트 CI/CD를 구축한 배포 링크
CI/CD
사용자에게 우리가 만들어낸 프로젝트를 배포했는데 어떠한 동작이 올바르게 동작하지 않아 문제가 발생했다고 가정해보자.
개발자들에게는 비상이 걸릴 것이다. 급한 프로젝트일수록 더욱 빠르게 문제를 수정해야만 한다. 수정을 했으면 다시 컴파일, 빌드, 배포하는 과정을 통해 수정된 코드가 제대로 동작하는지 테스트하고 검증할 필요가 있다. 이 과정들은 시간도 많이 걸리고 실수하기도 쉽다.
수정된 코드에 문제가 다시 생기면 또 다시 과정을 반복해야한다. 이를 위해서 CI/CD가 생겨났다.
CI (Continuous Integration)
CI는 지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있도록 하는 것으로 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.
CI가 나오기 전까지는 위와 같이 개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지를 검증하며 코드 품질을 관리할 수 있었다.
CI를 적용하게 되면 각자의 개발자가 자신의 구현해야 할 기능을 구현하면 된다. 이후 완성이 되면 main 브랜치와 통합하고 코드가 잘 빌드되는지 보고, 올바르게 동작하는지 테스트하며 코드에 버그가 있다면 해결한다.
하지만 개발자가 직접 코드를 병합하고 빌드, 테스트를 검증하는 것은 시간이 많이 소요될 뿐만 아니라 귀찮고 그 양도 프로젝트의 크기가 커질수록 많아질 수밖에 없다.
이를 자동화하면 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있다.
개발자가 단위별로 구현한 부분을 병합할 때마다 자동화된 빌드와 테스트가 트리거되어 실행된다. 결과를 통해 우리는 어떤 부분에서 문제가 있는지 배포 전에 확인할 수 있고, 배포가 완성된 후에야 버그를 수정할 수 있던 기존의 문제를 빠르고 정확하게 해결할 수 있다.
결과적으로 버그를 신속하게 찾아 해결할 수 있을 뿐 아니라, 소프트웨어 품질을 개선하고 새로운 소프트웨어 업데이트를 검증하고 릴리즈하는데에 걸리는 시간을 단축할 수도 있다.
요약하자면 CI의 간단한 순서는 아래와 같다.
개발자가 구현한 코드를 기존 코드와 병합한다.
병합된 코드가 올바르게 동작하고 빌드되는지 검증한다.
테스트 결과 문제가 있다면 수정하고 다시 1로 돌아간다. 문제가 없다면 배포를 진행한다.
CD(Continuous Deployment)
이제 지속적 통합을 거친 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다.
CD는 지속적 배포로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념으로 지속적 제공(Continuous Delivery)로 사용되기도 한다.
지속적 제공은 CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github과 같은 저장소에 업로드하는 것을 의미한다.
지속적 배포는 이렇게 성공적으로 병합된 내역을 저장소뿐만 아니라 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미한다.
지속적 배포에서는 지속적 통합을 통해 빌드한 소스코드를 테스트 가능한 알파나 베타 버전으로 만든다. 이 버전에서 테스트를 수행해 문제가 발생하면 수정한 뒤 정식 버전으로 배포를 진행한다.
Github Actions
github에서 공식적으로 제공하는 CI / CD 툴(개발 워크 플로우 자동화 툴)이라고 보면 된다.
기존에 이미 Github과 서드파티 서비스들을 연동하여 자동화 해왔다. (TravisCI, CircleCI, Jenkins, CodeCov 등) 연동을 통해서 진행했던 많은 CI 작업들을 이제 Github(뒤에 MS를 업은)이 공식적인 기능으로 지원하게 되어, 개발 환경이 분산되지 않고 일원화된 개발 환경(GIthub)을 통해 많은 모든 과정을 통합적으로 관리할 수 있게 되었다.
Github Actions의 개념
Workflow 자동화된 전체 프로세스를 나타낸 순서도. Github에게 YAML파일로 정의한 자동화 동작을 전달하면, Github Actions는 해당 파일을 기반으로 그대로 실행시킨다.
Job 그룹의 역할로, 단일 가상 환경을 제공한다.
Step Job안에서 순차적으로 실행되는 프로세스 단위로, 파일 시스템을 통해 서로 정보를 공유, 교환할 수 있다. step에서 명령을 내리거나, action을 실행할 수 있다.
Action 타인들 또는 작성자에 의해서 미리 정의된 호출 매커니즘을 불러와 사용할 수 있다. 사용자가 직접 커스터마이징하거나, 어느 나/그룹/개발팀/제품/회사 등에서 정의한 action을 불러와 사용할 수 있다. Github Marketplace에서 공유되고, marketplace에 공유된 action은 yaml 파일에서 곧바로 사용할 수 있다.
Event workflow 실행 기준으로, cron과 같이 시간에 따라 작업을 실행하게 할 수도, git push / pull-request 등의 GIthub Repository 이벤트를 기준으로 실행하게 할 수도 있다.
