CICD3 3. 일반 프로젝트에 CI/CD 구축법(깃허브 액션에서 빌드/테스트) 1. 역할 분담: 일하는 곳(GitHub Runner)과 보여주는 곳(EC2)가장 먼저 이해해야 할 핵심 개념은 역할의 분리입니다.이전 방식 (EC2에서 빌드): EC2 서버가 **빌드/테스트(일하는 곳)**와 서비스 운영(보여주는 곳) 역할을 모두 담당했습니다. 이는 가게 주방과 손님 테이블이 합쳐진 것과 같아서, 요리(빌드) 중에 가게가 어수선해지거나(서버 성능 저하) 문제가 생길 수 있습니다.표준 방식 (GitHub Actions에서 빌드): GitHub Actions가 제공하는 가상 머신(GitHub Runner)이 **빌드/테스트(일하는 곳)**를 전담합니다. EC2 서버는 Runner가 완성한 결과물(음식)을 받아 **서비스 운영(보여주는 곳)**에만 집중합니다. 주방과 홀이 완벽히 분리되어 .. 2025. 9. 3. 2. 개인 프로젝트에 CI/CD 구축법(EC2에서 빌드/테스트) 1.개인 프로젝트를 위한 초간단 CI/CD 파이프라인 (GitHub Actions + EC2)이 방법의 핵심 흐름은 매우 간단합니다.git push → GitHub Actions가 푸시 감지 → EC2에 SSH 원격 접속 → git pull 실행 및 서버 재시작GitHub Actions가 직접 EC2 서버에 접속해서 최신 코드를 받아오게 하는 방식입니다. 이 방식의 장점과 단점은 명확합니다.👍 장점🚀 빠른 배포 속도: 전체 프로젝트를 압축해서 전달하는 방식이 아닙니다. git pull을 활용해 변경된 코드만 업데이트하므로 배포 속도가 매우 빠릅니다.⚙️ 간단한 인프라 구조: CI/CD를 위해 필요한 도구는 GitHub Actions 하나뿐입니다. 별도의 Jenkins 서버 등을 구축할 필요가 없어 구.. 2025. 9. 3. 1. CI/CD의 개념,기본 문법 1. CI/CD, 개발자의 반복 작업을 자동화하는 필수 스킬프로젝트에 새로운 기능을 추가하거나 버그를 수정할 때마다 이런 과정을 반복하고 계신가요?수정된 코드를 git push 한다.실제 서비스가 운영되는 서버에 직접 접속한다.최신 코드를 git pull 받는다.필요하다면 프로젝트를 다시 빌드한다.서버를 재시작한다.코드 수정이 잦을수록 이 과정은 점점 더 귀찮고 번거로운 작업이 됩니다. 바로 이런 반복적인 배포 과정을 자동화하기 위해 우리는 CI/CD를 배웁니다.CI/CD를 도입하면, 개발자가 특정 브랜치에 코드를 push하는 것만으로 빌드, 테스트, 배포의 모든 과정이 자동으로 실행되도록 파이프라인을 구축할 수 있습니다. 이를 통해 개발자는 코드에만 집중할 수 있고, 수동 배포 과정에서 발생할 수 있는.. 2025. 9. 3. 이전 1 다음
