cibseven-devflows

개발자 워크플로우를 로컬 CIB seven 엔진에서 BPMN 프로세스로 실행하고, MCP 서버를 통해 Claude Code와 같은 AI 코딩 에이전트에서 구동하세요.

버전 0.1.0에는 릴리스 의식이라는 하나의 워크플로우가 포함되어 있습니다. 품질 게이트를 실행하고, 사람에게 승인을 요청하고, 태그를 달고, 게시합니다. 이 저장소는 그 프로세스를 스스로 실행하여 자체 v0.1.0을 만들었습니다.

왜 필요한가

릴리스를 만드는 것은 중간에 사람의 결정이 필요한 프로세스입니다. 일반적으로 그 프로세스는 누군가의 머릿속과 터미널 스크롤백에만 존재합니다. 게이트가 실행되었다는 것, 사람이 승인했다는 것, 무엇이 게시되었는지를 기록하는 것은 없습니다.

프로세스 엔진은 바로 그런 형태의 문제에 딱 맞는 도구입니다. CIB seven은 상태를 유지하고, 기록을 보관하며, 사람을 기다리는 방법을 알고 있습니다. 실제 작업은 여전히 여러분의 머신에서 수행되며, AI 에이전트가 실행을 시작하고 지켜볼 수는 있지만 승인을 건너뛸 수는 없습니다. 승인은 프롬프트의 약속이 아니라 프로세스의 한 단계이기 때문입니다.

Related MCP server: jt-mcp-server

아키텍처

flowchart LR
    agent["Claude Code<br/>(any MCP client)"] -- stdio --> mcpserver["devflows-mcp"]
    mcpserver -- REST --> engine["CIB seven engine<br/>Docker, H2, localhost:8080"]
    human["You, in the web UI"] -- approve --> engine
    engine -- fetchAndLock --> worker["devflows-worker"]
    worker -- shell --> repo["your repository<br/>pytest, ruff, git, gh"]

엔진은 셸 명령을 실행하지 않으며 저장소를 건드리지 않습니다. 작업을 나눠줄 뿐이며, 여러분의 머신에 있는 워커가 그것을 폴링하여 수행합니다. 이것은 표준 Camunda 7 외부 태스크 패턴이며, 프로세스가 개발자 머신을 안전하게 구동하도록 만드는 요소입니다.

릴리스 프로세스

flowchart LR
    start((start)) --> gates["Run gates<br/><i>devflows.gates</i>"]
    gates --> q1{Gates passed?}
    q1 -- no --> failed((Gates failed))
    q1 -- yes --> approve["Approve release<br/><i>user task</i>"]
    approve --> q2{Approved?}
    q2 -- stop --> rejected((Release rejected))
    q2 -- ship --> tag["Tag<br/><i>devflows.tag</i>"]
    tag --> publish["Publish<br/><i>devflows.publish</i>"]
    publish --> released((Released))

토픽 이름이 있는 세 개의 사각형은 외부 태스크입니다. "Approve release"는 BPMN 사용자 태스크이므로 대기하고, 엔진이 재시작되어도 유지되며, 웹 UI 또는 approve_gate MCP 도구를 통해 응답할 수 있습니다.

dry_run=true는 게이트를 실제로 실행하되 그 외에는 아무것도 변경하지 않습니다. 태그도, 푸시도, 릴리스도 없습니다.

빠른 시작

docker compose -f engine/docker-compose.yml up -d

uv sync

uv run pytest -m "not integration" && uv run ruff check .

프로세스 배포(엔진당 한 번):

curl -s -X POST http://localhost:8080/engine-rest/deployment/create -F "deployment-name=cibseven-devflows" -F "release.bpmn=@processes/release.bpmn"

워커를 시작하고 별도 터미널에서 계속 실행합니다:

uv run devflows-worker

이 저장소의 드라이 릴리스를 시작합니다. repo_path를 이 저장소의 절대 경로로 바꾸세요. Windows에서도 슬래시를 사용하세요(C:/Users/you/repos/cibseven-devflows). 슬래시는 작동하며 백슬래시 이스케이프 문제를 피할 수 있습니다.

curl -s -X POST http://localhost:8080/engine-rest/process-definition/key/devflows-release/start -H "Content-Type: application/json" -d '{"variables":{"repo_path":{"value":"ABSOLUTE/PATH/TO/cibseven-devflows","type":"String"},"version":{"value":"0.2.0","type":"String"},"dry_run":{"value":true,"type":"Boolean"}}}'

그런 다음 http://localhost:8080/webapp/#/seven/auth/tasks에서 demo / demo로 승인합니다: My Group Tasks 필터, Approve release 클레임, approve 체크, 제출.

실제로는 curl 대신 MCP 서버를 통해 실행을 시작합니다. 전체 안내는 docs/DEMO.md를 참조하세요.

devflows.yaml

각 저장소는 루트의 devflows.yaml에 자체 릴리스를 설명합니다:

gates:
  - name: tests
    run: uv run pytest -q
  - name: lint
    run: uv run ruff check .

tag:
  format: "v{version}"

publish:
  run: gh release create v{version} --generate-notes

알 수 없는 최상위 키는 무시되므로, 최신 버전의 devflows가 이전 파일을 깨뜨리지 않고 단계를 추가할 수 있습니다.

MCP 도구

devflows-mcp는 stdio를 통해 MCP를 사용하며 모든 MCP 클라이언트에서 작동합니다.

모든 도구는 ok 플래그가 있는 딕셔너리를 반환하며, ok가 false이면 error 문자열을 반환합니다. 호출자가 실패를 사람에게 설명해야 하는 언어 모델이므로 어떤 도구도 예외를 발생시키지 않습니다.

Claude Code에서 사용하기

plugin/은 동일한 서버를 중심으로 한 Claude Code 플러그인입니다:

• plugin/.mcp.json은 uv run으로 devflows-mcp를 시작합니다.

• plugin/skills/release-with-devflows/SKILL.md는 에이전트에게 엔진을 언제 사용하고 어떤 순서로 도구를 호출할지 알려줍니다. 승인 전에 멈춰서 물어봐야 한다는 규칙을 포함합니다.

• plugin/commands/release.md는 /devflows:release <version> [--real]을 제공합니다.

다른 MCP 클라이언트에 서버를 직접 연결하려면:

{
  "mcpServers": {
    "cibseven-devflows": {
      "command": "uv",
      "args": ["run", "devflows-mcp"]
    }
  }
}

구성

보안

이 프로젝트에 대해 의도된 두 가지가 있으며, 둘 다 로컬 머신에서 실행된다고 가정합니다:

• 엔진에 인증이 없습니다. localhost:8080의 REST API는 연결할 수 있는 모든 것을 수락합니다. 제어할 수 없는 네트워크에 해당 포트를 노출하지 마십시오.

• 워커는 셸 명령을 실행합니다. 이 명령은 릴리스를 요청한 저장소의 devflows.yaml에서 오며, 해당 저장소에서 사용자로 실행되며, 직접 입력하는 것과 동일한 명령입니다. 신뢰하는 저장소에서만 실행하십시오.

클라우드 서비스, 원격 측정, gh가 이미 가지고 있는 GitHub 자격 증명 외의 계정은 없습니다.

저장소 구조

요구 사항

• 엔진용 Docker Desktop

• Python 3.12 및 uv

• 태그 및 게시 단계를 위한 인증된 git 및 gh

• BPMN 다이어그램을 편집하려면 Camunda Modeler 5.x(선택 사항). processes/release.bpmn을 Camunda 7 다이어그램으로 여세요.

라이선스

Apache License 2.0. LICENSE를 참조하세요.