08-11 06:07
반응형
Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
Tags
- node.js
- ec2 복제
- sequential thinking mcp
- n8n 설치
- observability
- logsdb
- n8n 튜토리얼
- n8n 사용법
- 워크플로우 자동화
- gitlab ci/cd
- vercel 대안
- 셀프 호스팅
- 개발 생산성
- n8n
- Docker
- coolify
- elastic observability
- cursor ide
- ai 에이전트
- 설치 가이드
- colima
- elasticsearch
- 고가용성 아키텍처
- 튜토리얼
- ai assistant
- AI 코딩
- smithery ai
- openrouter
- 퍼블릭 서브넷
- 프라이빗 서브넷
Archives
- Today
- Total
목록ci/cd 파이프라인 (1)
여행하는개발자
.gitlab-ci.yml 하나로 main, dev 브랜치 최신 상태로 동기화하기
핵심 요약: 본 문서는 Git-flow 또는 유사한 브랜치 전략을 사용하는 프로젝트에서, 릴리즈 브랜치(main)의 변경 사항을 개발 브랜치(dev)로 자동으로 역머지(Reverse-Merge)하는 GitLab CI/CD 파이프라인 구축 과정을 단계별로 설명한다. 이를 통해 수동 머지 작업을 제거하고 브랜치 간 정합성을 유지할 수 있다.많은 개발팀이 안정적인 운영을 위해 릴리즈를 위한 main 브랜치와 기능 개발을 위한 dev 브랜치를 분리하여 관리한다. 그러나 릴리즈가 완료된 후 main 브랜치에 적용된 최종 변경사항(예: 긴급 핫픽스, 버전 정보 업데이트)을 다시 dev 브랜치로 가져오는 작업은 번거롭고 잊기 쉬운 과정이다. 이 수동 역머지 과정이 누락되면 두 브랜치 간의 차이가 누적되어 추후 개발 ..
기술
2025. 6. 16. 23:10