블로그 글

시니 선생님이 개발 블로그에 쓴 글입니다.

✅ 1. Playwright 보고서 HTML로 발행하기 stage('E2E') { steps { sh ''' npm install serve node_modules/.bin/serve -s

✅ 1. DevOps는 무엇일까? 표준이나 사양이 아님 소프트웨어가 아님 DevOps는 사고방식의 변화 즉, 문화이다. ✅ 2. 기존 방식의 문제점 새로운 기능을 원하는 고객이 있음 프로젝트 관리자는 고객이 원하는 것을 파악하고 몇 가지 사양을 작성

✅ 1. E2E(End-to-End) 테스트란? E2E는 "끝에서 끝까지"라는 뜻 사용자의 관점에서 애플리케이션의 전체 흐름을 처음부터 끝까지 검증하는 테스트 실제 브라우저를 띄우고 사용자가 하는 행동(로그인 클릭, 상품 검색, 결제 등)을 그대로 시

지금까지는 우리가 직접 빌드하기 버튼을 클릭하여 빌드를 진행했다. 하지만, 우리가 궁극적으로 원하는 것은 자동 빌드이다. 주기적으로 배포를 한다거나, Git에 변화가 생겼을 때 배포를 하는것과 같이 자동으로 빌드 및 배포를 하려면 어떻게 해야 할까

✅ 1. Jenkins 파일 생성하기 Jenkinsfile pipeline { agent any stages { stage('Hello') { steps { echo 'H

퀴즈 파트는 스스로 실습을 통해 배운 것을 테스트 하는 단계입니다. 반드시 스스로 실습을 진행해보시고 정답을 열어주세요! ✅ 1. 단계별 실습 과제 1단계 2단계 3단계 4단계 ✅ 2. 정답 확인(반드시 실습을 꼭 진행하고 확인할 것!!) 1단계 2

✅ 1. 프로젝트 다운로드 강의 자료에 있는 build.zip 파일을 다운로드 하고 압축을 해제한다. ✅ 2. netlify에 수동으로 배포하기 Or browse to upload 버튼을 클릭하고, 압축 해제한 build 폴더를 선택한다. 해당 버튼을

조금 더 안전한 배포를 위해, 스테이징 배포 이후 관리자의 승인 이후에 프로덕션 환경에 배포되게끔 하면 어떨까? Jenkins에서 제공하는 기능을 통해 구현해보자. ✅ 1. 새로운 파이프라인 생성하기 pipeline { agent any

우리는 방금 배포 후 테스트를 자동화하는 방법에 대해 배웠다. 그러나 배포가 엉뚱하게 되더라도 사용자는 엉뚱한 화면을 보는 것은 피할 수 없다. 그렇다면, 배포를 하기 전에 배포를 테스트할 수 있는 방법은 없을까? ✅ 1. 스테이징 환경을 구축하는

✅ 1. CI란 무엇일까? CI는 Continuous Integration의 약자 즉, 지속적인 통합을 의미한다. 쉽게 설명하자면, 여러 명의 개발자가 각자 수정한 코드를 하나의 공유 저장소에 수시로 합치고, 그 코드가 제대로 작동하는지 자동으로 확인

✅ 1. 프로젝트에서 자격 증명 사용하기 pipeline { agent { docker { image 'mcr.microsoft.com/playwright:v1.39.0-jammy' re

✅ 1. Node 프로젝트 준비하기 해당 프로젝트를 Clone 또는 Fork 하여 로컬에 복사한다. 해당 파일은 개인이 편한 IDE로 열어도 무방하나, 강의에서는 Codespace를 이용한다. 개인 IDE 툴을 활용하는 경우 반드시 Node를 설치 후