34일) 내가 만든 사이트를 세상에 공개한다..! 배포준비와 이에 따르는 책임들 / GCP/SSH/Loadbalancer/테스트코드 CODE CAMP FE 6기

• 졸면 저한테 사진찍힙니다 졸지맙시다 ㅎㅅㅎ

• 하.. 너무 아쉬운 코캠의 마지막 8주차 커리큘럼
  
  내가 로컬호스트로 틀어서만 확인 가능했던 사이트를 도메인을 직접 사서 배포 할 수 있다니 ?! 정말 너무나 설레는군...? (오류없이 포폴을 잘 만들어 놓자)
  게다가 깃헙으로 협업까지 배운다고 한다.. 정말 실무로 나가기위한 창과 방패와 머리단장까지 싹해서 내보내주는 느낌의 코캠..!

• 오늘 배울 내용
  오늘은 크게 배포와 테스트코드에 대해 알아봤죠!
  
  
  우리는 우리가 만든 프로젝트를 지금까지 yarn dev를 통해 ‘내 컴퓨터’안에서만 구동시켰죠? 하지만 외부 다른 컴퓨터에서도 접근이 가능하고 싶다면 외부 컴퓨터를 빌려 배포를 진행해야 했습니다!
  
  
  물론 우리가 가지고 있는 컴퓨터로도 배포가 가능하죠! 하지만 해당 컴퓨터를 24시간 구동시켜야하기 때문에 외부 컴퓨터를 빌려 배포를 진행하는 것이 효율적이였습니다!(경제적 측면)
  
  
  예전에는 배포를 어떻게 했는지 먼저 알아봤었죠!
  서버컴퓨터와 DB컴퓨터를 직접 사용하여 진행했습니다! 하지만 이 방식에는 문제가 있었죠!
  사용량이 증가하게 될 경우 서버 컴퓨터에 무리가 생겨 부하를 분산 시켜주었어야 했습니다!
  
  
  그렇기에 서버 컴퓨터를 하나 더 구매하여 분산시켜 주었습니다! LB(LoadBalancer)를 사용해 각각의 컴퓨터에 사용량을 분산시켜 해결한다고 했던것 기억나시죠!?
  
  
  또한, 실물 컴퓨터를 구매하던것을 이제는 CloudProvider 서비스를 사용하여 컴퓨터를 대여하게 되었죠!? 대표적으로 AWS(AmazonWebServices),GCP(GoogleCloudPaltform),Azure 등이 있었습니다!
  
  
  이렇게 클라우드 서비스를 사용하여 컴퓨터를 대여하여 해당 컴퓨터 안에서 git clone, yarn dev 등 명령어를 그대로 사용해 배포를 진행할 수 있었습니다!
  
  
  gcp의 compute Engine-VM인스턴스를 통해 가상 컴퓨터를 빌릴 수 있었죠!?
  이 안에서 인스턴스 만들기를 통해 빌리려는 컴퓨터의 사양과 지역을 고를 수 있었고, 부팅 디스크에서 컴퓨터의 운영체제를 선택 할 수 있었습니다!
  
  
  가상 컴퓨터를 대여한 후 SSH를 통해 해당 컴퓨터에 접속할 수 있었습니다! 우리는 이 컴퓨터를 24시간 꺼지지 않도록 설정하여 우리가 배포한 사이트가 항상 접근이 가능하도록 해주는 것 이였습니다!
  
  
  우리가 빌려놓은 컴퓨터의 ip로 접속하는 방식은 번거로웠죠!
  따라서 우리가 구매하는 도메인을 연결시켜주어 도메인 주소를 통해 해당 사이트에 접속하게 될 경우 해당 ip로 변경해 접속할 수 있도록 해주었어야 했습니다!
  
  
  네트워크 서비스 - Cloud DNS(Domain Name System) 에서 설정해 주었죠!?
  배포를 하게 될 경우 크게 두 가지 영역에 배포를 진행한다 했습니다!
  Storage와 Frontend-Server였습니다!
  
  
  html,css,js 등을 Storage에 저장시킨 후 Browser에서 Storage에 접근하여 html,css,js를 다운로드 받는 방식을 위한 Storage배포와
  SSR이 필요한 페이지에 접근할 경우, Browser에서 Frontend-server에 접근한 후 Backend-server -> DataBase에 접근하기 위한 Frontend-Server배포였습니다!
  
  
  즉, 주소(DNS)에 따라 어디로 접근하여 필요한 데이터를 받아올지가 나뉘게 되는 것인데, 이런 방식을 구분시켜주는 도구! 로드밸런서(LB)가 Browser에서 Storage 혹은 Frontend-server에 접근하기 전, 어디로 접근할지 판단하여 나누어 준다고 했습니다! 그렇기에 Storage/Frontend-server 앞에 붙여준다고 했습니다!
  
  
  다시말해, 접속하는 도메인 주소에 따라 입력된 값을 LB가 판단하여 Storage로 연결시킬지, Frontend-server로 연결시킬지 구분해준다고 했습니다! 기억나시죠!?
  
  
  하지만 이 Frontend-Server에 아무나 접근하면 안되겠죠! 따라서 우리는 방화벽을 설정하고, 우리가 지정한 특정 접근으로만 방화벽이 열리게 설정해주어야 했습니다!
  
  
  오늘 배우는 배포의 개념을 잘 잡고 가지않으면 실제 배포를 진행할때 많이 힘들게 되니, 꼭 개념 정리를 하고 넘어가시길 바랍니다!
  테스트 코드에 대해서도 알아봤죠!
  테스트코드는 우리가 만든 프로젝트가 잘 구동되는지 하나하나 손으로 체크하는 것이 아닌 프로그램으로써 확인하는 방식입니다!
  
  
  예시를 통해 테스트코드의 중요성을 알아봤습니다! 새로운 업데이트가 있을때, 예상치 못한 부분에서 발생할 수 있는 오류를 알 수 있었죠! 테스트코드는 안정적인 서비스 운영에 있어 중요한 부분이였습니다!
  
  
  테스트 방법에는 개별 기능을 테스트하는 단위테스트와 한꺼번에 테스트하는 통합테스트, 특정 루트나 시나리오가 있는 E2E테스트(End to End)가 있었죠!
  
  
  테스트 코드를 진행할 수 있는 프레임워크가 있는데, 그 중 jest와 cypress가 대표적입니다! jest는 단위테스트에 적합했고, 통합테스트나 E2E테스트는 cypress가 적합했죠!
  
  
  그 중 우리는 facebook에서 만든 jest를 실습해봤습니다!
  우리는 Next에서 사용하기위해 devDependencies에 jest와 testing-library/react, testing-library/jest-dom도 함께 설치해주었죠! 또한, eslint 에러가 발생할 수 있기에, eslint-plugin-jest도 설치해 주는것이 좋습니다!
  
  
  설치 이후, 설정파일도 만들어 주었습니다! jest.config.js에 공식문서 내용(https://nextjs.org/docs/testing#jest-and-react-testing-library)을 넣어주었죠!
  
  
  마지막으로 테스트 명령어를 추가해 주었죠! package.json안 script에 ”test”:”jest --watch”를 추가했습니다! 여기서 --watch는 테스트 진행 후 자동종료 되지않고, 변경사항이 생길때마다 테스트를 다시 진행하게하는 역할을 합니다!
  
  
  테스트 관련 파일들은 추후 헷갈리지 않도록 따로 폴더를 만들어 관리했습니다! test 기억나시죠? 보통 이런 테스트 폴더는 루트경로에 두어 관리하는 것이 추후 편할겁니다!
  
  
  큰 단위 테스트는 describe(“어떤 테스트인지 설명”,()=>{}) 를 사용하여 진행했고, 작은 단위의 테스트는 it(“어떤 테스트인지 설명”,()=>{})로 진행했습니다!
  
  
  여기서 it 대신 test 로 사용하여도 됩니다!
  기대값을 적어줄때는 expect()를 사용했죠! 그리고 결과로 나와야 하는 값을 toBe()안에 적어주었습니다! 그 예시로 우리는 더하기 함수를 테스트했죠!(expect(result).toBe(8) 기억나시죠!) 실제 테스트는 yarn test 로 진행했습니다!
  
  
  단위 테스트도 진행해봤죠! 간단한 컴포넌트를 만들었고 출력되는 화면이 맞는지 체크했습니다! 가상화면 출력테스트를 위해 import를 시켜주었습니다!(testing-library/jest-dom/extend-expect)
  
  
  동일하게 it()를 사용했고 테스트 함수에는 해당 컴포넌트를 가상으로 렌더링 시켜주는 render()를 통해 우리가 만든 페이지를 실행시켜주었죠!
  
  
  이후, 렌더링된 화면이 우리가 만든 내용과 동일한지 screen과 .getByText()를 사용해 화면 내 내용을 뽑아와 expect().toBeInTheDocument()를 사용해 화면에 출력되어있는지 확인해주었습니다! 하지만 이 방식은 방대한 양의 UI를 체크하기에는 비효율적이였죠!
  
  
  따라서 snapShotTest를 사용하는것이 더 효율적이였습니다!
  스냅샷 테스트는 해당 화면을 찍어 놓고, 이후 테스트를 진행할때 이전에 찍어 놓은 화면과 다른 부분을 찾아 알림을 주는 방식이였죠!
  Testing | Next.js
  Learn how to set up Next.js with three commonly used testing tools — Cypress, Playwright, Jest, and React Testing Library.
  Testing | Next.js
  테스트 함수에는 rendering결과를 담아 expect(result.container).toMatchSnapshot()를 사용해 기존 스냅샷이 있는 경우 기존 스냅샷과 비교하고, 기존 스냅샷이 없을 경우 새로운 스냅샷을 찍게 되었죠!
  
  
  cypress테스트도 진행해봤습니다! jest와 동일하게 devDependencies에 cypress를 추가해주고, script에 ”cypress”:”cypress open”와 ”cypress:run”:”cypress run”을 추가해주었습니다! 또한, jest와 충돌이 날 수 있기 때문에 jest.config.js에 testPathIgnorePatterns:[“<rootDir/cypress”]를 입력해주었습니다!
  
  
  cypress는 통합테스트에 적합했죠! 우리는 페이지 이동 테스트를 진행해 보았습니다!
  
  
  테스트를 위해 테스트코드를 만들기 전, 우리는 yarn cypress 를 통해 cypress를 열어준 후, 또 다른 터미널을 열어 yarn cypress:run 명령어를 실행해 cypress를 실행시켜 주었습니다! 실행시키게 되면 프로젝트 루트위치에 cypress폴더가 생기고, 내부에 integration(통합)폴더에 우리의 테스트를 작성하면 됐죠!
  
  
  동일하게 it로 작성했습니다, 테스트 함수에 cy.visit(“접속할 브라우저 주소”)로 페이지를 방문시킨 후, cy.get(“button”).click()로 페이지 내 이동 버튼을 눌러주어 페이지를 이동시키고 cy.get(“div”).contains(“포함하고 있어야하는 내용”)으로 체크해 주었습니다! 여기서 중요한 포인트는 사이트를 접속시켜주기 위해 yarn dev를 통해 서버를 열어 주어야 한다는 것이였습니다!

- 배포 Deployment

• 내가만든 서비스를 세상에 공개한다!
  • 우리가 여지껏 사이트를 켜서 확인했던 방식은, 내 컴퓨터 나의 Vscode에서 yarn start 후 yarn dev 통해서 localhost 3000으로 html, css, javascript를 받아와 보여주는 방식이었다.
  • 이것을 다른 컴퓨터에 옮겨서 clone을 하고 그 컴퓨터로 다른 사람들이 접속해서 나의 html, css, javascript를 받아가 볼수 있도록 하는게 배포!
    
  • 근데 저 요청을 하나의 컴퓨터에서 하나하나 하다보면,, 사람이 많아지면 컴터 하나로는 안돼 ! 그래서 백엔드 컴퓨터를 여러개를 두어봤다.
    
    
  • 그거로도 부족해서, 컴퓨터가 굉장히 많은 회사들이 등장 !
    (AWS, GCP, Azure...우리가 빌려줄게 사용요금만 내 ! )
    
    
  • 그 회사들이 터미널을 켠다..두둥! yarn dev를 24시간 켜놔야 사람들이 언제든 들어와서 다운받아가서 사이트 접속이 가능하니, 배포는 항상 yarn dev를 해놓는것이라고 생각하자. 우리는 그 24시간동안 켜놓는 비용을 지불하는것이고!
    
    
  • 가장 사용량이 많은 회사는 AWS이고, 그다음은 GCP이다 (국내 NHN NAVER..등등 국내 Cloud Provider도 있다)
  • 기능의 질은 GCP가 좋지만, 다양한 기능땜시 AWS로 보통 간다
• 구글 플랫폼 사이트를 가서 그럼 맨날 켜져있는 사이트를 사보자 !
  
• 1기가당 만원이라고 생각을 해보자
  
• SSH는 시큐어 쉘! (하나의 터미널을 의미한다)
  • 여기에 목록도 볼수 있고 폴더도 만들수 있고 깃 클론, 얀데브 가능 !
  • 터미널을 끄거나 놋북을 닫는다고 컴터가 꺼지는건 아니고, 이제 연결이 되었기 때문에 컴터를 끄려면 저 왼쪽 초록버튼을 꺼주고, 연결부분 종료를 해줘야 꺼지는것이다 !
    
  • 여기 리전은 물리적인 컴퓨터가 어디있는지를 고르는 건데, 국내에서 서비스를 배포하면 서울로 설정하는것이 좋아 ! (실제로 예전에 한 퀴즈 서비스에서 리전을 미국에두고 했었는데 버튼 클릭해서 바뀌는 속도가 너무 느려서 optimistic ui 적용하기도 어렵고, response 받아오는데도 딜레이가 걸리곤했었다.)
    
    
  • gcping 핑을 날린다 ?
    • 구글클라우드에서 핑을 날려봤을때 얼마나 지역에 따라 시간이 걸리는지 측정해주는 사이트
• vpc 네트워크- 방화벽이란?
  • 열어서 사용자들이 다운받아갈때 방화벽을 해제해주어야 접속이 들어올수 있는 공간을 만들어주는것이다 !
    (yarn dev만 하면 접속 안되는거야 보안목적땜시 yarn dev해주고 방화벽 없애줘야됨! 방화벽을 국내에서만 접속 할수 있도록 부분적으로 열어줄수도 있고, 루트별로 다양하게 설정가능 ! )
• mysite.com도메인을 사서 나의 외부ip로 바꾸어 연결해주는게 DNS!
  
• html, css,javascript는 정적파일이라고 한다 (static file0
  • 얘네를 그냥 스토리지에 올려놔 (static-file-serving)

  •             ^ Nginxt, Apache...

  • 스토리지에서 html, css, javascript가 저장하고 제공이 되는데, 왜 우리가 바로 거기다 올려서 배포하면 안되고, yarn dev를 거치고 컴터를 온라인해놓고 이 형식으로 배포를 해야할까?
    
    
  • 서버사이드렌더링 때문에..!
  • 서버사이드렌더링은 브라우저, 프론트, 백이 연결되는 즉시 그려내는 작업이기 때문에 !
    
    
• 요청을 분산하는 친구 LB(load balancer)
• 그 앞에 dns (아까 도메인 바꿔주는 친구라 해찌)
  • 도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환하는것을 의미!
• dns에서 요청이 들어오면 주소를 바꿔주고,
  lb가 렌더링을 파악해서 서버사이드 렌더링이네 ? 하면 f로,
  아니면은 정적파일 요청하는 스토리지(ssg-Static file serving)로 요청을 보내준다

-> 요청이 SSR인지, SSG인지에 따라 다른데다가 줄게 !

잠깐 :
Static Site Generator(SSG)란?

• Static-Generation(또는 SSG) 방식은 빌드 타임(npm run build)시

• 우리가 pages 폴더에서 작성한 각 페이지들에 대한 각각의 HTML 문서를 생성해서 정적(static) 문서로 가지고 있게 된다.

• 이 페이지에 대한 유저들의 요청이 발생하게 되면, 요청에 따라 계속 서버에서 재생성 하는 것이 아니라 이미 생성이 완료된 페이지를 반환해주게 된다.

• 따라서 생성이 완료된 HTML 문서를 재활용 하기에 응답 속도가 매우 빠르다.

• Next에서는 다음과 같은 경우에 Static-Generation 을 사용할 것을 권고하고 있다.

  • 퍼포먼스에 집중 (CDN을 통해 더 빠른 응답 가능)
    마케팅 페이지 / 블로그 게시물 / 제품의 목록 등과 같이 정적 생성하여 각 요청에 동일한 문서를 반환할 수 있는 경우

SSR 이란?

• SSR 방식은 유저의 요청 때 마다 그에 상응하는 HTML 문서를 생성하여 반환하는 방식이다.

• SSR을 사용하는 경우는 다음과 같이 설명하고 있다.

  • 항상 최신 상태를 유지해야 하는 경우 (요청에 따라 응답해야 할 내용이 시시각각 변함)
    제품의 상세 페이지 / 분석 차트 등 요청 마다 다른 내용 또는 형식의 HTML 문서가 반환되는 경우

• 그러면 우리는 서버사이드 렌더링 요청이 들어오는 곳에서 데이터나 api나 잘 관리를 해야한다
  

- test 테스트?

-마우스로 클릭하는거 대신해주기

• 어차피 테스트 할것인데 왜 테스트 코드를 만들어야 하는거지 ?
  • 버전 업데이트를 하고 기능을 추가하면서, 기존의 기능들이 모두 작동이 가능한지 0부터 끝까지 다 테스트 해봐야 하기 때문이다.
  • 처음에는 반드시 테스트코드가 필요한게 아닌데, 업데이트할때 기존 코드에 영향을 주면 어떡할껴 그때부터는 필수가 된다 !
    -> 테스트코드! (사람이 클릭하는것 행동하는것 .. 실행작업 다 적어놓는것)
    -> 할일 너무 많은데요...? ㅜ
    
    
• 테스트 코드를 만드는것은 두가지 방법으로 나뉜다
  • 규모가 크다 : 기능 + 테스트코드를 같이 만들어서 배포!
  • 처음에 작다(스타트업) : 기능먼저 + 업그레이드 기능의 증가 + 1차 기능에 대한 테스트코드 준비 .. 식으로 진행하게 된다 !
    
    
    -테스트하는 방법은 다 달라요!
    
    - E2E - End to end 끝에서 끝까지 테스트 한다는 뜻 !
    가장 많이 사용되는건 제스트 !
    -> 모해에 jest 들어가봐야지 !
    next.js와 jest는 자주 같이 사용한다
    테스트 종류별로 자주쓰는건 아마 저 두가지가 될꺼야 !
    
    next 들어가보면 우리는
    jest @testing-library/react @testing-library/jest-dom
    이렇게 3개를 설치할거야!
    
    yarn add -D jest @testing-library/react @testing-library/jest-dom 폴더 안에 설치해보리쟈
    -jest.config.js를 만들어주자
    
    pakage.json에 원래 위에 3개가 있었는데, 밑에 test를 추가해주세요
    그러면 우리는 yarn을 쓰니까 그러면 yarn test하면 test가 되겠지!
• 실습을 해보자
  
  테스트 파일은 같은 폴더안에 test 형식으로 만들어서, 파일명에 test붙여서 만들어주고
  테스트하고자하는거 import해주고
  예시를 넣어주고
  expect로 예상입력값 담아주고 뭐가 나와야하는지 작성해주는 코드 !

import { add } from '../index'
it("더하기가 잘되는지 테슷흐를 해보겠습니다", ()=> {
    const result =  add( 3 , 5 )
    expect(result).toBe(8)
})

앗 근데
넥스트라는 애는 Pages에 있으면 페이지로 착각을 할 수 있기 때문에,
pages의 바깥쪽 상위폴더에 지정을 해주어야 한다.


1. yarn add - D eslint-plugin-jest
2. yarn add -D jest-environment-jsdom
3. eslintrc. js plugins: ["react", "@typescript-eslint", "jest/globals"], 추가해주기 (eslint가 검사할수 있게금 플러그인에 추가해주겠다)
3. yarn test 해보자



여러개 검증 묶을수도 있어!

• 컴포넌트 검증해보자
  컴포넌트를 가짜로 렌더링 해본다는 의미!
  render를 testing-library/react에서 잘 임포트해오자
  컴포넌트니까 tsx로 테스트파일 만드는것도 잊지말고!
  
  
  
  
  
  
  expect(myText).toBeInTheDocument()
  확인해줘 이 텍스트가 저 파일에 있는지
  저러면 다 있고, 있고 있으니까 true가 나올꺼야 근데 더 효율적인 방법이 있어!

-> 스냅샷 테스트!

컴포넌트 안에 있는것을 하나하나 테스트하는것이 현실적으로 불가능하니까,
똑같은 내용을 스냅샷을 떠서(사진을 찌겅)
그게 바뀌면 체크하는 형태로 테스트를 한다.
스냅샷을 찌그면 폴더가 저절로 생기고, 비교해서 달라졌으면 에러를 띄우게됨
yarn add -D @testing-library/react@12.1.2
버전 문제 있을때 원하는 버전 다운받는 방법
페이지를 임포트해와서
투매치스냅샷 yarn test하면 스냅샷 폴더가 생긴다 그래서 그 이후에 test하면 바뀌면 error가 뜨게 되는 원리

- TDD

Test Driven Development

(테스트를 기반으로 개발을 하겠다, 테스트를 먼저 만들고, 기능만들기 )
우리는 여지껏 index파일 만들고 test폴더 만들었으니까 tdd가 아니겠지 !
이런 밑과 같은 이유로 테스트하려는 의도가 그냥 하나의 일로 변질될수가 있다.



테스트코드를 먼저 정성스럽게 만들고, 기능이 그 틀안에서 작동하도록 만들면 좋다!
하지만 모든 프로젝트에서 tdd를 꼭 하는것은 아니고,
더 안전한 코드를 필요로 하는곳에서 하면 된다 !

- cypress

• cypress open
  e2e테스트는 시나리오가 있다.
  홈과 이동하는 파일이 하나씩 있다고 가정했을때
  밑의 예시를 보면 실제로 cypress기반으로 브라우저가 열리고 , 접속이 된다
  
  그래서 a태그를 찾고 클릭해라 라고 명령하는 부분,
  이동된 페이지에서 h1태그를 가져와서 'about page'가 있는지 확인을 해라
  라고 되어있는 테스트 예시 !!!

- React Native 1일차

안드로이드 개발 Kotlin (java기반)
ios개발 swift(c언어 기반)
react native (안드로이드와 ios둘다 개발가능)

자바와 오브젝트c로 변환하는 과정에서 속도가 조금 느리기 때문에,
실제로 실무에서 용량이 커지게 되면 나중엔 코틀린이랑 스위프트로 넘어가게 된다

• expo CLI 개발입문자가 쉽게 개발할수 있도록하는 입문자용
• react native CLI 좀 더 확장형 실무형 라이브러리, 프레임워크
  (우분투 리액트 네이티브깔아서 리눅스 깔아야 실행가능?)
  yarn global add expo-cli
  expo init classmobile

https://reactnative.dev/docs/environment-setup
여기들어가서
sudo npm install -g expo-cli
맥북 관리자권한으로 폴더 설치 해주자 !!

그러면 이렇게 짜잔 왼쪽은 react native CLI
오른쪽은 expo CLI
react는 웹이어서 pages가 있었지만
우리는 나중에 screens 폴더를 깔아서 쓸거야

핸드폰에 expo앱을 깔아서 터미널에 뜬 qr코드로 접속하면 (핸드폰과 노트북이 같은 와이파이에 연결)
핸드포네도 화면이 뜨고 , 웹 브라우저에도 들어갈수 있다!
div태그같은 태그는 view!

indianred input창 만든 모습
함수를 만들어서 가져올때
event.nativeEvent.text를 쓰면 잘 들어온다
reactnative의 pressable부분 읽고 잘 활용해보자