DevOps

• Development Operations
• 소프트웨어 개발과 운영을 통합하여 효율성, 협력, 속도, 안정성을 개선하는 개발 및 운영 방법
• Build(Compile+Link) > Deploy > Test > Release
• CI/CD
  • CI
    : Continuous Integration
    : 개발자가 개발한 프로젝트를 빌드하고 테스트하는 일련의 프로세스
  • CD
    : Continuous Delivery
    : 지속적으로 고객(조직 내부 QA팀, 최종 사용자)에게 프로젝트를 전달하기 위한 프로세스

방법

• 스크럼
  • 개발 및 QA 프로젝트를 가속하기 위한 팀원의 협력 방법을 정의
• 칸반
  • 진행 중인 소프트웨어 프로젝트 작업 상태(WIP)를 칸반 보드로 추적
• 애자일
  • 스크럼 및 칸반을 비롯한 많은 DevOps 방법에는 애자일 프로그래밍 요소가 포함되어 있음
  • e.g. 매일 아침 회의 수행, 지속적인 고객 피드백 포함
  • 기존의 긴 "폭포수" 개발 방법과 다르게 짧은소프트웨어 개발 DevOps 라이프사이클을 사용

툴체인

• 계획
  • 비즈니스 가치 및 요구사항을 정의
  • Jira, Git 등
• 코딩
  • 소프트웨어 설계 및 소프트웨어 코드 생성
  • GitHub, GitLab, Bitbucket, Stash 등
• 구축
  • 소프트웨어 빌드 및 버전을 관리, 자동화된 툴을 사용하여 코드 컴파일 및 패키징
  • Docker, Ansible, Puppet, Chef, Gradle, Maven, JFrog Artifactor 등
• 테스트
  • 코드 품질 보장
  • JUnit, Codeception, Selenium, Vagrant, TestNG, BlazeMeter 등
• 배포
  • 제품 릴리즈 및 운영
  • Puppet, Chef, Ansible, Jenkins, Kubernetes, OpenShift, OpenStack, Docker, Jira 등
• 운영
  • 운영 중인 소프트웨어 관리
  • Anabilities, Puppet, PowerShell, Chef, Salt, Otter 등
• 모니터링
  • 운영 환경의 특정 소프트웨어 릴리즈에서 발생하는 문제 정보 식별 및 수집
  • New Relic, Datadog, Grafana, Wireshark, Splunk, Nagios, Slack 등

Node.js

• JavaScript를 브라우저 밖에서도 실행할 수 있도록 해주는 런타임 환경이자, 서버 개발을 위한 플랫폼
• 개발 환경의 변화로 인해 문제가 나타날 수 있음
• 최신 버전은 새로운 기능이 포함되어있지만 안정성에대한 검증이 완벽히 되지 않은 버전
• LTS 버전은 안전성이 보장된 최신 버전

nvm

1. 설치
   brew 설치 https://velog.io/@jinic/brew

brew install nvm

2. 설정

brew info nvm // 명령어에서 안내대로 추가 진행

https://stackoverflow.com/questions/53118850/brew-install-nvm-nvm-command-not-found

// 생성
touch ~/.bash_profile || touch ~/.zshrc
// 작성(brew info nvm 안내대로 진행)
vi ~/.bash_profile || vi ~/.zshrc
// 재실행
source ~/.bash_profile || source ~/.zshrc

Oh my Zsh 설치하면 재 설정 필요

3. node 버전 설치/변경/확인

nvm install --lts
nvm install x.x.x
nvm use x.x.x
node -v

// nvm 으로 설치한 node 버전 확인
nvm list

node_modules

• node_modules폴더는 .gitignore에 추가
  https://stackoverflow.com/questions/22924633/gitignore-is-not-ignoring-directories

  git rm -r --cached node_modules
  git commit -m "removing node_modules"

• npm config
npm config list : 현재 설정된 값
  npm config set metrics-registry <패키지설치경로> --global
npm config set registry https://your-registry-url
npm install <패키지명> --registry=https://your-registry-url

• npm install시 "Maximum call stack size exceeded" 에러가 나는 경우

  • 자바스크립트에서 호출 스택(콜 스택)의 크기가 초과되었음을 의미

  • 원인

    • 순환 의존성
    • 의존성 충돌
    • 잘못된 또는 손상된 package.json
    • npm 또는 Node.js 버그
    • 대규모 프로젝트 또는 복잡한 의존성 트리

  • 해결 방법

    • npm 캐시 정리

    // npm cache 삭제
    npm cache clean --force
    
    // npm 재빌드
    npm rebuild
    
    // node_modules 폴더 삭제
    rm -rf node_modules

    • 메모리 할당 증가

    // 메모리 사용량을 8GB로 늘린 상태에서 npm install을 실행하여, 메모리 부족으로 인해 발생할 수 있는 설치 실패 문제 방지
    // 보통 대규모 프로젝트에서, 기본 메모리 제한(약 1.5GB)이 부족할 때 이 옵션을 사용
    
    // node: Node.js 실행 파일을 호출하는 명령어
    // --max-old-space-size=8192: V8 자바스크립트 엔진(구글 크롬과 Node.js의 핵심 부분)의 메모리 사용량을 조정하는 플래그
    // which npm 명령은 npm 실행 파일의 경로를 반환, 이 경로를 $(...)로 감싸서, 실제로는 node /path/to/npm과 같이 npm을 Node.js로 실행
    // npm install: Node.js 프로젝트의 package.json 파일에 정의된 모든 의존성을 설치하는 명령어
    node --max-old-space-size=8192 $(which npm) install

    • npm install 옵션 조정
      npm install --legacy-peer-deps 또는 npm install --force 옵션 사용

Dependencies, Dev Dependencies, Peer Dependencies

• Dependencies
  런타임, 빌드타임, 개발중 모두 필요한 패키지
  앱이 빌드 될 때 이 종속성 패키지들도 번들에 포함되어 배포됨
• Dev Dependencies
  런타임에서는 필요하지 않고 빌드타임, 개발중에만 필요한 패키지
  빌드타임에서 이 종속성 패키지들은 빌드에 도움을 주거나 참조 되지만 번들에는 포함되지 않음
• Peer Dependencies
  사용자가 설치해야할 종속성 명시
  ex. 리액트 컴포넌트 라이브러리를 개발했다면 사용자의 앱에 설치할 때 리액트를 통째로 들고 올 것이 아니라, 해당 앱에 설치되어 있는 리액트를 사용하도록 말해줌

패키지 재설치

rm -rf node_modules
rm -f package-lock.json | rm -f yarn.lock // lock 파일 삭제 
npm cache clean --force

Build Tool

• 프로젝트 내에서 소스 코드를 가지고 실행 가능한 Application 을 자동으로 생성해 주는 도구
• 빌드의 자동화는 소프트웨어 개발자가 다음과 같은 일상적으로 수행하는 다양한 작업(ex. Downloading Dependencies, Compiling Source Code into Binary Code, Packaging that Binary Code, Running Tests, Deployment to Product System)을 스크립트화 하거나 자동화하는 행위로 볼 수 있음
• https://buddy.works/blog/webpack-vs-gulp
  https://kdydesign.github.io/2017/07/27/webpack/

Gulp

gulpfile.js 파일을 기반으로 실행하는 Task Runner
Task Runner = 반복 가능한 특정 작업들을 단순 자동화한 것
(배포, 테스트와 같은 미리 정의해 놓은 어떤 작업들을 자동화하여 실행)
빌드속도가 빠름, 구축 시간이 적게 걸림
작은 규모의 개인프로젝트에서

npm install --global gulp-cli

Webpack

• 모듈 번들러
• package.json의 script를 기반으로 동작하는 Package Bundler
  Package Bundler = 종속성을 가진 어플리케이션 모듈을 정적인 소스로 재생산
  (소스들을 하나의 패키지화 하는 것)
  Webpack = Gulp + 의존성 관리 기능 + 솓고 빠름

entry
의존성의 시작점
Webpack은 모든 파일을 모듈로 관리한다.
Webpack에서 모듈이 많아질수록 서로의 의존성은 높아진다.

output
Webpack을 이용하여 빌드하고 번들된 파일의 위치를 지정

loader
파일을 해석하고 변환하는 과정에 관여하여 모듈 처리
Webpack은 javascript밖에 알지 못하므로 css,scss,babel,file 등은 loader로 등록해줘야 Webpack이 빌드할 때 인식을 할 수 있다.

plugin
해당 결과물의 형태를 바꾸는 역할을 하므로 번들링된 파일을 처리한다.
결과물에서 스타일 코드만 뽑아서 별도 css 파일로 만들어 역할에 따라 파일을 분리하는것이 가능하다.

Vite

• 자바스크립트 네이티브 모듈을 기반으로 한 데브 서버
• https://joshua1988.github.io/vue-camp/vite/intro.html#vite%E1%84%85%E1%85%A1%E1%86%AB

자바스크립트 패키지 매니저, 패키지 관리 툴

npm

Node.js의 기본 패키지 관리자
command-line client인 npm과 온라인 데이터베이스인 npm registry로 이루어져 있으며, 일반적으로 command-line client를 npm이라고 생각하는데, 실제로 npm에는 npm registry까지 포함되어 있습니다.

Node.js의 기본 패키지 관리자

장점
: 세계 최대 규모의 패키지들을 보유하고있음

단점
: 저장소의 취약한 보안 이슈
: 여러 패키지 설치 시 이전 패키지 설치가 완료 된 뒤 다음 패키지 설치로 시간이 오래걸림
: 패키지가 많아짐에 따라 빌드 성능이 떨어짐

npmrc

npm 패키지 매니저의 동작 사용자 지정

• shamefully-hoist=true
  : 일반적으로 npm은 종속성을 각 패키지의 node_modules 폴더에 설치합니다. 그러나 이 옵션을 사용하면 모든 종속성을 최상위 node_modules 폴더로 이동시켜 중복을 줄입니다. "shamefully-hoist"라는 용어는 이 작업이 관례적이지 않고 조심스러운 방법이라는 의미에서 사용됩니다.
• strict-peer-dependencies=false
  : 이 설정은 false로 설정되어 있으므로, npm이 peer 종속성에 대한 엄격한 검사를 수행하지 않습니다. peer 종속성은 패키지가 특정 버전의 다른 패키지와 함께 사용되어야 함을 나타냅니다. 이 설정을 사용하면 이러한 검사를 건너뛰고 종속성을 설치할 수 있습니다. 이것은 종종 개발 및 테스트 환경에서 편의를 위해 사용됩니다.
• https://www.daleseo.com/js-npm-config/

yarn

페이스북에서 만든 자바스크립트 패키지 관리자
npm과 같은 기능을 수
npm에 단점(속도, 안정성, 보안성)을 느껴 만들어 짐

npm에 단점(속도,안전성,보안성)을 느끼고 페이스북에서 만든 자바스크립트 패키지 매니저
npm과 같은 기능 수행

장점
: 여러 패키지 설치 시 병렬 설치로 속도가 빠름

단점
: yarn.lock 파일의 버전관리로 인해 기존 모듈이 최신화로 업데이트 될 수 있으며 이 경우 하위 호환을 보정하지않는 모듈에서 에러가 날 수 있음
: 디스크 용량을 좀 더 많이 잡아먹는 편

명령어
: https://classic.yarnpkg.com/en/docs/cli/install

npm vs yarn

• lock 파일은 둘 다(package-lock.json, yarn.lock) 있어도 되지만,
  npm과 yarn의 패키지 관리 방식이 다르기 때문에 한 번 사용하기 시작한 패키지 관리자로 계속 작업을 진행하는게 패키지 충돌 오류를 막아줌
• yarn이 npm의 개선버전으로 나왔다고는 하지만 npm도 지속적으로 개선되는 중
• local npmrc > global npmrc > local yarnrc?
• npm
  : 패키지를 한 번에 하나씩 순차적으로 설치
  : 각 설치한 패키지별로 서브패키지를 이루는 형식
  : 각 설치한 패키지의 독립성이 보장되지만, 패키지 중복으로 인한 크기가 전체적으로 커짐
• yarn
  : 여러 패키지를 동시에 가져오고 설치하도록 최적화되어 있은
  : 설치한 패키지와 종속되는 패키지를 공통적으로 사용할 때 일렬로 나열한 뒤 설치 패키지로 링크하는 방식
  : 패키지 중복이 제거되어 적은 용량으로 빠른 실행 가능
  : 네이티브 및 yarn을 고려하지 않은 버전 관리로 인한 드문 케이스로 패키지 충돌 가능성
• 참고
  • https://javascript.plainenglish.io/npm-vs-yarn-choosing-the-right-package-manager-a5f04256a93f
  • https://velog.io/@khy226/Yarn-%EC%9D%B4%EB%9E%80
  • https://joshua1988.github.io/vue-camp/package-manager/npm-vs-yarn.html#npm

패키지 관리 매커니즘

• 패키지 관리 툴의 종류에 상관없이 프로젝트의 메타정보는 package.json 파일을 통해 관리
• package.json 파일만 있으면 해당 프로젝트가 의존하고 있는 모든 패키지를 설치할 수 있기 때문에, node_modules 디렉터리는 Git 저장소에 올리지 않음
• package.json에서는 ^나 ~등을 이용해 범위를 지정한 경우가 많음 (따라서 모든 개발자가 동일시간에 패키지를 설치하지 않는 이상 개발자들은 서로 상이한 버전의 패키지를 설치할 확률이 매우 높아 이러한 상황을 해결하기 위해 패키지 관리툴에서 패키지 잠금을 지원하기 시작)

패키지 잠금 파일

패키지 잠금 파일에는 프로젝트의 패키지가 최초로 추가될 때 정확히 어떤 버전이 설치되었었는지 기록된다. 잠금 파일이 생성되면 잠금 파일에 명시된 버전으로 패키지를 설치해주어 설치 시점에 상관없이 항상 동일한 버전의 패키지가 설치되는 것을 보장 받을 수 있다. 잠금 파일을 Git 저장소에 올려두면 프로젝트의 모든 개발자의 PC뿐만 아니라 애플리케이션이 배포되는 서버까지도 npm registry에 배포된 최신 버전을 무시하고 잠금파일에 기록된 버전을 기준으로 패키지가 설치된다.

프로젝트를 최초 셋업하는 개발자는 패키지 잠금 파일을 Git 저장소에 반드시 올려서 다른 개발자들이 패키지 잠금 파일을 기준으로 패키지를 설치할 수 있도록 해야한다.
패키지 잠금 파일은 패키지 매니저가 신규 패키지를 설치하거나 기존 패키지를 갱신/제거할 때마다 package.json과 자동으로 동기를 맞춰주기 때문에 개발자가 이 파일을 직접 수정해야 할 필요는 없으며 해서도 안 된다.
신규 패키지를 설치하거나 기존 패키지를 갱신/제거한 개발자는 package.json과 더불어 함께 업데이트된 패키지 잠금 파일을 반드시 커밋해야 한다.
gitignore 에는 추가하지 말자.
https://blog.naver.com/gingsero/222140320340
https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5

npm: https://docs.npmjs.com/files/package-lock.json
yarn: https://yarnpkg.com/lang/en/docs/yarn-lock/

패키지 버저닝

• 참고 : https://blog.outsider.ne.kr/1041
• MAJOR.MINOR.PATCH
  • MAJOR
    : version when you make incompatible API changes
    (API의 호환성이 깨질만한 변경사항)
  • MINOR
    : version when you add functionality in a backwards-compatible manner
    (하위호환성을 지키면서 기능이 추가된 것)
  • PATCH
    : version when you make backwards-compatible bug fixes.
    : (하위호환성을 지키는 범위내에서 버그가 수정된 것)
• 틸트(~)
  • 현재 지정한 버전의 마지막 자리 내의 범위에서만 자동 업데이트
  • x.y.z 중 z 범위 내에서 버전 업데이트
  • ex.
    ~0.0.1 : >=0.0.1 <0.1.0
    ~0.1.1 : >=0.1.1 <0.2.0
    ~0.1 : >=0.1.0 <0.2.0
    ~0 : >=0.0 <1.0
• 캐럿(^)
  • Major버전이 바뀌지 않고, 하위호환성을 유지하기 때문에 실무에서 가장 많이 사용
  • x.y.z 중 x 이하 하위호환성이 보장되는 범위 내에서 버전 업데이트
  • ex.
    ^1.0.2 : >=1.0.2 <2.0
    ^1.0 : >=1.0.0 <2.0
    ^1 : >=1.0.0 <2.0

기타

Babel

Lint

Prettier

프론트 배포

• Nercel로 프론트 배포
  https://velog.io/@mjieun/Next.js-Vercel%EB%A1%9C-%ED%94%84%EB%A1%A0%ED%8A%B8-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0
• https://univdev.page/posts/vercel-cicd/