Azure 파이핑에서 캐시를 사용하여 구축 시간을 줄이는 방법

파이핑 캐시는 나중에 실행될 때 실행된 출력이나 다운로드의 의존 항목을 다시 사용할 수 있도록 함으로써 구축 시간을 줄이고 같은 파일을 다시 만들거나 다운로드하는 비용을 줄이거나 피할 수 있습니다.
Azure 파이핑에서 캐시를 설정하고 사용하는 방법을 살펴보겠습니다.

소개

안녕하세요.오늘 우리는 캐시를 사용하여 파이프 운행에 필요한 시간을 줄이는 방법을 토론할 것이다.
실행이 시작될 때마다 같은 의존항을 반복적으로 다운로드하는 장면에서 캐시가 특히 유용하다.이것은 보통 수백 또는 수천 개의 네트워크 호출과 관련된 시간이 걸리는 과정이다.

비디오

만약 당신이 시각 학습자이거나 읽기보다 보기와 듣기만 좋아한다면, 여기에 동영상이 하나 있는데, 그 중에는 완전한 해석이 있다. 공평하게 말하자면, 이것은 이 문장보다 훨씬 완전하다.
만약 당신이 읽는 것을 더 좋아한다면...계속하자:)

왜 캐시

왜 캐시가 중요합니까?만약 on-prem 기계나 dev 기계에 있다면, 구축과 발표 과정은 이미 어떤 캐시가 실행되어 있으며, 로컬에서 파일이나 메타데이터를 저장할 수 있습니다.
그러나 Azure Pipelines 에이전트에 대해 말하자면, 새로운 파이프라인이 실행될 때마다 이 실행을 위해 다시 만든 에이전트 기기에 있기 때문에 CICD 프로세스에 필요한 바이너리 파일과 서비스를 제외하고는 아무런 저장도 하지 않습니다.이것이 바로 당신이 캐시 서비스를 사용하기를 원할 수 있는 이유입니다.
캐시를 복구하고 저장하는 시간이 처음부터 출력을 다시 생성하는 시간보다 적으면 캐시가 구축 시간을 효과적으로 단축할 수 있다는 것을 기억하십시오.따라서 캐시는 모든 장면에서 유효하지 않을 수도 있고 구축 시간에 부정적인 영향을 미칠 수도 있다.

캐시

캐시 파이핑 작업을 사용하여 파이핑에 캐시를 추가합니다.이 작업은 다른 작업과 마찬가지로 작업하고 작업의 단계 부분에 추가됩니다.

variables:
  solution: '**/WebAppTest.sln'
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,!**/bin/**,!**/obj/**'
    restoreKeys: |
       nuget | "$(Agent.OS)"
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

캐시 작업에는 다음과 같은 두 가지 필수 입력이 있습니다.

경로는 캐시를 채울 디렉터리(저장할 때)와 파일을 저장할 디렉터리(복원할 때)로 설정해야 합니다.그것은 절대적일 수도 있고, 상대적일 수도 있다.

반대로 키를 복구하거나 저장할 캐시의 식별자로 설정해야 한다

또 다른 인자 "restore keys"가 있습니다. 여러 키나 키 접두사를 조회하려면 이 인자를 사용할 수 있습니다.이것은 키를 찾을 수 없는 상황에서 다른 키로 되돌아가는 데 유용하다.
위의 예시에서 나는'nuget'문자가 있는 복합 키, 프록시가 실행 중인 운영체제 버전 (시스템 변수에서 온 것) 을 사용했고, 마지막으로'packages'의 내용을 사용했다.자물쇠json 파일.파일을 지정할 때 엔진은 파일 내용의 해시를 키의 일부로 사용하기 때문에 내용이 변경되면 키도 변경됩니다.bin과obj 폴더에tit가 존재할 때 이 파일을 무시할 수 있도록 다른 필터를 지정했습니다.

실행 중 캐시 단계를 만났을 때, 작업은 제공된 입력에 따라 캐시를 복구합니다.캐시를 찾지 못하면 이 절차가 완료되고 작업의 다음 단계를 실행합니다.작업의 모든 단계가 실행되고 작업 상태가 성공했다고 가정하면 특수 캐시 저장 단계를 자동으로 주입하고 생략되지 않은 각 캐시 복구 단계를 실행합니다.이 단계는 캐시 저장을 책임집니다.

캐시 적중력 기반 건너뛰기 단계

어떤 경우, 캐시의 성공적인 복구는 일련의 다른 절차를 실행해야 한다.예를 들어 캐시가 복원되면 의존 항목을 설치하는 절차를 건너뛸 수 있습니다.

variables:
  solution: '**/WebAppTest.sln'
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages
  CACHE_RESTORED: 'false'

- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,!**/bin/**,!**/obj/**'
    restoreKeys: |
       nuget | "$(Agent.OS)"
    path: $(NUGET_PACKAGES)
    cacheHitVar: CACHE_RESTORED
  displayName: Cache NuGet packages

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'
  condition: ne(variables.CACHE_RESTORED, 'true')

이 점을 실현하기 위해서 우리는cacheHitVar 파라미터를 사용하여 변수를 전달할 수 있다.캐시가 적중되면 변수 값이true로 변경됩니다.
그런 다음 건너뛸 작업이나 단계의 조건에서 이 변수를 사용할 수 있습니다.

비교하다

나는 이 비교표를 만들었기 때문에, 우리는 캐시 성능에 대해 개술할 수 있다.

첫 번째 열은 캐시가 없는 실행입니다.
두 번째는 캐시입니다. 그러나 첫 번째 실행 시 캐시가 명중되지 않았다는 것을 의미합니다.보시다시피, 의존 항목은 예전처럼 복구되어야 할 뿐만 아니라, 캐시가 존재하는지 확인해야 하기 때문에, 존재하지 않기 때문에, 내용을 업로드하고 캐시 항목을 만들어야 합니다.
세 번째 열도 마지막 열은 캐시 적중입니다.캐시가 존재하기 때문에 의존 항목을 다운로드할 필요가 없습니다. 따라서 NuGet 복원 절차가 더 빠릅니다. 캐시가 저장할 시간이 없을 수 없기 때문입니다. 그리고 몇 초만 있어도 프레젠테이션 프로그램에서 의존 항목이 적기 때문입니다.

결론

주의해야 할 것은 캐시는 현재 CI와 배치 작업에서 지원되지만 클래식 발표 작업에서는 지원되지 않는다는 것이다.
당신은 Azure 파이프 캐시 시스템이 어떻다고 생각합니까?너는 그것을 쓰니?너는 그것의 좋은 점을 볼 수 있니?
아래의 평론 부분에서 저에게 알려주세요.

참조 및 링크

Video with full explanation and examples about Pipelines Caching

Official documentation about Azure Pipelines Caching

좋아하다🚀 자세한 내용:
📽
☕ Buy me a coffee
💖 Patreon
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻
👴🏻
🔉 Podcast