Düzenle

Azure DevOps ve Helm ile Kubernetes'te mikro hizmetler için CI/CD işlem hattı oluşturma

Azure Kubernetes Service (AKS)
Azure Container Registry
Azure DevOps

Mikro hizmetler mimarisi için güvenilir bir sürekli tümleştirme/sürekli teslim (CI/CD) işlemi oluşturmak zor olabilir. Tek tek ekiplerin, diğer ekipleri kesintiye uğratmadan veya bir bütün olarak uygulamanın istikrarını bozmadan hizmetleri hızlı ve güvenilir bir şekilde serbest bırakabilmesi gerekir.

Bu makalede, Mikro hizmetleri Azure Kubernetes Service'e (AKS) dağıtmak için örnek bir CI/CD işlem hattı açıklanmaktadır. Her ekip ve proje farklıdır, bu nedenle bu makaleyi bir dizi zor ve hızlı kural olarak almayın. Bunun yerine, kendi CI/CD işleminizi tasarlamaya yönelik bir başlangıç noktası olması gerekir.

Kubernetes tarafından barındırılan mikro hizmetler için CI/CD işlem hattının hedefleri aşağıdaki gibi özetlenebilir:

  • Ekipler hizmetlerini bağımsız olarak derleyebilir ve dağıtabilir.
  • CI işlemini geçen kod değişiklikleri otomatik olarak üretim benzeri bir ortama dağıtılır.
  • Kalite kapıları, işlem hattının her aşamasında uygulanır.
  • Hizmetin yeni bir sürümü, önceki sürümle yan yana dağıtılabilir.

Daha fazla arka plan için bkz . Mikro hizmet mimarileri için CI/CD.

Varsayımlar

Bu örnekte geliştirme ekibi ve kod tabanıyla ilgili bazı varsayımlar aşağıda verilmiştir:

  • Kod deposu, mikro hizmet tarafından düzenlenmiş klasörlerin yer aldığı bir monorepodur.
  • Ekibin dallanma stratejisi, gövde tabanlı geliştirmeyi temel alır.
  • Ekip, yayınları yönetmek için yayın dallarını kullanır. Her mikro hizmet için ayrı sürümler oluşturulur.
  • CI/CD işlemi, mikro hizmetleri derlemek, test etmek ve AKS'ye dağıtmak için Azure Pipelines'ı kullanır.
  • Her mikro hizmetin kapsayıcı görüntüleri Azure Container Registry'de depolanır.
  • Ekip, her mikro hizmeti paketlemek için Helm grafiklerini kullanır.
  • Azure Pipelines ve ilişkili aracıların doğrudan AKS kümesine bağlanarak dağıtım gerçekleştirdiği bir anında iletme dağıtım modeli kullanılır.

Bu varsayımlar CI/CD işlem hattının belirli ayrıntılarının çoğunu yönlendirir. Ancak burada açıklanan temel yaklaşım Jenkins veya Docker Hub gibi diğer işlemler, araçlar ve hizmetler için uyarlanmıştır.

Alternatifler

Müşterilerin Azure Kubernetes Service ile CI/CD stratejisi seçerken kullanabileceği yaygın alternatifler şunlardır:

  • Helm'i paket yönetimi ve dağıtım aracı olarak kullanmaya alternatif olarak Kustomize, uygulama yapılandırmasını özelleştirmek ve parametreleştirmek için şablon içermeyen bir yol sağlayan bir Kubernetes yerel yapılandırma yönetim aracıdır.
  • Git depoları ve işlem hatları için Azure DevOps'u kullanmaya alternatif olarak, GitHub Depoları özel ve genel Git depoları için, GitHub Actions ise CI/CD işlem hatları için kullanılabilir.
  • Anında iletme dağıtım modeli kullanmaya alternatif olarak, Kubernetes yapılandırmasını büyük ölçekte yönetmek, küme içi Kubernetes işlecinin Git deposunda depolanan yapılandırmaya göre küme durumunu eşitlediği GitOps (çekme dağıtım modeli) kullanılarak gerçekleştirilebilir.

Doğrulama derlemeleri

Bir geliştiricinin Teslim Hizmeti adlı bir mikro hizmet üzerinde çalıştığını varsayalım. Geliştirici, yeni bir özellik geliştirirken kodu bir özellik dalı içinde denetler. Kural gereği, özellik dalları olarak adlandırılır feature/*.

CI/CD workflow

Derleme tanımı dosyası, dal adına ve kaynak yola göre filtreleyen bir tetikleyici içerir:

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - master
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

Bu yaklaşımı kullanarak her ekibin kendi derleme işlem hattı olabilir. Yalnızca klasörde denetlenen /src/shipping/delivery kod, Teslim Hizmeti'nin bir derlemesini tetikler. İşlemelerin filtreyle eşleşen bir dala gönderilmesi bir CI derlemesini tetikler. İş akışının bu noktasında, CI derlemesi bazı en düşük kod doğrulamasını çalıştırır:

  1. Kodu oluşturun.
  2. Birim testlerini çalıştırın.

Hedef, geliştiricinin hızlı geri bildirim alabilmesi için derleme sürelerini kısa tutmaktır. Özellik ana şablonla birleştirmeye hazır olduğunda geliştirici bir çekme isteği açar. Bu işlem, bazı ek denetimler gerçekleştiren başka bir CI derlemesini tetikler:

  1. Kodu oluşturun.
  2. Birim testlerini çalıştırın.
  3. Çalışma zamanı kapsayıcı görüntüsünü oluşturun.
  4. Görüntüde güvenlik açığı taramaları çalıştırın.

Diagram showing ci-delivery-full in the Build pipeline.

Dekont

Azure DevOps Depoları'nda dalları korumak için ilkeler tanımlayabilirsiniz. Örneğin, ilkenin ana şablonda birleştirilebilmesi için başarılı bir CI derlemesinin yanı sıra onaylayandan bir oturum kapatma işlemi gerekebilir.

Tam CI/CD derlemesi

Bir noktada ekip, Teslim hizmetinin yeni bir sürümünü dağıtmaya hazırdır. Yayın yöneticisi ana daldan şu adlandırma deseniyle bir dal oluşturur: release/<microservice name>/<semver>. Örneğin, release/delivery/v1.0.2.

Diagram showing ci-delivery-full in the Build pipeline and cd-delivery in the Release pipeline.

Bu dalın oluşturulması, önceki adımların tümünü çalıştıran tam bir CI derlemesini tetikler artı:

  1. Kapsayıcı görüntüsünü Azure Container Registry'ye gönderin. Görüntü, dal adından alınan sürüm numarasıyla etiketlenmiş.
  2. Hizmeti için Helm grafiğini paketlemek için komutunu çalıştırın helm package . Grafik ayrıca bir sürüm numarasıyla etiketlenmiş.
  3. Helm paketini Container Registry'ye gönderin.

Bu derlemenin başarılı olduğunu varsayarsak Azure Pipelines yayın işlem hattını kullanarak bir dağıtım (CD) işlemi tetikler. Bu işlem hattı aşağıdaki adımlara sahiptir:

  1. Helm grafiğini bir Soru-Cevap ortamına dağıtın.
  2. Paket üretime geçmeden önce onaylayan oturumunu kapatır. Bkz. Onayları kullanarak dağıtım denetimini serbest bırakma.
  3. Azure Container Registry'de üretim ad alanı için Docker görüntüsünü yeniden etiketleyin. Örneğin, geçerli etiket ise myrepo.azurecr.io/delivery:v1.0.2üretim etiketi olur myrepo.azurecr.io/prod/delivery:v1.0.2.
  4. Helm grafiğini üretim ortamına dağıtın.

Tek bir monorepoda bile bu görevlerin kapsamı, ekiplerin yüksek hızda dağıtılabilmesi için tek tek mikro hizmetlere göre ayarlanabilir. İşlemin bazı el ile adımları vardır: PR'leri onaylama, yayın dalları oluşturma ve üretim kümesine dağıtımları onaylama. Bu adımlar el ile gerçekleştirilir; kuruluş tercih ederse otomatikleştirilebilir.

Ortamların yalıtımı

Geliştirme, duman testi, tümleştirme testi, yük testi ve son olarak üretim ortamları dahil olmak üzere hizmetleri dağıtacağınız birden çok ortamınız olacaktır. Bu ortamların bir yalıtım düzeyine ihtiyacı vardır. Kubernetes'te fiziksel yalıtım ile mantıksal yalıtım arasında seçim yapın. Fiziksel yalıtım, ayrı kümelere dağıtma anlamına gelir. Mantıksal yalıtım, daha önce açıklandığı gibi ad alanlarını ve ilkeleri kullanır.

Önerimiz, geliştirme/test ortamlarınız için ayrı bir kümeyle birlikte ayrılmış bir üretim kümesi oluşturmaktır. Geliştirme/test kümesindeki ortamları ayırmak için mantıksal yalıtımı kullanın. Geliştirme/test kümesine dağıtılan hizmetlerin hiçbir zaman iş verilerini barındıran veri depolarına erişimi olmamalıdır.

Derleme işlemi

Mümkün olduğunda derleme işleminizi bir Docker kapsayıcısına paketleyin. Bu yapılandırma, Docker kullanarak ve her derleme makinesinde bir derleme ortamı yapılandırmadan kod yapıtları oluşturmanıza olanak tanır. Kapsayıcılı derleme işlemi, yeni derleme aracıları ekleyerek CI işlem hattının ölçeğini genişletmeyi kolaylaştırır. Ayrıca, ekip üzerindeki herhangi bir geliştirici derleme kapsayıcısını çalıştırarak kodu derleyebilir.

Docker'da çok aşamalı derlemeler kullanarak, derleme ortamını ve çalışma zamanı görüntüsünü tek bir Dockerfile içinde tanımlayabilirsiniz. Örneğin, bir .NET uygulaması oluşturan bir Dockerfile aşağıda verilmiştir:

FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c release -o /app --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

Bu Dockerfile çeşitli derleme aşamalarını tanımlar. adlı aşamanın .NET çalışma zamanını, adlı basebuild aşama ise tam .NET SDK'sını kullandığına dikkat edin. Aşama build , .NET projesini derlemek için kullanılır. Ancak son çalışma zamanı kapsayıcısı, yalnızca çalışma zamanını içeren ve tam SDK görüntüsünden önemli ölçüde daha küçük olan sürümünden baseoluşturulur.

Test çalıştırıcısı oluşturma

Bir diğer iyi uygulama da kapsayıcıda birim testleri çalıştırmaktır. Örneğin, test çalıştırıcısı oluşturan docker dosyasının bir bölümü aşağıda verilmiştir:

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

Bir geliştirici testleri yerel olarak çalıştırmak için bu Docker dosyasını kullanabilir:

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

CI işlem hattı, derleme doğrulama adımının bir parçası olarak testleri de çalıştırmalıdır.

Bu dosyanın Docker ENTRYPOINT komutunu değil testleri çalıştırmak için Docker RUN komutunu kullandığını unutmayın.

  • komutunu kullanırsanız RUN , görüntüyü her derlediğinizde testler çalıştırılır. kullanılarak ENTRYPOINTtestler kabul edilir. Yalnızca aşamayı testrunner açıkça hedeflediğinizde çalışırlar.
  • Başarısız bir test, Docker build komutunun başarısız olmasına neden olmaz. Bu şekilde, kapsayıcı derleme hatalarını test hatalarından ayırt edebilirsiniz.
  • Test sonuçları bağlı bir birime kaydedilebilir.

Kapsayıcı en iyi yöntemleri

Kapsayıcılar için dikkate alınması gereken diğer en iyi uygulamalardan bazıları şunlardır:

  • Kümeye dağıtılan kaynaklar (podlar, hizmetler vb.) için kapsayıcı etiketleri, sürüm oluşturma ve adlandırma kuralları için kuruluş genelinde kurallar tanımlayın. Bu, dağıtım sorunlarını tanılamayı kolaylaştırabilir.

  • Geliştirme ve test döngüsü sırasında CI/CD işlemi birçok kapsayıcı görüntüsü oluşturur. Bu görüntülerin yalnızca bazıları yayın için adaydır ve ardından bu sürüm adaylarından yalnızca bazıları üretime yükseltilir. Şu anda üretime hangi görüntülerin dağıtıldığını bilmeniz ve gerekirse önceki bir sürüme geri dönmenize yardımcı olması için net bir sürüm oluşturma stratejisine sahip olun.

  • Her zaman belirli kapsayıcı sürümü etiketlerini dağıtın, dağıtmayın latest.

  • Üretim için onaylanan görüntüleri test edilmeye devam eden görüntülerden yalıtmak için Azure Container Registry'deki ad alanlarını kullanın. Bir görüntüyü üretime dağıtmaya hazır olana kadar üretim ad alanına taşımayın. Bu uygulamayı kapsayıcı görüntülerinin anlamsal sürümüyle birleştirirseniz, yayın için onaylanmamış bir sürümü yanlışlıkla dağıtma olasılığını azaltabilir.

  • Kapsayıcıları ayrıcalıksız bir kullanıcı olarak çalıştırarak en az ayrıcalık ilkesini izleyin. Kubernetes'te kapsayıcıların kök olarak çalışmasını engelleyen bir pod güvenlik ilkesi oluşturabilirsiniz.

Helm grafikleri

Hizmet oluşturma ve dağıtmayı yönetmek için Helm'i kullanmayı göz önünde bulundurun. Helm'in CI/CD ile ilgili yardımcı olan özelliklerinden bazıları şunlardır:

  • Genellikle tek bir mikro hizmet birden çok Kubernetes nesnesi tarafından tanımlanır. Helm, bu nesnelerin tek bir Helm grafiğinde paketlenmiş olmasını sağlar.
  • Grafik, bir dizi kubectl komutu yerine tek bir Helm komutuyla dağıtılabilir.
  • Grafikler açıkça sürümlenir. Helm'i kullanarak bir sürümü yayınlayın, sürümleri görüntüleyin ve önceki bir sürüme geri dönün. Anlamsal sürüm oluşturmanın yanı sıra önceki bir sürüme geri dönme özelliğini kullanarak güncelleştirmeleri ve düzeltmeleri izleme.
  • Helm grafikleri, etiketler ve seçiciler gibi bilgilerin birçok dosyada çoğaltılmasını önlemek için şablonları kullanır.
  • Helm grafikler arasındaki bağımlılıkları yönetebilir.
  • Grafikler Azure Container Registry gibi bir Helm deposunda depolanabilir ve derleme işlem hattıyla tümleştirilebilir.

Container Registry'yi Helm deposu olarak kullanma hakkında daha fazla bilgi için bkz . Uygulama grafikleriniz için Azure Container Registry'yi Helm deposu olarak kullanma.

Tek bir mikro hizmet birden çok Kubernetes yapılandırma dosyası içerebilir. Bir hizmeti güncelleştirmek seçicileri, etiketleri ve görüntü etiketlerini güncelleştirmek için bu dosyaların tümüne dokunmak anlamına gelebilir. Helm bunları grafik olarak adlandırılan tek bir paket olarak ele alır ve değişkenleri kullanarak YAML dosyalarını kolayca güncelleştirmenizi sağlar. Helm, parametreli YAML yapılandırma dosyaları yazmanıza olanak sağlamak için bir şablon dili (Go şablonları temelinde) kullanır.

Örneğin, dağıtımı tanımlayan bir YAML dosyasının bir bölümü aşağıda verilmiştır:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

  spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

Dağıtım adının, etiketlerin ve kapsayıcı belirtimlerinin tümünün dağıtım zamanında sağlanan şablon parametrelerini kullandığını görebilirsiniz. Örneğin, komut satırından:

helm install $HELM_CHARTS/package/ \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend \
     --name package-v0.1.0

CI/CD işlem hattınız doğrudan Kubernetes'e bir grafik yükleyebilse de, bir grafik arşivi (.tgz dosyası) oluşturmanızı ve grafiği Azure Container Registry gibi bir Helm deposuna göndermenizi öneririz. Daha fazla bilgi için bkz . Azure Pipelines'da Helm grafiklerinde Docker tabanlı uygulamaları paketleme.

Düzeltmeler

Helm grafiklerinde her zaman anlamsal sürüm oluşturmanın kullanılması gereken bir sürüm numarası bulunur. Grafikte bir de olabilir appVersion. Bu alan isteğe bağlıdır ve grafik sürümüyle ilişkili olması gerekmez. Bazı ekipler, sürümleri grafiklere yapılan güncelleştirmelerden ayrı olarak uygulamak isteyebilir. Ancak daha basit bir yaklaşım, bir sürüm numarası kullanmaktır, bu nedenle grafik sürümü ile uygulama sürümü arasında 1:1 ilişkisi vardır. Bu şekilde, yayın başına bir grafik depolayabilir ve istediğiniz sürümü kolayca dağıtabilirsiniz:

helm install <package-chart-name> --version <desiredVersion>

Başka bir iyi uygulama, dağıtım şablonunda değişiklik nedeni ek açıklaması sağlamaktır:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

Bu, komutunu kullanarak kubectl rollout history her düzeltme için değişiklik nedeni alanını görüntülemenizi sağlar. Önceki örnekte değişiklik nedeni Helm grafik parametresi olarak sağlanmıştır.

kubectl rollout history deployments/delivery-v010 -n backend

deployment.extensions/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

Düzeltme geçmişini görüntülemek için komutunu da kullanabilirsiniz helm list :

helm list

NAME            REVISION    UPDATED                     STATUS        CHART            APP VERSION     NAMESPACE
delivery-v0.1.0 1           Sun Apr  7 00:25:30 2020    DEPLOYED      delivery-v0.1.0  v0.1.0          backend

Azure DevOps İşlem Hattı

Azure Pipelines'da işlem hatları derleme işlem hatlarına ve yayın işlem hatlarına ayrılır. Derleme işlem hattı CI işlemini çalıştırır ve derleme yapıtları oluşturur. Kubernetes'te mikro hizmetler mimarisi için bu yapıtlar, her mikro hizmeti tanımlayan kapsayıcı görüntüleri ve Helm grafikleridir. Yayın işlem hattı, kümeye mikro hizmet dağıtan CD işlemini çalıştırır.

Bu makalenin önceki bölümlerinde açıklanan CI akışına bağlı olarak, derleme işlem hattı aşağıdaki görevlerden oluşabilir:

  1. Test çalıştırıcı kapsayıcısını oluşturun.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    arguments: '--pull --target testrunner'
    dockerFile: $(System.DefaultWorkingDirectory)/$(dockerFileName)
    imageName: '$(imageName)-test'

  2. Test çalıştırıcı kapsayıcısına karşı docker çalıştırmasını çağırarak testleri çalıştırın.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    command: 'run'
    containerName: testrunner
    volumes: '$(System.DefaultWorkingDirectory)/TestResults:/app/tests/TestResults'
    imageName: '$(imageName)-test'
    runInBackground: false

  3. Test sonuçlarını yayımlayın. Bkz. Görüntü oluşturma.

    - task: PublishTestResults@2
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: 'TestResults/*.trx'
    searchFolder: '$(System.DefaultWorkingDirectory)'
    publishRunAttachments: true

  4. Çalışma zamanı kapsayıcısını oluşturun.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    dockerFile: $(System.DefaultWorkingDirectory)/$(dockerFileName)
    includeLatestTag: false
    imageName: '$(imageName)'

  5. Kapsayıcı görüntüsünü Azure Container Registry'ye (veya başka bir kapsayıcı kayıt defterine) gönderin.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    command: 'Push an image'
    imageName: '$(imageName)'
    includeSourceTags: false

  6. Helm grafiğini paketleyin.

    - task: HelmDeploy@0
  inputs:
    command: package
    chartPath: $(chartPath)
    chartVersion: $(Build.SourceBranchName)
    arguments: '--app-version $(Build.SourceBranchName)'

  7. Helm paketini Azure Container Registry'ye (veya diğer Helm deposuna) gönderin.

    task: AzureCLI@1
  inputs:
    azureSubscription: $(AzureSubscription)
    scriptLocation: inlineScript
    inlineScript: |
    az acr helm push $(System.ArtifactsDirectory)/$(repositoryName)-$(Build.SourceBranchName).tgz --name $(AzureContainerRegistry);

CI işlem hattının çıkışı, üretime hazır bir kapsayıcı görüntüsü ve mikro hizmet için güncelleştirilmiş helm grafiğidir. Bu noktada yayın işlem hattı devralabilir. Her mikro hizmet için benzersiz bir yayın işlem hattı olacaktır. Yayın işlem hattı, yapıtı yayımlayan CI işlem hattına ayarlanmış bir tetikleyici kaynağı olacak şekilde yapılandırılır. Bu işlem hattı, her mikro hizmetin bağımsız dağıtımlarına sahip olmanıza olanak tanır. Yayın işlem hattı aşağıdaki adımları gerçekleştirir:

  • Helm grafiğini geliştirme/Soru-Cevap/hazırlama ortamlarına dağıtın. komutu, Helm upgrade ilk yükleme ve sonraki yükseltmeleri desteklemek için bayrağıyla --install birlikte kullanılabilir.
  • Onaylayanın dağıtımı onaylamasını veya reddetmesini bekleyin.
  • Kapsayıcı görüntüsünü yayın için yeniden etiketleyin
  • Yayın etiketini kapsayıcı kayıt defterine gönderin.
  • Helm grafiğini üretim kümesine dağıtın.

Yayın işlem hattı oluşturma hakkında daha fazla bilgi için bkz . Yayın işlem hatları, taslak sürümler ve sürüm seçenekleri.

Aşağıdaki diyagramda, bu makalede açıklanan uçtan uca CI/CD işlemi gösterilmektedir:

CD/CD pipeline

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

  • John Poole | Kıdemli Bulut Çözümleri Mimarı

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar