이 프로젝트의 진화는 많은 소프트웨어 개발 여행을 반영합니다. 단순하게 시작한 다음 복잡성이 커지는 데 적응합니다. 처음에는 단일 저장소 내에서 큰 모 놀리 식 애플리케이션으로, 건축 리팩토링 및 리포지토리 관리의 여러 단계를 통해 진화했습니다.
Leoloso/Pop 프로젝트는 단일 저장소의 테마와 플러그인을 결합하여 WordPress 사이트로 시작되었습니다. 이것은 초기 개발의 용이성을 제공했지만 비슷한 기능을 가진 더 많은 사이트가 추가됨에 따라 다루기 힘들었습니다. 이 리포는 약 10 개의 사이트를 포함하여 유지 보수 악몽을 만듭니다. 여러 사이트에서 문자열을 검색하고 교체하는 것은 엄청나게 비효율적이었습니다.
확장 성 문제를 해결하기 위해 응용 프로그램은 작곡가가 관리하는 독립적 인 PHP 패키지로 리팩토링되었습니다. 이를 위해서는 패키지 당 하나의 리포지토리로 다중 리포지토리 구조로 전환해야했습니다. 코드 재사용 성과 더 나은 아키텍처를 홍보하는 동안 200 개가 넘는 리포지토리를 관리하는 것은 매우 부담이되었습니다. 수많은 리포지토리에서 버전 관리 종속성 및 조정 풀 요청은 엄청나게 복잡한 것으로 판명되었습니다. 중앙 집중식 관리 시스템의 부족은 효율적인 개발을 방해했습니다.
솔루션은 모든 패키지를 호스팅하는 단일 저장소 인 Monorepo였습니다. 이 간소화 된 버전 컨트롤은 동시 릴리스 및 단순화 된 풀 요청을 허용합니다. 그러나 Packagist는 패키지 출판을위한 개별 리포지토리가 필요하기 때문에, 개발을위한 Monorepo와 분포를위한 별도의 저장소 인 2 개의 가려진 접근법이 채택되었습니다. 이를 위해서는 Monorepo Builder 도구를 사용하여 처리 한 Monorepo를 "분할"하는 프로세스가 필요했습니다. 이 단계는 특히 리팩토링 중에 개발 속도가 크게 향상되었습니다. 맞춤형 GitHub Actions 워크 플로우를 통해 여러 WordPress 플러그인을 동시에 방출하는 기능은 더욱 효율성을 향상시킵니다.
장점에도 불구하고 Monorepo는 모든 패키지에서 단일 라이센스를 시행하고, 대규모 이슈 보드 관리 및 코드 변경 없이도 패키지의 독립 버전 설정을 제시했습니다.
공개 및 개인 코드를 관리해야 할 필요성으로 인해 멀티 모노 포포 아키텍처가 채택되었습니다. 공개 Monorepo (Leoloso/Pop)는 상류 저장소 역할을하는 반면, 개인 Monorepo (Leoloso/Graphqlapi-Pro)는 공개 모노 노를 GIT 하위 모드로 통합하는 다운 스트림 리포지토리 역할을합니다. 이를 통해 개인 저장소는 공공 코드베이스에 액세스하고 확장 할 수 있으므로 단일의 적응 된 워크 플로를 사용하여 공개 및 개인 플러그인 버전의 생성을 가능하게합니다.
그러나이 접근법은 복잡성을 도입합니다. 다운 스트림 리포지토리는 서브 모듈을 명시 적으로 점검해야하며, 워크 플로를 신중하게 관리하고 잠재적으로 업스트림 리포지토리의 변화를 깨뜨려야합니다. 이를 위해서는 의도하지 않은 결과를 방지하기 위해 신중한 코드 검토 및 커뮤니케이션이 필요합니다.
이 프로젝트의 저장소 구조의 진화는 변화하는 요구에 적응하는 것의 중요성을 강조합니다. 각 단계는 장점과 단점을 제공하여 궁극적으로 현재 프로젝트의 요구 사항을 충족하는 멀티 모노로 설정으로 이어집니다. 그러나 미래의 요구는 저장소 관리 전략에서 추가 반복이 필요할 수 있습니다. "최상의"접근 방식은 컨텍스트 의존적으로 남아 있으며 소프트웨어 개발 및 저장소 관리의 반복적 특성을 강조합니다.
위 내용은 단일 리포지토리, 멀티 리포스, 모노레포, 멀티 모노포까지의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
