☰

Git 프로젝트의 내부 종속성을 관리하시나요?

tag-icon • tag-icon linux command-line python git open-source
Git 프로젝트의 내부 종속성을 관리하시나요?

여러 구성 요소가 있는 Git 프로젝트 관리에 대한 기본적인 질문이 있습니다. 제가 언급하고 있는 프로젝트의 구조는 다음과 같습니다.

project-name
├── cli
├── api
├── webapp
├── docker-compose.yaml
├── README.md
├── LICENCE

내 목표는 유지 관리성과 코드 재사용을 우선시하는 구조를 갖는 것입니다. 따라서 핵심 기능은 모두 Python의 명령줄 인터페이스(cli)에 내장되어 있습니다. 또한 나머지 API를 구축 중이며 목표는 코드를 다시 작성하지 않도록 백그라운드에서 cli를 사용하도록 만드는 것입니다.

내 첫 번째 질문은 다음과 같습니다.이것이 좋은 접근 방식입니까? 저는 AWS와 같은 API 기반(내 접근 방식과 반대)을 기반으로 하는 많은 cli를 사용했습니다. 그리고 ffmpeg와 같은 CLI 기반 API도 사용했습니다. 따라서 제 경우에는 위에서 설명한 대로 진행하는 것이 적합한지 잘 모르겠습니다.

이제 api와 cli를 연결하기 위해 2가지 접근 방식을 염두에 두고 있는데 어느 것이 가장 적절한지 알 수 없습니다.

  • 접근 방식 A: 프로젝트 내부의 상대 경로를 사용하여 API에서 직접 cli를 호출합니다. 하지만 이는 cli가 항상 API와 함께 배송되어야 함을 의미합니까?
  • 접근 방식 B: cli를 Python 패키지로 별도로 빌드하고 저장소에 게시한 다음 API의 요구 사항으로 사용합니다. 이것은 나에게 "더 깔끔해" 보이지만 패키지를 다시 빌드하고 게시해야 하기 때문에 CLI에서 수행한 개선 사항을 즉시 확인할 수 없음을 의미합니다.

두 번째 질문은 다음과 같습니다.API에서 cli를 참조하는 올바른 방법은 무엇입니까? (아니면 다른 방법이 있나요?)

미리 감사드립니다!

답변1

아니요, 여기에는 수많은 문제가 있습니다.

  • API는 CLI를 사용해서는 안 됩니다. CLI는 API를 사용해야 합니다.
  • cli/app/webapp을 하나의 저장소에 넣을 수 있지만 이는 잘못된 디자인으로 간주됩니다."모노레포". 일반적으로 webapp과 CLI가 모두 API를 호출하는 세 가지 다른 저장소가 필요합니다. 하나의 Dockerfile이 거의 의미가 없기 때문에 이것은 또한 더 좋습니다. cli를 패키징하고 있습니까, 아니면 웹앱을 패키징하고 있습니까? cli와 webapp 모두에 Dockerfile이 있을 것으로 예상합니다.
  • 단일 저장소에 비해 마이크로 저장소를 사용하는 것의 장점은 주로 도구입니다. 툴링은 이러한 것들에 대해 훨씬 더 나은 지원을 제공할 것입니다.
  • 마이크로 저장소를 사용하면 cli와 웹앱의 버전이 API와 별도로 관리됩니다. 이는 항상 바람직합니다. 예를 들어, 서로 다른 두 가지 버전의 API를 동시에 사용하여 두 가지 버전의 웹앱 또는 cli를 개발할 수 있습니다. cli 및 webapp에서 API를 가져오면 필요한 다른 외부 종속성과 마찬가지로 작동합니다.

관련 정보