내부 엔터프라이즈 개발에 Nuget을 어떻게 사용해야합니까?

내부 엔터프라이즈 개발에 Nuget을 어떻게 사용해야합니까?

---

내부 개발을 위해 Nuget을 사용하여 팀간에 코드를 공유 할 수 있습니다. 그러나 한 사람이 동시에 여러 너겟 패키지에 배포 될 코드를 작업 할 때 문제가 발생합니다. 예를 들어

A는 C에 의존하는 B에 의존합니다.

A, B 및 C는 아티팩트를 Nuget에 푸시하고 이것이 A, B 및 C 간의 종속성을 관리하는 방법입니다. 문제는 개발자가 C를 변경하고 이러한 변경 사항이 A에 반영되는 것을 빠르게 확인하려는 경우 다음 과정을 거쳐야합니다.

1. C에서 변경하십시오.
2. 변경 사항을 자식에게 푸시
3. CI는 C에 대한 변경 사항을 선택하고 새 너겟 패키지를 빌드 및 배포합니다.
4. B로 이동하여 nuget update package 명령을 사용하여 C에 대한 참조를 업데이트합니다.
5. packages.config 파일에 대한 변경 사항을 git까지 푸시합니다.
6. CI는 B에 대한 변경 사항을 선택하고 B에 대한 새 너겟 패키지를 빌드 및 배포합니다.
7. 이제 A를 열고 B 및 Nuget 업데이트 패키지에 대한 참조를 변경하십시오.
8. A를 변경하여 B (및 전 이적으로 C)의 변경 사항을 따르십시오.

이것은 매우 고통스러워 보이며 일부 개발자는 내부적으로 개발 된 코드에 대해 Nuget을 선택하는 것에 의문을 제기합니다. 모두가 여전히 외부 패키지를 소비하는 것을 좋아합니다.

Nuget을 내부적으로 사용하기위한 더 나은 워크 플로가 있습니까?

---

우리 회사에서는 다음 설정으로 계단식 업데이트 문제를 해결했습니다. 먼저 NuGet 리포지토리 및 빌드 서버에 대한 다음 설정이 있습니다.

• 회사에 대해 게시 된 모든 패키지를 보관하는 내부 NuGet 리포지토리가 있습니다. 이 저장소는 서버 중 하나의 공유 디렉토리입니다.

• 각 개발자는 로컬 NuGet 패키지 리포지토리 역할을하는 자체 머신에 하나 이상의 디렉터리를 가질 수 있지만 반드시 가질 필요는 없습니다. 개발자는 사용자 별 NuGet 구성 을 사용하여 NuGet이 패키지를 찾기 위해 패키지 리포지토리를 검색하는 순서를 제어 할 수 있습니다.

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <packageRestore>
      <add key="enabled" value="True" />
    </packageRestore>
    <packageSources>
      <add key="Dev" value="D:\dev\testpackages" />
      <add key="Company" value="<UNC_ADDRESS_COMPANY_REPOSITORY>" />
      <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
      <add key="All" value="(Aggregate source)" />
    </activePackageSource>
  </configuration>
  

• 모든 솔루션에는 자동 패키지 복원이 켜져 있으므로 버전 제어 시스템에 패키지를 커밋 할 필요가 없습니다.

• 개발자는 4 개의 버전 번호 중 3 개만 제어합니다. 예를 들어 버전이 <MAJOR>.<MINOR>.<BUILD>.<REVISION>다음 버전 이면 개발자는 메이저, 마이너 및 빌드 번호 만 변경할 수 있으며, 버전 번호는 빌드 번호 인 빌드 서버에서 수행 한 빌드를 제외하고 0으로 설정됩니다. 빌드의. 이는 메이저, 마이너 및 빌드 번호로 구성된 주어진 버전에 대해 빌드 서버가 항상 더 높은 버전 번호를 생성한다는 것을 의미하기 때문에 중요합니다. 이것은 NuGet이 회사 패키지 리포지토리 (빌드 서버를 통해서만 패키지를 가져옴)에서 오는 패키지 버전을 선호 함을 의미합니다.

기본 라이브러리 중 하나를 변경하기 위해 두 가지 가능한 프로세스가 사용됩니다. 첫 번째 프로세스는 다음과 같습니다.

1. 기본 라이브러리 (A)를 변경합니다. 필요한 경우 (A) 버전을 업데이트하십시오.
2. MsBuild 스크립트를 실행하여 바이너리를 빌드하고 (A)의 NuGet 패키지를 만듭니다.
3. 새 NuGet 패키지를 로컬 컴퓨터의 패키지 리포지토리에 복사합니다.
4. 종속 프로젝트에서 (B) 로컬 컴퓨터 패키지 저장소에 방금 배치 된 (A)의 새 패키지로 업그레이드합니다 (회사 전체 저장소 또는 NuGet.org에서 사용 가능한 버전보다 더 높은 버전이어야 함).
5. (B)로 변경합니다.

(A)에 더 많은 변경이 필요한 경우 1,2 및 3 단계를 반복 한 다음 (B)의 작업 디렉토리에서 (A)의 패키지를 삭제하십시오. 다음에 빌드가 실행될 때 NuGet은 (A)의 특정 버전을 찾아 로컬 머신 저장소에서 찾아서 다시 가져옵니다. NuGet 캐시 는 NuGet처럼 보이지만이 프로세스를 방해 할 수 있습니다. 동일한 시스템 (?)에서 가져온 패키지를 캐시 할 수 없습니다.

변경이 완료되면 다음을 수행합니다.

1. (A)에 변경 사항을 적용합니다. 빌드 서버는 통합 빌드를 실행하여 모든 것이 작동하는지 확인합니다.
2. 바이너리를 빌드하고 NuGet 패키지를 회사 전체 NuGet 리포지토리로 푸시하는 릴리스 빌드를 실행하도록 빌드 서버에 지시합니다.
3. In (B), upgrade to the latest version of (A) (which should have a higher version number than the test package because the test package should have version a.b.c.0 while the newly build version in the company-wide repository should be a.b.c. where > 0
4. Commit the changes to (B). Wait for the build server to finish the integration tests
5. Tell the build server to run the release build for (B).

Another way of doing the development work is by taking the following steps

1. Make the changes to the base library (A). Update the version of (A) if required.
2. Build the binaries
3. Copy the binaries over to the location where NuGet unpacks the package of (A) for project (B) (e.g. c:\mysource\projectB\packages\ProjectA.1.2.3.4)
4. Make the required changes to project (B)

The commit process is still the same, project (A) needs to be committed first, and in project (B) the NuGet reference to (A) needs to be upgraded.

The first approach is slightly neater because this process also warns if there are faults in the NuGet package of (A) (e.g. forgotten to add a new assembly) while in the second process the developer won't know until after the package for (A) has been published.

---

You have two choices here:

1. Run an instance of NuGet Gallery within your organisation. This is the code which runs nuget.org
2. Get a license for Artifactory Pro, which has in-built Nuget support and acts as a Nuget repository.

I have used both, and #1 is a reasonable choice to start with, but NuGet Galley is optimised and designed for nuget.org, not on-premise/enterprise use, so things like deleting packages is a pain (hand-rolled SQL required).

I'd say that you should pay the (low) license fee for Artifactory Pro - it's an excellent product, and the JFrog team are really keen and switched on.

You should not be using nuget.org for internal/enterprise packages; nuget.org is designed for 3rd party/open source libraries, not internal build dependencies.

EDIT: in terms of workflow, why are you putting shared code into multiple packages? If the code needs to be shared, it needs to go in its own separate package.

EDIT 2: To speed up the code change workflow for the developer, you can use nuget.exe (the command-line client) and use command-line accessible builds, so you can target a "developer" build run. Then in your "developer" build (as opposed to the CI build) you specify -Source as a local path (e.g. nuget install B -Source C:\Code\B) when you want to pull the newly-updated B as a dependency and build against that; likewise for C or other local, newly-updated packages. Then when A, B, and C all build fine, you can git push all of them (in reverse dependency order), and let CI do its thing.

However, you also should question whether your package separation is really appropriate if you have to do this build 'dance' often, as this suggests that all the code should be in a single package, or possibly split along different lines in separate packages. A key feature of a well-defined package is that it should not cause ripple effects on other packages, certainly not if you are using Semantic Versioning effectively.

Edit 3 Some clarifications requested by marcelo-oliveira: "command-line accessible builds" are builds which can take place entirely from the command-line, without using Visual Studio, usually via batch files. A "developer build" is a build which a developer runs from her workstation, as opposed to the CI build which runs on the CI server (both builds should essentially be the same).

---

If A, B and C are under the same solution, you can create NuGet packages for them in a single build.

Just make sure that the using package has the new version number (assuming your build doesn't randomly change it) of the package it depends on.

If A, B and C are intentionally under different solutions e.g. A is under an infrastructure solution and B is under a product solution, then the only suggestion I have for you is to define your CI builds run on check in and not periodically.

Edit:

Another option is to create a push pre-release packages (e.g. version 1.0.0-alpha) to your NuGet server during local builds, this way developers can experiment with the package prior to creating a release version.

---

Nuget was designed for sharing third party libaries. We plan to use Nuget internally for all common code that can be shared between projects. Things like a common data layer, string and other regular expression functions, email components and other artifacts like that.

The only way I see Nuget being of any help is when the components, code or artifacts you are sharing across teams/projects are stable and have their own release cycle that is different from your project's release cycle. For your needs Nuget is an overkill. You might have better productivity linking all such projects within the same solution. Your solution structure should include the three projects A,B and C as dependent projects referenced internally wherever required.

참고URL : https://stackoverflow.com/questions/18113223/how-should-i-use-nuget-for-internal-enterprise-development