Aracılığıyla paylaş

Pipeline çalıştırmalarında sorun giderme

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

İşlem hattı çalıştırmanız tamamlanamadıysa, sorunu gidermek için işlem hattı çalıştırması özet sayfasındaki tanılama bilgilerini ve günlükleri kullanın. Bu kılavuzda günlükleri, hata çözümleme araçlarını ve yaygın sorun giderme tekniklerini kullanarak işlem hattı hatalarını tanılamaya yönelik yönergeler sağlanır. Kök nedenleri belirlemeyi ve işlem hatlarınızın sorunsuz çalışmasını sağlamak için çözümler uygulamayı öğrenin.

Tanılama bilgilerini içeren işlem hattı çalıştırma özeti sayfasının ekran görüntüsü.

Günlükleri görüntüle

Tamamlanmamış görevin günlüklerini görüntülemek için hata iletisini seçin.

İşlem hattı çalıştırma özet sayfasındaki bir görev hata iletisinin ekran görüntüsü.

Günlükler sayfasında seçili hata gösterilir. Bu örnekte, cmd-line görevinde echo komutunun echolarak girildiği bir hata vardır.

İşlem hattı çalışması için tanılama kayıtlarının ekran görüntüsü.

Ham günlüğü görüntüle'yi seçerek görevin ham günlüğünü görüntüleyebilir ve Bul'u kullanarak günlükte arama yapabilirsiniz.

Azure DevOps'taki günlük görünümü seçeneklerinin ekran görüntüsü.

Hata bilgileri ve görevin neden başarısız olduğuna ilişkin ipuçları için başarısız olan görevin günlüklerini tarayın. Varsayılan olarak, az ayrıntılı günlükler bir işlem hattı çalıştırılarak oluşturulur. Varsayılan günlükler sorunun nedenini göstermiyorsa ayrıntılı günlükleri yapılandırarak daha fazla bilgi edinebilirsiniz.

Hata analizi sayfası

Hata analizi sayfası kullanılarak sorun giderme yardımı sağlanır. Fareyi hata bilgileri satırının üzerine getirin ve Çözümlemeyi görüntüle simgesini seçin.

İşlem hattı çalıştırma özet sayfasındaki görünüm analizi simgesinin ekran görüntüsü.

Azure DevOps Server için analiz görüntüleme simgesinin ekran görüntüsü.

Şunu seçin: İşlem hattını çalıştırmak için kullanılan aracı hakkında daha fazla bilgi görüntülemek için Aracıyı Görüntüle (veya Microsoft tarafından barındırılan aracılar için Barındırılan Aracı Görüntüsü Hakkında), ve işlem hattı çalıştırma günlüklerini görüntülemek için Günlüğü Görüntüle.

Azure DevOps portalında hata analizi sayfasının ekran görüntüsü.

Görev hakkındaki bilgileri görüntülemek için Çalışma zamanı ayrıntıları'nın altındaki görevin adını seçin.

Hata analizinden görev ayrıntılarının ekran görüntüsü.

Bu örnekte, Value'in Script'ında bir hata olduğunu görebilirsiniz. Görevin belgelerini görüntülemek için Bu görev hakkında'yı seçin.

İşlem hattı çalıştırma özeti sayfasından veya günlüklere göz atmadan sorun görünmüyorsa, aşağıdaki Yaygın sorunlar bölümünü gözden geçirin ve daha fazla tanılama bilgisi içeren tam günlükleri indirme hakkında bilgi için işlem hattı sorunlarını tanılamak için günlükleri gözden geçirme bölümüne bakın.

Yaygın sorunlar

Başarısız işlem hattı çalışmaları için görev içgörüleri

Azure DevOps, "Başarısız İşlem Hattı Çalıştırmaları için Görev Öngörüleri" adlı bir ayar sağlar. Bu ayar etkinleştirildiğinde, bir raporu görüntüleme bağlantısıyla derleme hataları hakkında açılır bildirimler sağlar.

Görev içgörüleri ölçümlerinin ekran görüntüsü.

Bu ayarı yapılandırmak için Önizleme özellikleri'ne gidin, Başarısız İşlem Hattı Çalıştırmaları için Görev öngörüleri'ni bulun ve istediğiniz ayarı seçin.

Başarısız işlem hattı çalıştırmaları için görev içgörüleri ayarının ekran görüntüsü.

Başarısız çalıştırmalar için bildirimler

Azure DevOps, başarısız işlem hattı çalıştırmaları için yerleşik bildirimler içerir. Bildirimleri etkinleştirmek için:

  1. Proje ayarları> Projeniz içinbildirimler'e gidin.
  2. Almak istediğiniz bildirim türünü seçin. Bir boru hattı çalışması her başarısız olduğunda bildirim almak için Bir derleme başarısız oluyor seçeneğini seçin.

Proje ayarlarındaki bildirimlerin ekran görüntüsü.

Bu işlem hattının devam etmesi için, çalıştırmadan önce bir kaynağa erişim izni gerekiyor.

İşlem hattınızın başlatılmadığını düşünüyorsanız veya This pipeline needs permission to access a resource before this run can continue gibi bir hata mesajı alıyorsanız, işlem hattının hizmet bağlantısı veya aracı havuzu gibi bir kaynaktan çalıştırılması için yetkilendirme bekleyip beklemediğini kontrol edin.

  1. İşlem hattına gidin ve manuel olarak bir çalıştırma başlatın.
  2. Bu çalıştırmanın devam edebilmesi için bu işlem hattının bir kaynağa erişim izni gereklidir. iletisi görünür. İletinin yanındaki Görünüm'ü seçin.
  3. Gözden geçirme bekleniyor ekranında İzin Ver'i seçin ve onay ekranında yeniden İzin Ver'i seçin.

Bu eylem, işlem hattını kaynak üzerinde yetkilendirilmiş kullanıcı olarak açıkça ekler.

aracı havuzunuza erişmek için işlem hatlarını yetkilendirmenin iki yolu vardır.

Belirli işlem hatlarını yetkilendirme

gibi This pipeline needs permission to access a resource before this run can continuebir ileti aldığınızda önceki bölümde yer alan yordamı izleyerek belirli işlem hatlarını aracı havuzunda çalışacak şekilde tek tek yetkilendirebilirsiniz.

Ayrıca aşağıdaki yordamı uygulayarak boru hatlarını yetkili listeden el ile ekleyebilir ve kaldırabilirsiniz. Bu yordam, Azure DevOps kuruluşunuzda proje düzeyinde gerçekleştirilir.

  1. Azure DevOps'ta Proje ayarları, Aracı havuzları'na gidin, şirket içinde barındırılan havuzunuzu seçin ve Güvenlik'i seçin.
  2. Yetkili listeye işlem hattı eklemek için + seçin.
  3. Yetkili listeden bir işlem hattını kaldırmak için X(Erişimi iptal et) seçeneğini belirleyin.

Açık erişimi yapılandırma

Bazı kaynaklar, her yeni işlem hattı tanımının açık yetkilendirme gerektirmemesi için Açık erişim yapılandırmanıza olanak sağlar.

Açık erişimi yapılandırmak için Project yöneticisi izinleri gerekir.

Aracı havuzları için Açık erişimi yapılandırmak için:

  1. Azure DevOps'ta Proje ayarları, Aracı havuzları'na gidin, şirket içinde barındırılan havuzunuzu seçin ve Güvenlik'i seçin.
  2. Açık erişimi etkinleştirmek için Diğer eylemler, Erişimi aç'ı seçin ve onaylamak için Yeniden Erişimi aç'ı seçin.
  3. Açık erişimi iptal etmek için İzni kısıtla'yı seçin.

Diğer kaynak türleri için Açık erişimin kullanılabilir olup olmadığını gözden geçirmek için bkz. Azure Pipelines'ta güvenliği yönetme ve Açık erişim araması.

Aracı havuzları için açık erişim hakkında daha fazla bilgi için bkz. Tek bir aracı havuzu için işlem hattı izinlerini ayarlama ve İşlem hattı izinleri.

İş zaman aşımı

İşlem hattı uzun süre çalışabilir ve sonra iş zaman aşımı süresi nedeniyle başarısız olabilir. İş zaman aşımı süresi, kullanılan araca sıkı sıkıya bağlıdır. Microsoft tarafından barındırılan ücretsiz aracılar, özel bir depo için iş başına en fazla 60 dakika ve genel depo için en fazla 360 dakika zaman aşımına sahiptir.

Bir işin en fazla zaman aşımı süresini artırmak için aşağıdakilerden birini tercih edebilirsiniz.

  • Kullanılan depodan bağımsız olarak tüm işler için size 360 dakika süre tanıyan microsoft tarafından barındırılan bir aracı satın alın
  • Aracıdan kaynaklanan zaman aşımı sorunlarını elemek için yerel olarak barındırılan bir aracı kullanarak

İş zaman aşımı hakkında daha fazla bilgi edinin.

Uyarı

Microsoft tarafından barındırılan aracı işleriniz zaman aşımına uğriyorsa, işlem hattı zaman aşımınızın bir iş için maksimum zaman aşımından daha büyük bir değere ayarlandığını doğrulayın. Kontrol etmek için bakınız Zaman Aşımları.

Kod indirme sorunları

İşlem hattım bir çekme adımında başarısız oluyor.

Kuruluşunuzda işlem hattınızdan farklı bir checkout projede yer alan bir Azure Repos Git deposunda bir adım kullanıyorsanız, İş yetkilendirme kapsamını geçerli projeyle sınırla ayarının devre dışı bırakıldığından emin olun veya işlem hattınızın depoya erişimi olduğundan emin olmak için Kapsamlı derleme kimlikleri'ndeki adımları izleyin.

İşlem hattınız sınırlı iş yetkilendirme kapsamı nedeniyle depoya erişemiyorsa hatayı Git fetch failed with exit code 128 alırsınız ve günlükleriniz şuna benzer bir giriş içerir: Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

İşlem hattınız Could not find a project that corresponds with the repositoryile hemen başarısız oluyorsa, checkout adımında veya depo kaynak bildiriminde projenizin ve depo adınızın doğru olduğundan emin olun.

Team Foundation Sürüm Denetimi (TFVC) sorunları

Bazı dosyaların indirilmediği kaynakları alma

Günlükte komuttan tf get "Tüm dosyalar güncel" iletisini görebilirsiniz. Yerleşik hizmet kimliğinin kaynakları indirme için izinlere sahip olduğunu doğrulayın. Derleme işlem hattının Genel sekmesinde seçilen yetkilendirme kapsamına bağlı olarak, kaynakları indirmek için Proje Koleksiyonu Derleme Hizmeti Kimliği veya Proje Derleme Hizmeti Kimliğinin iznine ihtiyaç duyulur. Sürüm kontrolü web kullanıcı arayüzünde, klasör hiyerarşisinin herhangi bir seviyesindeki proje dosyalarına göz atabilir ve güvenlik ayarlarını kontrol edebilirsiniz.

Team Foundation Proxy aracılığıyla kaynakları alma

Team Foundation Proxy aracılığıyla kaynakları almak için aracıyı yapılandırmanın en kolay yolu, aracının kullanıcı olarak çalıştırılması için TFVC proxy sunucusuna işaret eden ortam değişkeni TFSPROXY ayarlamaktır.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

İşlem hattım MSBUILD gibi bir komut satırı adımında başarısız oluyor

Bir derleme veya yayım hatasının, Azure Pipelines ürün sorunu (aracı veya görevler) kaynaklı olup olmadığını belirlemek faydalı olur. Derleme ve yayın hataları da dış komutlardan kaynaklanabilir.

Başarısız görev tarafından yürütülen tam komut satırını görmek için günlükleri kontrol edin. Komutu komut satırından yerel olarak çalıştırmaya çalışmak sorunu yeniden üretebilir. Komutunu kendi makinenizden yerel olarak çalıştırmak ve/veya makinede oturum açıp komutu hizmet hesabı olarak çalıştırmak yararlı olabilir.

Örneğin, sorun derleme işlem hattınızın MSBuild bölümü sırasında mı oluyor (örneğin, MSBuild veya Visual Studio Derleme görevini mi kullanıyorsunuz)? Öyleyse, aynı bağımsız değişkenleri kullanarak yerel bir makinede aynı MSBuild komutunu çalıştırmayı deneyin. Sorunu yerel bir makinede yeniden oluşturabiliyorsanız, sonraki adımlarınız MSBuild sorununu araştırmaktır.

Dosya düzeni

Bir derleme için gereken araçların, kütüphanelerin, başlıkların ve diğer öğelerin konumu, barındırılan ajanda yerel makinenizden farklılık gösterebilir. Derleme bu dosyalardan birini bulamadığından başarısız olursa, aracıdaki düzeni incelemek için aşağıdaki betikleri kullanabilirsiniz. Bu, eksik dosyayı izlemenize yardımcı olabilir.

Geçici bir konumda yeni bir YAML işlem hattı oluşturun (örneğin, sorun giderme amacıyla oluşturulan yeni bir depo). Yazıldıkça betik, yolunuzdaki dizinleri arar. İsteğe bağlı olarak SEARCH_PATH= satırını düzenleyerek başka yerlerde arama yapabilirsiniz.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Yerel komut istemi ve aracı arasındaki farklar

Yerel makinede bir komut yürütülürken ve bir aracıda derleme veya yayın çalıştırılırken bazı farklılıkların geçerli olduğunu unutmayın. Aracı Linux, macOS veya Windows'da hizmet olarak çalışacak şekilde yapılandırılmışsa, etkileşimli bir oturum açma oturumunda çalışmıyor demektir. Etkileşimli bir oturum olmadan, kullanıcı arabirimiyle etkileşim ve diğer sınırlamalar vardır.

Kullanımdaki dosya veya klasör hataları

File or folder in use hataları aşağıdaki gibi hata iletileriyle gösterilir:

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Sorun giderme adımları:

Kullanımdaki dosyaları ve klasörleri algılama

Windows'da İşlem İzleyicisi gibi araçlar belirli bir dizin altında dosya olaylarının izini yakalamak olabilir. Öte yandan anlık görüntü için İşlem Gezgini veya Tanıtıcı gibi araçlar da kullanılabilir.

Antivirüs istisnası

Dosyalarınızı tarayan virüsten koruma yazılımı, derleme veya yayın sırasında dosya veya klasörün kullanımda hatalara neden olabilir. Virüsten koruma yazılımını müdahaleci süreç olarak belirlemeye yardımcı olmak için, aracı dizininize ve yapılandırılmış "çalışma klasörünüze" yönelik bir virüsten koruma dışlaması eklemek faydalı olabilir.

MSBuild ve /nodeReuse:false

Derleme sırasında MSBuild'i çağırıyorsanız, /nodeReuse:false parametresini (kısa form /nr:false) geçtiğinizden emin olun. Aksi takdirde DERLEME tamamlandıktan sonra MSBuild işlemleri çalışmaya devam eder. İşlemler bir süre daha olası bir sonraki derlemeyi beklemeye devam eder.

MSBuild'in bu özelliği, MSBuild işlemlerinin çalışma diziniyle çakışma nedeniyle bir dizini silme veya taşıma girişimlerini engelleyebilir.

MSBuild ve Visual Studio Derleme işlemleri, zaten MSBuild'e iletilen argümanlara /nr:false ekler. Ancak, MSBuild'i kendi betiğinizden çağırırsanız bağımsız değişkenini belirtmeniz gerekir.

MSBuild ve /maxcpucount:[n]

Varsayılan olarak MSBuild ve Visual Studio Derlemesi gibi derleme görevleri MSBuild'i /m anahtarla çalıştırır. Bazı durumlarda bu, birden çok işlem dosyası erişim sorunu gibi sorunlara neden olabilir.

Derleme görevlerinize /m:1 bağımsız değişkenini ekleyerek MSBuild'in aynı anda yalnızca bir işlem çalıştırmasını sağlamayı deneyin.

MSBuild'in eşzamanlı işlem özelliğinden yararlanılırken dosya kullanımı sorunları oluşabilir. /maxcpucount:[n] bağımsız değişkeninin belirtilmemesi (kısa formu /m:[n]), MSBuild'e yalnızca tek bir işlem kullanmasını belirtir. MSBuild veya Visual Studio Derleme görevlerini kullanıyorsanız, varsayılan olarak eklenen "/m" bağımsız değişkenini geçersiz kılmak için "/m:1" belirtmeniz gerekebilir.

Aralıklı veya tutarsız MSBuild hataları

Aralıklı veya tutarsız MSBuild hatalarıyla karşılaşıyorsanız, MSBuild'e yalnızca tek işlem kullanma talimatını verin. Aralıklı veya tutarsız hatalar, hedef yapılandırmanızın MSBuild'in eşzamanlı işlem özelliğiyle uyumsuz olduğunu gösterebilir. Bkz . MSBuild ve /maxcpucount:[n].

İşlem yanıt vermeyi durduruyor

İşlem, nedenlere yanıt vermeyi ve sorun giderme adımlarını durdurur:

Giriş Bekleniyor

Yanıt vermeyi durduran bir işlem, bir işlemin giriş beklediğini gösterebilir.

Aracıyı etkileşimli bir oturumda komut satırından çalıştırmak, bir işlemin giriş için bir iletişim kutusu isteyip istemediğini belirlemenize yardımcı olabilir.

Aracıyı hizmet olarak çalıştırmak, programların giriş istemesini ortadan kaldırmaya yardımcı olabilir. Örneğin. .NET'te programlar, sorup sormayacağını belirlemek için System.Environment.UserInteractive Boolean'a güvenebilir. Aracı bir Windows hizmeti olarak çalışırken, değer false olur.

İşlem dökümü

Bir işlemin dökümünü analiz etmek, kilitlenmiş bir işlemin neyi beklediğini belirlemeye yardımcı olabilir.

WiX projesi

Özel MSBuild günlükçüleri etkinleştirildiğinde bir WiX projesi oluşturmak, WiX'in çıkış akışının yanıtını beklerken donmasına veya tepki vermemesine neden olabilir. Eklenmesi gereken MSBuild bağımsız değişkeni /p:RunWixToolsOutOfProc=true sorunu çözer.

Birden çok platform için satır sonları

İşlem hatlarını birden çok platformda çalıştırdığınızda, bazen farklı satır sonlarıyla ilgili sorunlarla karşılaşabilirsiniz. Geçmişte, Linux ve macOS 'satır besleme' (LF) karakterlerini kullanırken, Windows 'satır başı ve satır besleme' (CRLF) kullanıyordu. Git, satırların otomatik olarak depoda LF ile bitmesini ancak Windows'daki çalışma dizininde CRLF'nin olmasını sağlayarak farkı telafi etmeye çalışır.

Çoğu Windows aracı yalnızca LF satır sonlarıyla uyumludur ancak bu otomatik davranış, çözdüğünden daha fazla soruna yol açabilir. Satır sonlarını temel alan sorunlarla karşılaşırsanız Git'i her yerde LF'yi tercih etmek üzere yapılandırmanızı öneririz. Bunu yapmak için deponuzun köküne bir .gitattributes dosyası ekleyin. Bu dosyaya aşağıdaki satırı ekleyin:

* text eol=lf

' (tek tırnak) eklenmiş değişkenler

İşlem hattınız komutunu kullanarak ##vso değişkenleri ayarlayan bir Bash betiği içeriyorsa, ayarladığınız değişkenin değerine başka bir ' eklendiğini görebilirsiniz. Bu, set -x ile olan bir etkileşim nedeniyle oluşur. Çözüm, değişken ayarlamadan önce set -x'i geçici olarak devre dışı bırakmaktır. Bunu yapmak için Bash sözdizimi set +x şeklindedir.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Bu neden gerçekleşir?

Birçok Bash betikleri, hata ayıklamaya yardımcı olmak için set -x komutunu içerir. Bash tam olarak hangi komutun yürütüldüğünü izler ve stdout'a yazar. Bu, ajanının ##vso komutunu iki kez görmesine neden olur ve ikinci seferde Bash, ' karakterini sona eklemiş olur.

Örneğin, şu işlem hattını göz önünde bulundurun:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

stdout üzerinde, ajan iki satır görür.

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Aracı ilk satırı gördüğünde, MY_VAR "my_value" doğru bir değere ayarlanır. Ancak, ikinci satırı gördüğünde aracı her şeyi satırın sonuna kadar işler. MY_VAR "my_value" olarak ayarlanır.

Python uygulaması için kitaplıklar, betik çalıştırıldığında yüklenmiyor.

Python uygulaması dağıtıldığında, bazı durumlarda bir CI/CD işlem hattı çalıştırılır ve kod başarıyla dağıtılır, ancak tüm bağımlılık kitaplıklarını yüklemekten sorumlu olanrequirements.txt dosyası yürütülmüyor.

Bağımlılıkları yüklemek için App Service dağıtım görevinde bir dağıtım sonrası betiği kullanın. Aşağıdaki örnek, dağıtım sonrası betiğinde kullanmanız gereken komutu gösterir. Senaryonuzun betiğini güncelleyebilirsiniz.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Hizmet bağlantılarıyla ilgili sorunları gidermek için bkz. Hizmet bağlantısı sorunlarını giderme. Kimlik doğrulaması için iş yükü kimliğini kullanan hizmet bağlantılarında özellikle sorun gidermek için bkz. İş yükü kimlik hizmeti bağlantılarında sorun giderme.

Acente ile iletişim kesildi.

İşlem hattınız We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.gibi bir iletiyle başarısız olursa, ajan makinesinin kaynaklarının tükendiğini görmek için ajanın kaynak kullanımını kontrol edin. Sprint 228'den başlayarak Azure Pipelines günlükleri her adım için kaynak kullanım ölçümleri içerir.

Azure DevOps Services kullanırken, ayrıntılı günlükleri etkinleştirerek günlüklerde disk kullanımı, bellek kullanımı ve CPU kullanımını içeren kaynak kullanımını görebilirsiniz. İşlem hattı tamamlandığında, günlüklerde her adım için Agent environment resources giriş arayın.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Ek kaynak kullanım günlüklerini yakalama hakkında bilgi için bkz. Kaynak kullanımı ayrıntılarını yakalama.

Depolama Gezgini'nin .css ve .js gibi statik içerikleri Azure Pipelines aracılığıyla Azure DevOps'tan statik bir web sitesine dağıtmasını sağlama

Bu senaryoda, web sitesine içerik yüklemek için Azure Dosya Kopyalama görevini kullanabilirsiniz. İçeriği web kapsayıcısına yüklemek için İçerik yükleme bölümünde açıklanan araçlardan herhangi birini kullanabilirsiniz.

Sonraki adımlar