"종속성 관리"에 대한 사례를 어떻게 만들 수 있습니까?

현재 빌드 (ala Maven, Ivy, NuGet)에 대한 종속성 관리를 채택하고 공유 모듈에 대한 내부 저장소를 만드는 사례를 만들려고 노력 중입니다. 이 빌드 기술의 주요 판매 포인트는 무엇입니까? 내가 지금까지 가지고있는 것들 :

공유 모듈, 특히 버전 업그레이드를 배포하고 가져 오는 프로세스가 쉬워집니다.
공유 모듈의 종속성을 정확하게 문서화해야합니다.
소스 제어에서 공유 모듈을 제거하고 체크 아웃 / 체크인 속도를 높이고 단순화합니다 _{(20 개 이상의 라이브러리가있는 응용 프로그램을 사용하는 경우 이는 실제 요소 임)} .
조직에서 어떤 타사 라이브러리가 사용되는지에 대해 더 많은 제어 또는 인식을 허용합니다.

누락 된 판매 포인트가 있습니까? 개선 지표를 제공하는 연구 나 기사가 있습니까?

dependency-management

— 가로 질러 가다
소스

나는 당신이 그것을 못 박았다 생각합니다.

— Mike Partridge

나는 깨진 Maven 설정에 낭비 된 많은 시간을 되돌려 보내지 않을 것입니다. 나는 좋은 의도에 상관없이, 대기업에서 결국 당신이 속이 빈 껍질이 될 때까지 당신의 삶을 빨아들이는 유지되지 않는 혼란이 될 것이라고 확신했습니다.

— MrFox

@suslik "깨진 Maven"설정이 무엇인지 자세히 설명 하시겠습니까?

— 앤드류 T 피넬

@AndrewFinnell 빌드를 컴파일하기 위해 가져와야하는 5 개의 그룹이 프로젝트에 참여하고 있으며, 조정이 좋지 않아서 모든 버전의 라이브러리에 따라 모든 사람이 생깁니다. 그런 다음 프로젝트 중 하나가 아직 '릴리스'되지 않았지만 (아무도 말하지 않았습니다!) 만족해야 할 종속성이 있습니다. 이것은``추정 된 ''것은 아니지만 자동 해상도로 인해 너무 쉽습니다. 모든 사람이 svn에서 유지 보수 할 / libs 디렉토리를 가지고 있다면, 사람들이 손을 떼기 전에 중지하고 질문을해야합니다.

— MrFox

@MrFox 실제로 Maven 의존성 해결이 아니라 조정이 잘못 되었기 때문입니다. 나는 같은 상황을 경험 한 나는 메이븐의 팬이 아니에요,하지만, 도구를 조기 출시 등의 인간 관련 문제를 해결하기 위해 안된다는 생각 테스트, 정비 불량 등의 부족, 의사 소통의 부족

— scriptin을

답변:

나는 긍정적으로 100 % 확신하지 못합니다. 몇 가지 부정적인 점이 있습니다.

종종 불안정한 타사 서버 / 엔드 포인트에 종속성을 추가하게됩니다.

일부 종속성의 저장소가 삭제되거나 이동 된 bower와 함께 발생했습니다. 그래서 새로운 개발자가 와서 내 저장소를 복제하고 bower install액세스 할 수없는 저장소에 대한 오류를 얻습니다. 대신 타사 코드를 내 저장소에 체크인하면 문제가 사라집니다.

이것은 운영하는 서버에 보관 된 사본에서 뎁을 가져 오는 경우 OP가 제안한 것처럼 해결됩니다.
멍청한 놈들을 위해 더 열심히.

나는 명령 줄 경험이 거의없는 미술 학생들과 함께 일합니다. 그들은 Processing, arduino, Unity3D로 예술을 만들고 기술 지식이 거의 없습니다. 그들은 내가 쓴 HTML5 / JavaScript를 사용하고 싶었습니다. 정자 때문에 단계
1. github에서 repo 우편 번호를 다운로드하십시오 (github의 모든 repo의 오른쪽에 있습니다 .git은 모르기 때문에)
2. 노드 다운로드 및 설치 (NPM을 실행하여 bower 설치 가능)
3. git 또는 msysgit을 설치하십시오 (bower가 필요하고 많은 학생들의 컴퓨터에 설치되어 있지 않기 때문에)
4. 바우어 설치 ( npm install -g bower)
5. bower install (마지막으로 의존성을 얻기 위해)
파일을 github 저장소에 체크인하면 2-5 단계를 모두 삭제할 수 있습니다. 그 단계는 아마도 당신과 나에게 매우 쉬운 것처럼 들릴 것입니다. 학생들에게 그들은 매우 혼란 스러웠으며 어디에서 무엇을해야하는지에 대해 배우는 것이 좋을지 모르지만 수업 주제와 완전히 직교하여 빨리 잊혀 질 수 있는 모든 단계를 알고 싶어했습니다 .
당기면 또 다른 단계가 추가됩니다.

나는 여러 번 일을 git pull origin master한 다음 내 코드를 테스트 bower install 하고 최신 뎁을 얻기 위해 입력해야한다는 것을 기억하는 데 5 ~ 10 분이 걸립니다 . 풀 스크립트 후크로 쉽게 해결할 수 있다고 확신합니다.
자식 분기를 더 어렵게 만듭니다.

두 가지 가지의 깊이가 다르면 문제가 생깁니다. 나는 당신이 bower install매번 입력 할 수 있다고 가정합니다 git checkout. 속도가 너무 큽니다.

당신의 긍정적 인 측면에서 나는 그들 각각에 대한 반대 사례가 있다고 생각합니다.

공유 모듈, 특히 버전 업그레이드를 배포하고 가져 오는 프로세스가 쉬워집니다.

대 무엇? 배포하기가 쉽지 않습니다. 20 개 대신 하나의 저장소를 당기는 것은 쉽지 않으며 실패 할 가능성이 높습니다. 위의 # 1 참조

소스 제어에서 공유 모듈을 제거하고 체크 아웃 / 체크인 속도를 높이고 단순화합니다 (라이브러리가 20 개 이상인 응용 프로그램을 사용하는 경우 이는 중요한 요소 임).

반대로 이것은 수정을 위해 다른 사람에게 의존한다는 것을 의미합니다. 당신의 뎁이 써드 파티 소스에서 뽑아 내고 버그를 수정해야한다면 패치를 적용 할 때까지 기다려야합니다. 더 나쁜 것은 아마도 원하는 버전과 패치를 가져갈 수는 없으며 프로젝트와 호환되지 않는 최신 버전을 사용해야한다는 것입니다.

저장소를 개별적으로 복제하여 문제를 해결할 수 있으며 프로젝트 뎁을 사본으로 지정합니다. 그런 다음 사본에 수정 사항을 적용하십시오. 물론 소스를 저장소에 복사하면 그렇게 할 수도 있습니다.

조직에서 어떤 타사 라이브러리가 사용되는지에 대해 더 많은 제어 또는 인식을 허용합니다.

논쟁의 여지가있는 것 같습니다. 개발자가 타사 라이브러리를 아래의 자체 폴더에 넣으면됩니다 <ProjectRoot>/3rdparty/<nameOfDep>. 타사 라이브러리가 사용되는 것을 쉽게 볼 수 있습니다.

나는 긍정적 인 것이 없다고 말하는 것이 아닙니다. 내가 마지막으로 한 팀은 100 개 이상의 타사 뎁을 가졌다. 나는 그것이 모든 장미가 아니라고 지적하고 있습니다. 예를 들어 필요에 따라 정자를 제거해야하는지 평가하고 있습니다.

— gman
소스

와우, 많은 부정적인 투표와 그들에 대한 단일 정당화가 아닙니다. 잘 했어! :(

— gman

나는 bower를 사용한 적이 없지만 install체크 아웃 할 때마다 디자인 결함이있는 것처럼 보입니다. 프로젝트를 빌드 할 때 구성을 확인해야합니다. 변경 사항이 있으면 처음부터 다시 빌드해야합니다. 또한 리 포지션 이동은 코드가있는 실제 리포지토리가 아닌 아티팩트를 저장하는 Maven 저장소에서 아티팩트를 가져 오기 때문에 Maven과 관련이 없습니다. 당신은 변경할 수 있습니다 artifactId및 groupId귀하의 유물의 다음 버전에서 당신은 메이븐 저장소에 게시합니다. 따라서 포인트 1과 4는 특히 Maven과 관련이 없습니다. # 3은 mvn clean(때때로) 대체 될 수 있습니다

— scriptin

사실이지만, # 2는 단점이 아닙니다. 트레이드 오프입니다. 물론 도구를 배워야합니다! 예를 들어, Git은 이해하기가 쉽지 않지만 멍청한 놈 때문에 포기하지는 않을 것입니다.

— scriptin

Twelve Factor App 살펴보기

특히 의존성 에 대해 그들이 무엇을 말해야하는지 읽어보십시오 . 좋은 디자인은 의존성을 찾는 선언적 메커니즘을 제공한다는 것을 알 수 있습니다. Java에서는 종종 Maven을 통해 실현됩니다. 아이비와 NuGet은 잘 작동하지만 Maven은 현재이 분야의 리더이며 아이비는 확실히 열심히 일하고 있습니다.

Maven 릴리스 프로세스 (공식 릴리스가 준비 될 때까지 스냅 샷 개발, 이전 릴리스를 덮어 쓰려고 시도하지 말고 Nexus 또는 Artifactory와 같은 적절한 저장소 관리자를 사용하지 마십시오)를 준수하는 경우 빌드 프로세스가 멋지게 진행되어야합니다.

확고한 선언적 빌드 프로세스가 완료되면 Jenkins 와의 지속적인 통합 , Sonar 와의 지속적인 코드 분석과 같은 다른 모범 사례를 열 수 있으며 git을 사용하여 더 나은 버전 제어 분기 전략을 찾고 있습니다.

위의 각각은 Maven 인 코어를 기반으로합니다. 요즘은 생각할 필요가없는 결정입니다.

— 게리 로우
소스

나는 Twelve Factor App을 보았지만 매우 논쟁 적이며 아주 조금만 관련이 있습니다. 또한 Maven을 푸시해도 의존성 주입이 필요한 이유를 설명하는 데 도움이되지 않습니다. 전반적 으로이 답변은 Dependency Injection을 판매하는 데 도움이되지 않으며 빌드 프로세스에 필요한 많은 것을 알려줍니다.

— C. Ross

종속성 주입 (디자인 패턴)은 종속성 관리 (빌드 패턴)가 아닙니다. 귀하는 이미 귀하의 질문에서 가장 중요한 측면을 모두 다루었습니다. 당신의 팀이 그 말을들은 후에도 여전히 설득력이 필요하다면, 의존성 관리가 어떤 결과를 가져 오는지를 보는 것이 최종 확신이되어야합니다.

— 게리 로우

그리고 우리의 상위 10 개 목록 중 1 위는 ...

(드럼 롤)

모든 개발자는 정확히 동일한 버전의 모든 종속성을 사용하므로 프로덕션 환경에 배포 할 대상을 궁금 할 필요가 없습니다.

— 로스 패터슨
소스

의존성을 체크인하는 것과 다른 점은 무엇입니까? 실제로 종속성을 확인하지 않으면 일부 타사가 배포판을 손상시킬 위험이 있습니다. 일부 bower dep이 누군가 삭제하거나 이름을 바꾼 repo를 가리키는 곳 에서이 문제가 두 번 이상 발생했습니다. 방금 소스를 리포지토리에 복사하면 문제가 해결됩니다.

— gman