배포 파이프라인 하나 만들려고 티켓을 몇 장 쓰시나요? GitLab·Argo CD·Jenkins를 한 번에 잇는 DevOps Code Foundry
한 번의 요청을 GitLab → Argo CD → Jenkins → Kubernetes 배포 흐름으로 바꾸는 셀프서비스 플랫폼 새 서비스 하나를 만들기 위해 티켓을 몇 장이나 쓰고 있나요? 저장소 생성 요청, 브랜치 보호 설정, CI/CD 변수 등록, Argo CD Application 생성, Jenkins 잡 실행, 배포 상태 확인까지. 개발을 시작하기도 전에 여러 팀의 답변을 기다리는 일이 익숙해졌다면 문제는 개발자의 속도가 아닙니다. 진짜 병목은 서비스마다 반복되는 배포 파이프라인 준비 작업입니다. 사람이 매번 같은 설정을 옮겨 적으면 리드타임은 길어지고, 누락과 표준 편차가 쌓이며, 실패했을 때 어디까지 만들어졌는지도 알기 어려워집니다. 그래서 만든 것이 devops-code-foundry입니다. 개발자가 셀프서비스 포털에 앱 이름·팀·템플릿을 입력하면 GitLab 프로젝트부터 GitOps 매니페스트, Jenkins 초기 실행까지 자동으로 프로비저닝하는 플랫폼입니다. 한 줄로 요약하면 devops-code-foundry는 단순한 배포 스크립트가 아닙니다. 플랫폼 팀의 반복 작업을 멱등한 워크플로우로 바꾸고, 개발팀이 기다리지 않고 표준 파이프라인을 만들게 하는 셀프서비스 DevOps 플랫폼 입니다. 개발자 요청 ↓ 즉시 request_id 반환 FastAPI — 인증 · 검증 · 정책 적용 ↓ Argo Workflows — 상태 · 재시도 · 보상 제어 ↓ GitLab → Argo CD(GitOps) → Jenkins ↓ 대상 Kubernetes 클러스터에 애플리케이션 배포 왜 ‘자동화 스크립트’가 아니라 플랫폼인가? 스크립트는 실행한 사람에게만 편리할 수 있습니다. 플랫폼은 입력 규칙, 진행 상태, 실패 복구, 권한, 감사 기록까지 조직의 공통 방식으로 만듭니다. 이 프로젝트가 해결하려는 차이는 다음과 같습니다. 구분 수동 요청 방식 Code Foundry 시작 팀별 티켓과 메시지 포...