피드로 돌아가기
From Local Project to CI/CD Pipeline: Two Git Workflows (Simple vs Git Flow)
Dev.toDev.to
DevOps

단일 main 브랜치 워크플로우로 CI/CD 구축 시간을 단축하고 실수를 줄임

From Local Project to CI/CD Pipeline: Two Git Workflows (Simple vs Git Flow)

lajibolala2026년 4월 3일6beginner

Context

새로운 VM이나 시간 제약이 있는 환경에서 CI/CD 파이프라인을 구축할 때 복잡한 Git 워크플로우를 적용하고 싶지만, 실제로는 복잡성이 더 많은 문제를 야기함. Git Flow 같은 워크플로우는 브랜치 실수, 파이프라인 미실행, 디버깅 시간 낭비 등을 초래함.

Technical Solution

  • Single Branch Workflow: 모든 변경 작업을 main 브랜치 하나에서 처리하여 브랜치 관리 복잡도를 제거함
  • 점진적 푸시 전략: 프로젝트 임포트 → .gitignore → Dockerfile → sonar-project.properties → .gitlab-ci.yml 순서로 단계별로 커밋함
  • GitLab CI 설정: only에 실행 대상 브랜치를 명시적으로 지정하여 의도치 않은 파이프라인 실행을 방지함
  • 로컬 우선 테스트: 원격 푸시 전에 pip install, pytest, curl 테스트로 로컬에서 동작을 확인함
  • .gitignore 관리: pycache, .venv, .env, .sonar 등을 제외하여 불필요한 파일 업로드를 차단함

Impact

복잡한 브랜칭 구조를 배제하여 파이프라인 구축 시작부터 실패 포인트와 디버깅 시간이 감소함.

Key Takeaway

CI/CD는 복잡한 워크플로우가 아니라 신뢰성, 반복 가능성, 전달에 대한 제어력임. 처음부터 단순하게 시작하여 동작하도록 만든 후 개선해야 함.


제한된 환경에서 GitLab CI/CD를 구축할 때 main 브랜치만 사용하고, 프로젝트 임포트 후 .gitignore와 Dockerfile을 순차적으로 푸시한 뒤 마지막에 .gitlab-ci.yml을 추가하는 것이 실수를 줄이는 가장 안전한 방법임

원문 읽기