Server

환경변수들을 관리해 주는 env 파일들을 만들고, 그곳에 링크를 넣었다.
우리는 local, dev, staging 3가지가 있었다.
local 환경과 dev 환경이 같았고, staging 서버는 실제로 테스트 서버와 동일하게 간다고 하는 것이 일반적이라고 한다.
그래서 Gitlab에 올릴 때 브랜치를 잘 구분해서 머지해야 했다!

Build

build도 dev 서버에 빌드하는 명령어, staging 서버에 빌드하는 명령어 각각 따로 존재했다.
취업 전에는 이렇게 서버를 여러 개 만들어 놓을 필요가 없었으니..
npm run build 이런식으로 명령어만 치면 컴파일 되었었다.(high language --> low language)
하지만 회사는 dev 서버, staging 서버로 분기되어 있으니 각기 build 명령어가 달랐다.
package.json의 script에 표기되어 있었다!

Web Hosting(FileZilla)

Web Hosting ?

웹 호스팅은 웹 사이트 or 웹 애플리케이션을 저장하고
데스크톱, 모바일 및 태블릿과 같은 다양한 디바이스에서 손쉽게 액세스하도록 하는 서비스
다.
(내부 서버에서 비즈니스 웹 사이트를 호스팅하려면 시간과 비용이 많이 들기 때문에 웹 호스팅 회사로부터 공급받는다.)

나는 FileZilla를 사용했다.

FileZilla는 웹 호스팅을 위해 내 컴퓨터에서 FTP 서버로 파일을 쉽게 전송하기 위한 프로그램이다.
(SFTP를 사용하기 위해서는 SFTP를 지원하는 서버와 클라이언트가 있어야 하기 때문에 알드라이브 or FileZilla 이용)

화면에서 왼쪽은 내 컴퓨터 파일, 오른쪽은 aws 서버의 파일이다.(amazon web service)

프로토콜은 SFTP로 하고
(Protocol : 복수의 컴퓨터 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약)
(Secure File Transfer Protocal : 기존 FTP보다 보안이 강화된 전송 방식/모든 정보 암호화
일반적인 FTP : 로그인 정보 or 파일 정보 암호화 하지 않음 --> 정보 노출 위험 있음)

호스트에 인스턴스의 퍼블릭 IP 주소를 입력한다 (포트 번호는 각각 다름)

여기서 한 가지 알게 된 것이 있다!
서버마다 각각 연결해야 한다는 사실이다!
지금 보면 진짜 당연하고 쉬운 건데 와닿지 않아서 그런가...
staging으로 build 해놓고 dev 서버만 연결해놓으면 되는 줄 알고 거기다 옮길 뻔 하기도 하고...
dev로 build 하고 staging 서버에 파일을 옮길 뻔 하기도 했다.

CI/CD ?

난 아직도 이게 뭔지 모르겠다 ㅋㅋ.

CI/CD (Continuos Integration/Continuous Delivery)
: 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법
: 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포
: 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제를 해결하기 위한 solution
--> "CI/CD 파이프라인" 이라고 부름
: 개발 및 운영팀의 애자일 방식 협력을 통해 DevOps 또는 SRE(사이트 신뢰성 엔지니어링) 방식으로 지원됨

CI
: 지속적 통합
: 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리 가능

--> CI가 나오기 전까지는

개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지 검증할 수 있었다.

--> CI를 적용하게 되면

각자의 개발자가 자신이 구현해야할 기능을 구현하면 된다.
이후 완성이 되면 main branch와 통합하고, 코드가 잘 build 되는지 보고, 올바르게 동작하는지 테스트 하면 된다.

--> CI를 자동화까지 하게 되면

개발자가 build와 test를 직접 하지 않고도! 수정한 코드를 branch에 병합하기만 하면!
자동으로 빌드와 테스트를 검증할 수 있다.

개발자가 구현한 부분을 병합할 때마다 자동화된 빌드와 테스트가 트리거되어 실행된다.

CD
: 지속적 제공 = 지속적 배포
: 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리
: 지속적 제공
--> CI를 통해서 새로운 소스코드의 build와 테스트 병합까지 성공적으로 진행되었다면,
build와 test를 거쳐 github과 같은 저장소에 업로드하는 것
지속적 배포
--> 이렇게 성공적으로 병합된 내역을 저장소 뿐만 아니라,
사용자가 사용할 수 있는 배포 환경까지 release하는 것(배포하는 것)

대표적인 CI/CD 방법으로는 Travis와 Jenkins가 있다.
나중에 CI/CD 파이프라인을 구축하게 될 때 자세히 다뤄봐야겠다.

예전에는 CI/CD 를 다른 프론트 분이 해줘서 몰랐는데,
CI/CD를 하지 않으면 build 후 filezila 등에 직접 옮겨주는 번거로움이 있다는 사실을 깨달았다.

0개의 댓글