나의 잡다한 노트 및 메모

회귀 테스트(Regression Testing)는 소프트웨어 변경 후 기존 기능들이 여전히 정상적으로 작동하는지를 확인하기 위한 테스트 절차이다.  회귀 테스트의 정의회귀 테스트는 소스 코드에 변경(버그 수정, 기능 추가, 개선 등)이 이루어진 후, 변경 사항이 기존에 잘 동작하던 기능에 의도치 않은 영향을 미치지 않았는지 검증하는 과정입니다.즉, 코드 변경으로 인해 “회귀(regression)” 즉, 기존 기능에 문제가 발생하는 것을 방지하기 위해 수행됩니다.  회귀 테스트의 목적기존 기능 보장:변경 후에도 애플리케이션의 모든 주요 기능이 정상적으로 동작하는지 확인합니다.예기치 않은 오류 예방:수정된 부분이나 새로 추가된 기능이 기존 코드와 상호 작용할 때 발생할 수 있는 부작용을 조기에 발견합니다.품..

1. Smoke Test (스모크 테스트)개념 및 목적초기 안정성 검증:새로 빌드된 애플리케이션이 "큰 결함" 없이 실행되는지를 확인합니다.기본 기능들이 정상적으로 작동하는지만 체크하여, 시스템 전체의 건강 상태를 빠르게 판단합니다.주요 목적:기본 동작 확인: 애플리케이션이 전반적으로 작동하는지, 즉 주요 화면이 로드되고, 핵심 기능(로그인, 주요 메뉴 접근 등)이 수행되는지를 확인합니다.빌드 품질 판단: 빌드가 안정적이면 이후에 진행될 상세한 테스트(예: 회귀 테스트)를 수행할 수 있는지 판단합니다.적용 시점 및 특징적용 시점:새 빌드가 완료된 후배포 전에, 혹은 배포 직후 초기 검증 단계로 사용됩니다.특징:넓고 얕은 범위: 시스템의 광범위한 영역을 대상으로 하지만, 각 기능에 대한 세밀한 검증은 수행..

SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링)은 소프트웨어 엔지니어링 기법을 인프라 운영에 적용하여, 시스템의 안정성과 확장성을 높이고 운영상의 문제를 자동화 및 예방하는 접근 방식입니다. 아래는 SRE에 대한 자세한 설명입니다.1. SRE의 개념 및 기원정의:SRE는 소프트웨어 엔지니어링 기술을 활용해 시스템의 가용성, 성능, 확장성 등을 보장하고, 운영 업무(운영, 모니터링, 장애 대응 등)를 자동화하여 효율적으로 관리하는 방법론입니다.기원:구글에서 2003년 경에 처음 도입된 개념으로, 당시 대규모 서비스 운영의 복잡성을 해결하기 위해 탄생했습니다. 이후 많은 기업들이 이 모델을 도입해 운영의 효율성과 안정성을 크게 향상시켰습니다.2. 주요 원칙 및 개념신뢰..

remote 브랜치 목록 업데이트:먼저 git fetch 명령어로 원격 저장소의 최신 브랜치 정보를 가져옵니다. git fetchremote 브랜치를 로컬 브랜치로 체크아웃:가져온 remote 브랜치를 기반으로 새 로컬 브랜치를 생성하고 전환합니다. 예를 들어, remote의 브랜치 이름이 feature-branch라면 다음과 같이 실행합니다. git checkout -b feature-branch origin/feature-branch 왜 로컬 브랜치를 생성해야 할까요?작업 공간 제공:로컬 브랜치는 여러분이 파일을 수정하고, 테스트하며, 커밋할 수 있는 개인 작업 공간을 제공합니다.추적 및 동기화:원격 브랜치와 로컬 브랜치를 연결(tracking)함으로써 변경 사항을 효율적으로 관리할 수 있습니다. 이..

멀티 스테이지 빌드에서는 --target 옵션을 사용하여 원하는 특정 스테이지만 빌드할 수 있습니다. # 빌드 스테이지FROM node:14 AS builderWORKDIR /appCOPY package*.json ./RUN npm installCOPY . .RUN npm run build# 실행 스테이지FROM nginx:alpine AS runtimeCOPY --from=builder /app/build /usr/share/nginx/html이런 도커파일이 있다고 하고 stage가 정의돼있을때,builder와 runtime 두 개의 스테이지가 있다. 만약 빌드 시점에 builder 스테이지만 실행하고 싶다면 docker build --target builder -t myapp-builder . 이 명..

ARG vs. ENVARG (Build-time Argument)빌드 시점에만 사용할 수 있는 변수입니다.도커 이미지를 빌드할 때, 빌드 명령어(docker build)에 --build-arg 옵션을 통해 값을 전달할 수 있습니다.빌드가 완료되면 해당 값은 최종 이미지에 남지 않습니다.주로 빌드 프로세스에서만 필요한 정보를 전달할 때 사용합니다.ENV (Environment Variable)런타임과 빌드 시점 모두에서 사용할 수 있는 변수입니다.최종 컨테이너 이미지에 포함되어, 컨테이너가 실행될 때도 환경 변수로 남습니다.주로 애플리케이션 실행 시 필요한 설정이나 경로, 옵션 등을 지정할 때 사용합니다.

도커(Docker) 이미지를 이용해 개발 환경(dev), QA(품질 테스트 환경), 운영 환경(prod) 등 여러 스테이지(Stage)를 분리하고, 각 환경마다 인증이나 설정이 달라질 수 있다는 점을 설명하고 있습니다. 그리고 이를 환경 변수(ENV) 관리를 통해 효율적으로 제어할 수 있다는 내용을 담고 있습니다.아래에서 좀 더 구체적으로 살펴보겠습니다.1. 스테이지(환경) 구분일반적으로 애플리케이션 개발 과정에서는 다음과 같은 환경을 분리합니다:Dev(개발 환경):개발자들이 코드를 작성하고, 로컬 또는 개발 서버에서 실행하는 환경배포 자동화나 CI/CD 파이프라인 등을 테스트해볼 수 있음QA(품질 보증 환경 / 테스트 환경):QA 팀이나 자동화 테스트가 실제 프로덕션 환경과 유사한 조건에서 테스트를 진..

가상화는 물리적인 장비(서버, 스토리지, 네트워크 등)를 논리적으로 분리하여 여러 개의 독립적인 환경(가상 머신, 가상 스토리지 등)을 만들어 내는 기술 1. 물리적 장비와 가상화물리적 장비:전통적으로 한 서버에는 하나의 운영체제와 애플리케이션만 실행했습니다. 이 경우 서버의 모든 자원이 한 가지 용도로만 사용되죠.가상화의 개념:하나의 물리 서버를 여러 개의 가상 머신(Virtual Machine) 으로 나눌 수 있습니다. 각 가상 머신은 독립적으로 운영체제와 애플리케이션을 실행할 수 있어, 물리 서버의 자원을 여러 용도로 동시에 활용할 수 있습니다. 2. 가상화의 장점자원 효율성:물리적 서버 한 대를 여러 가상 머신으로 분할하면, 자원을 보다 효율적으로 사용할 수 있습니다. 즉, 한 서버의 CPU, 메..