main/master 브랜치 → 운영 서버 ?main/master 브랜치는 실제 서비스에 배포되는 안정 코드다. PR(Pull Request) 리뷰를 거쳐 팀장이 승인한 후에만 머지된다.
운영 배포는 main (또는 master) 브랜치에 PR을 머지할 때 실행된다.
반드시 팀장 승인이 필요하다.
@extends('layouts.app') @section('title', '운영서버 Git 동작원리') @push('styles') @endpush @section('content')
git push 후 코드가 서버에 반영되기까지 — 배포 자동화 파이프라인 가이드
한 줄 요약: git push 하는 방법은 전혀 바뀌지 않았다. 바뀐 것은 push 이후 서버에 코드가 반영되는 과정이 수동 → 자동으로 변경된 것이다.
Git 원격 저장소 (origin)
git remote -v 결과 동일개발자 작업 흐름
git add → commit → push 동일이전 (수동)
git pullcomposer installphp artisan migrate현재 (Jenkins CI/CD)
| 프로젝트 | 로컬 경로 | Origin URL | 현재 브랜치 |
|---|---|---|---|
| MNG | /home/aweso/sam/mng | http://114.203.209.83:3000/SamProject/sam-manage.git | develop |
| API | /home/aweso/sam/api | http://114.203.209.83:3000/SamProject/sam-api.git | develop |
| React | /home/aweso/sam/react | http://114.203.209.83:3000/SamProject/sam-react-prod.git | develop |
Gitea 웹 UI: http://114.203.209.83:3000
브라우저에서 접속하면 저장소 목록, 커밋 이력, PR(Pull Request) 관리 등을 할 수 있다.
origin URL의 IP와 포트가 동일하다 — 즉, 같은 서버다.
중요: Gitea 서버 = 개발 서버 (114.203.209.83)이다. 같은 서버에서 Gitea (포트 3000)와 Jenkins (포트 8080)를 모두 운영한다. git push를 하면 Gitea가 수신하고, Gitea가 Jenkins에 Webhook으로 알린다.
모든 단계를 사람이 직접 수행
개발자가 git push를 한 뒤, 팀장이 서버에 SSH로 접속하여
git pull →
composer install →
php artisan migrate →
config:clear를 순서대로 실행했다.
문제점: 사람이 실수로 단계를 빼먹거나, 잘못된 서버에서 실행하거나, 팀장 부재 시 배포가 지연되는 문제가 있었다.
push 후 자동으로 모든 단계 수행
개발자가 git push만 하면, Gitea가 Jenkins에 알리고, Jenkins가 자동으로 pull → install → migrate → cache clear를 수행한다. 사람이 서버에 접속할 필요가 없다.
장점: 실수 방지, 배포 속도 향상, 팀장 부재에도 배포 가능, 빌드 실패 시 자동으로 알림을 받을 수 있다.
Checkout
Gitea에서 최신 코드를 가져온다 (git pull)
Install
composer install — PHP 의존성 동기화
Migrate
php artisan migrate — DB 스키마 변경 적용 (API만)
Cache Clear
php artisan config:clear && cache:clear — 캐시된 설정 갱신
Queue 재시작
supervisorctl restart — 큐 워커 재시작 (변경사항 반영)
보고
빌드 결과를 Gitea에 보고 (성공/실패 표시)
React (Next.js) 배포는 다르다:
React는 빌드가 필요하므로 Jenkins에서 npm install → npm run build →
결과물을 tar.gz로 묶어 서버에 전송 → 압축 해제 → Node.js 재시작 순서로 배포한다.
서버에서 직접 빌드하지 않는다 (메모리 부족 방지).
일상 개발 작업은 모두 develop 브랜치에서 진행한다.
push 시 Jenkins가 자동으로 개발 서버에 배포한다.
별도의 승인이 필요 없다.
운영 배포는 main (또는 master) 브랜치에 PR을 머지할 때 실행된다.
반드시 팀장 승인이 필요하다.
| 브랜치 | 배포 대상 | 트리거 | 승인 |
|---|---|---|---|
| feature/* | 배포 안 함 | — | — |
| develop | 개발 서버 (dev.codebridge-x.com) |
Push 시 자동 | 불필요 |
| main/master | 운영 서버 (codebridge-x.com) |
PR 머지 시 | 팀장 승인 필수 |
| 서비스 | 로컬 (Docker) | 개발 서버 | 운영 서버 |
|---|---|---|---|
| React (사용자) | dev.sam.kr | dev.codebridge-x.com | codebridge-x.com |
| API | api.sam.kr | api.dev.codebridge-x.com | api.codebridge-x.com |
| MNG (관리자) | mng.sam.kr | admin.codebridge-x.com | mng.codebridge-x.com |
| Sales | sales.sam.kr | sales.dev.codebridge-x.com | sales.codebridge-x.com |
| 5130 (레거시) | 5130.sam.kr | — | — |
로컬 도메인: *.sam.kr은 로컬 개발 전용이며, /etc/hosts에 등록되어 있다.
실제 인터넷에서 접근할 수 없다.
Q. git origin URL이 바뀌었나요?
아니요. origin URL은 전혀 변경되지 않았습니다.
git remote -v로 확인하면 동일한 Gitea 주소가 나옵니다.
Q. push 후 서버 반영이 안 되면?
Jenkins 빌드가 실패했을 수 있습니다. http://114.203.209.83:8080에서 빌드 결과를 확인하세요.
실패 원인은 대부분 코드 오류(syntax error)이거나 마이그레이션 충돌입니다.
Q. Jenkins 장애 시 수동 배포는?
비상 절차로만 사용합니다. 팀장이 서버에 SSH로 접속하여 수동으로
git pull → composer install → migrate → config:clear를 실행합니다.
Q. 운영 서버에 바로 push할 수 있나요?
아니요. 운영 서버 배포는 반드시 develop → main/master PR을 통해서만 가능합니다.
팀장이 코드를 리뷰하고 승인한 후에만 머지됩니다.
Q. feature 브랜치는 어떻게 배포하나요?
feature 브랜치는 자동 배포 대상이 아닙니다.
feature/* → develop으로 머지한 후
develop을 push하면 개발 서버에 자동 배포됩니다.