다음을 통해 공유

파이프라인 캐싱

Azure DevOps Services

파이프라인 캐싱은 이전 실행에서 다운로드한 종속성을 재사용하여 동일한 파일을 다시 만들거나 다시 다운로드할 필요가 없도록 하여 빌드 시간을 줄일 수 있습니다. 이는 각 실행이 시작될 때 동일한 종속성이 반복적으로 다운로드되는 시나리오에서 특히 유용합니다. 이 프로세스는 종종 수백 또는 수천 개의 네트워크 호출을 포함하는 시간이 많이 소요되는 프로세스입니다.

캐시를 복원하고 저장하는 데 필요한 시간이 파일을 다시 생성하는 데 걸리는 시간보다 작은 경우 캐싱이 가장 효과적입니다. 그러나 경우에 따라 캐싱은 성능 이점을 제공하지 않을 수 있으며 빌드 시간에 부정적인 영향을 줄 수도 있습니다. 특정 시나리오를 평가하여 캐싱이 올바른 접근 방식인지 확인하는 것이 중요합니다.

메모

클래식 릴리스 파이프라인에는 파이프라인 캐싱이 지원되지 않습니다.

파이프라인 아티팩트 및 파이프라인 캐싱을 사용하는 경우

파이프라인 캐싱 및 파이프라인 아티팩트 도 비슷한 기능을 수행하지만 다른 시나리오를 위한 것이며 서로 다른 용도로 사용하면 안 됩니다.

  • 파이프라인 아티팩트 사용: 한 작업에서 생성된 특정 파일을 다른 작업과 공유해야 하는 경우, 그렇지 않으면 해당 작업이 실패할 가능성이 높습니다.

  • 파이프라인 캐싱 사용: 이전 실행에서 파일을 다시 사용하여 빌드 시간을 개선하려는 경우(해당 파일이 없으면 작업의 실행 기능에 영향을 주지 않음)

메모

파이프라인 캐싱 및 파이프라인 아티팩트도 모든 계층(무료 및 유료)에 대해 무료로 사용할 수 있습니다. 자세한 내용은 아티팩트 스토리지 사용을 참조하세요.

셀프 호스팅 에이전트 요구 사항

다음 실행 파일은 환경 변수에 나열된 폴더에 PATH 있어야 합니다. 이러한 요구 사항은 호스트된 에이전트가 필요한 소프트웨어와 함께 미리 설치되어 있으므로 자체 호스팅 에이전트에만 적용됩니다.

보관 소프트웨어/플랫폼 윈도우즈 리눅스 맥
GNU 타르 필수 필수 아니요
BSD 타르 아니요 아니요 필수
7-지퍼 권장 아니요 아니요

캐시 작업: 작동 방식

파이프라인에 캐싱을 추가하려면 작업의 섹션에 steps을 추가하세요.

파이프라인을 실행하는 동안 캐시 단계가 발견되면 태스크는 제공된 입력에 따라 캐시를 복원하려고 시도합니다. 캐시를 찾을 수 없으면 단계가 완료되고 작업의 다음 단계가 실행됩니다.

작업의 모든 단계가 성공적으로 실행되면 건너뛰지 않은 각 "캐시 복원" 단계에 대해 특수한 "사후 작업: 캐시" 단계가 자동으로 추가되고 트리거됩니다. 이 단계는 캐시을 저장하는 역할을 합니다.

메모

캐시는 변경할 수 없습니다. 캐시가 만들어지면 해당 콘텐츠를 수정할 수 없습니다.

캐시 작업 구성

캐시 작업에는 경로와 키라는 두 가지 필수 인수가 있습니다.

  1. path: 캐시할 폴더의 경로입니다. 절대 경로 또는 상대 경로일 수 있습니다. 상대 경로는 $(System.DefaultWorkingDirectory)을 기준으로 해결됩니다.

    팁

    미리 정의된 변수를 사용하여 캐시하려는 폴더의 경로를 저장할 수 있습니다. 그러나 와일드카드는 지원되지 않습니다.

  2. 키: 복원하거나 저장하려는 캐시의 식별자를 정의합니다. 키는 문자열 값, 파일 경로 또는 파일 패턴의 조합으로 구성되며 각 세그먼트는 문자로 구분됩니다 | .

    • 문자열:
      고정 값(예: 캐시 이름 또는 도구 이름) 또는 환경 변수(예: 현재 OS 또는 작업 이름)에서 가져온 값입니다.

    • 파일 경로:
      콘텐츠가 해시될 특정 파일의 경로입니다. 작업이 실행되는 시점에 파일이 있어야 합니다. 파일 경로와 유사한 모든 세그먼트는 이와 같이 처리되므로 특히 포함된 세그먼트를 .사용하는 경우 "파일이 존재하지 않음" 오류가 발생할 수 있으므로 주의해야 합니다.

      팁

      경로와 유사한 문자열 세그먼트가 파일 경로처럼 처리되지 않도록 하려면 큰따옴표로 래핑합니다(예: "my.key" | $(Agent.OS) | key.file

    • 파일 패턴:
      하나 이상의 파일과 일치해야 하는 glob 스타일 와일드카드 패턴의 쉼표로 구분된 목록입니다. 예제:

      • **/yarn.lock: 원본 디렉터리 아래의 모든 yarn.lock 파일입니다.
      • */asset.json, !bin/**: bin 디렉터리에 있는 파일을 제외하고 원본 디렉터리 아래의 디렉터리에 있는 모든 asset.json 파일입니다.

파일 경로 또는 파일 패턴으로 식별되는 파일의 콘텐츠는 동적 캐시 키를 생성하기 위해 해시됩니다. 이 기능은 프로젝트에 캐시되는 내용을 고유하게 식별하는 파일이 있는 경우에 유용합니다. 예를 들어 package-lock.jsonyarn.lockGemfile.lockPipfile.lock 파일은 고유한 종속성 집합을 나타내므로 캐시 키에서 참조되거나 자주 참조됩니다. 상대 파일 경로 또는 패턴은 $(System.DefaultWorkingDirectory)을 기준으로 해석됩니다.

  • 예:

다음 예제에서는 Yarn 패키지를 캐시하는 방법을 보여 줍니다.

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

이 예제에서 캐시 키는 정적 문자열("yarn"), 작업이 실행 중인 OS(캐시가 운영 체제마다 고유하므로) 및 파일의 해시(종속성을 고유하게 식별하는)의 yarn.lock 세 부분으로 구성됩니다.

작업이 추가된 후 첫 번째 실행에서 캐시 단계에서는 이 키로 식별된 캐시가 없기 때문에 "캐시 누락"을 보고합니다. 마지막 단계가 끝나면 $(Pipeline.Workspace)/s/.yarn 파일에서 캐시가 만들어지고 업로드됩니다. 다음 실행 시 캐시 단계에서는 "캐시 적중"을 보고하고 캐시의 내용을 다운로드하고 복원합니다.

사용할 때 checkout: self를, 리포지토리가 $(Pipeline.Workspace)/s에 체크 아웃되고 .yarn 폴더는 리포지토리 자체에 있을 가능성이 큽니다.

메모

Pipeline.Workspace 모든 디렉터리를 만드는 파이프라인을 실행하는 에이전트의 로컬 경로입니다. 이 변수는 Agent.BuildDirectory와 같은 값을 가집니다. checkout: self을(를) 사용하지 않는 경우, YARN_CACHE_FOLDER의 위치를 가리키도록 리포지토리의 .yarn 변수를 업데이트해야 합니다.

복원 키 사용

restoreKeys 를 사용하면 여러 개의 정확한 키 또는 키 접두사를 쿼리할 수 있습니다. 지정된 key 가 적중하지 않을 때 대체로 사용됩니다. 복원 키는 접두사로 키를 검색하고 가장 최근에 만든 캐시 항목을 반환합니다. 이는 파이프라인이 정확한 일치 항목을 찾을 수 없지만 여전히 부분 캐시 적중을 사용하려는 경우에 유용합니다.

여러 복원 키를 지정하려면 별도의 줄에 나열합니다. 복원 키를 시도하는 순서는 위에서 아래로입니다.

  • 예:

복원 키를 사용하여 Yarn 패키지를 캐시하는 방법의 예는 다음과 같습니다.

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

이 예제에서 캐시 태스크는 먼저 지정된 키를 복원하려고 시도합니다. 캐시에 키가 없으면 첫 번째 복원 키를 yarn | $(Agent.OS)시도합니다. 이 도구는 이 접두사에 정확히 일치하거나 이 접두사로 시작하는 캐시 키를 검색합니다.

파일의 해시가 변경된 경우, yarn.lock 접두사 일치가 발생할 수 있습니다. 예를 들어 캐시에 키 yarn | $(Agent.OS) | old-yarn.lock (현재 old-yarn.lock해시와 다른 해시가 있는 경우yarn.lock)가 포함된 경우 이 복원 키는 부분 캐시 적중을 초래합니다.

첫 번째 복원 키가 일치하지 않으면, 다음 복원 키(yarn)을 사용하여 yarn로 시작하는 모든 캐시 키를 검색합니다. 접두사 일치의 경우 복원 프로세스는 가장 최근에 만든 캐시 항목을 반환합니다.

메모

파이프라인에는 여러 캐싱 작업이 포함될 수 있으며 캐싱에 대한 스토리지 제한이 없습니다. 동일한 파이프라인 내의 작업 및 태스크는 동일한 캐시에 액세스하고 공유할 수 있습니다.

복원 조건 사용

일부 시나리오에서는 캐시가 성공적으로 복원되었는지 여부에 따라 단계를 조건부로 실행할 수 있습니다. 예를 들어 캐시가 복원된 경우 종속성을 설치하는 단계를 건너뛸 수 있습니다. 인수를 사용하여 이 작업을 cacheHitVar 수행할 수 있습니다.

이 입력을 환경 변수의 이름으로 설정하면 캐시 적중이 있을 때, true 복원 키가 부분 캐시 적중을 생성하는 경우 및 inexact 캐시를 찾을 수 없는 경우 변수가 설정 false 됩니다. 그런 다음 단계 조건 또는 스크립트 내에서 이 변수를 참조할 수 있습니다.

캐시가 복원될 때 단계를 건너뛰는 예제 install-deps.sh 는 다음과 같습니다.

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

캐시 격리 및 보안

서로 다른 파이프라인과 다른 분기의 캐시 간에 격리를 보장하기 위해 모든 캐시는 범위라는 논리 컨테이너 내에 저장됩니다. 범위는 다음을 보장하는 보안 경계 역할을 합니다.

  • 한 파이프라인의 작업은 다른 파이프라인의 캐시에 액세스할 수 없습니다.

  • 끌어오기 요청을 작성하는 작업은 대상 분기(동일한 파이프라인의 경우)에서 캐시를 읽을 수 있지만 대상 분기의 범위에 캐시를 작성(만들기)할 수는 없습니다.

실행하는 동안 캐시 단계가 발견되면 키로 식별되는 캐시가 서버에서 요청됩니다. 그런 다음 서버는 작업에 표시되는 범위에서 이 키가 있는 캐시를 찾고 캐시(사용 가능한 경우)를 반환합니다. 캐시 저장 시(작업 종료 시) 캐시는 파이프라인 및 분기를 나타내는 범위에 기록됩니다.

CI, 수동 및 예약된 실행

범위 읽다 쓰다
소스 브랜치 예 예
main 분기 예 아니요
master 분기 예 아니요

끌어오기 요청 실행

범위 읽다 쓰다
소스 브랜치 예 아니요
대상 브랜치 예 아니요
중간 분기(예: refs/pull/1/merge) 예 예
main 분기 예 아니요
master 분기 예 아니요

풀 리퀘스트 포크 실행

가지 읽다 쓰다
대상 브랜치 예 아니요
중간 분기(예: refs/pull/1/merge) 예 예
main 분기 예 아니요
master 분기 예 아니요

팁

캐시는 이미 프로젝트, 파이프라인 및 분기로 범위가 지정되어 있으므로 캐시 키에 프로젝트, 파이프라인 또는 분기 식별자를 포함할 필요가 없습니다.

예시

Bundler를 사용하는 Ruby 프로젝트의 경우, Bundler가 Gems를 찾는 경로를 설정하기 위해 BUNDLE_PATH 환경 변수를 재정의합니다.

예:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems

알려진 문제 및 피드백

파이프라인에서 캐싱을 설정하는 데 문제가 있는 경우 리포지토리에서 microsoft/azure-pipelines-tasks 목록을 확인합니다. 문제가 나열되지 않으면 새을 만들고 시나리오에 필요한 정보를 제공하십시오.

질문 및 답변

Q: 캐시를 지울 수 있나요?

A: 캐시 지우기는 지원되지 않습니다. 그러나 캐시 키에 문자열 리터럴(예: version2)을 추가하여 기존 캐시에서 적중을 방지할 수 있습니다. 예를 들어 다음 캐시 키를 다음과 같이 변경하세요.

key: 'yarn | "$(Agent.OS)" | yarn.lock'

이에:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

Q: 캐시는 언제 만료되나요?

A: 7일 동안 활동이 없으면 캐시가 만료됩니다.

Q: 캐시는 언제 업로드되나요?

A: 캐시는 작업의 마지막 단계 이후에 지정된 path 캐시에서 만들어지고 업로드됩니다. 자세한 내용은 예제 를 참조하세요.

Q: 캐시 크기에 제한이 있나요?

A: 조직 내의 개별 캐시 크기 또는 총 캐시 크기에 대한 제한은 없습니다.

관련 콘텐츠