Praktik terbaik untuk Workflows

Anda dapat merujuk ke praktik terbaik yang tercantum di sini saat mengatur layanan menggunakan Alur Kerja.

Daftar ini bukanlah daftar lengkap rekomendasi dan tidak mengajarkan dasar-dasar cara menggunakan Alur Kerja. Dokumen ini mengasumsikan bahwa Anda sudah memiliki pemahaman umum tentang lanskap Google Cloud dan Workflow secara keseluruhan. Untuk informasi selengkapnya, lihat Google Cloud Framework Arsitektur dan Ringkasan alur kerja.

Memilih pola komunikasi yang optimal

Saat mendesain arsitektur microservice untuk men-deploy beberapa layanan, Anda dapat memilih dari pola komunikasi berikut:

  • Komunikasi layanan ke layanan langsung

  • Komunikasi berbasis peristiwa tidak langsung (juga dikenal sebagai koreografi)

  • Konfigurasi, koordinasi, dan pengelolaan otomatis (juga dikenal sebagai orkestrasi)

Pastikan untuk mempertimbangkan manfaat dan kekurangan setiap opsi sebelumnya dan pilih pola yang optimal untuk kasus penggunaan Anda. Misalnya, komunikasi layanan ke layanan langsung mungkin lebih mudah diterapkan daripada opsi lain, tetapi layanan Anda akan terikat erat. Sebaliknya, arsitektur berbasis peristiwa memungkinkan Anda mengaitkan layanan secara longgar; namun, pemantauan dan proses debug mungkin lebih rumit. Terakhir, orkestrator pusat seperti Alur Kerja, meskipun kurang fleksibel, memungkinkan Anda mengoordinasikan komunikasi antar-layanan tanpa penggabungan yang ketat dari komunikasi layanan ke layanan langsung, atau kerumitan peristiwa yang dikoreografi.

Anda juga dapat menggabungkan pola komunikasi. Misalnya, dalam orkestrasi berbasis peristiwa, layanan yang terkait erat dikelola dalam orkestrasi yang dipicu oleh peristiwa. Demikian pula, Anda dapat mendesain sistem dengan satu orkestrasi yang menghasilkan pesan Pub/Sub ke sistem orkestrasi lainnya.

Tips umum

Setelah Anda memutuskan untuk menggunakan Alur Kerja sebagai orkestrator layanan, perhatikan tips bermanfaat berikut.

Menghindari URL hard code

Anda dapat mendukung alur kerja yang portabel di beberapa lingkungan dan lebih mudah dikelola dengan menghindari URL hardcode. Anda dapat melakukannya dengan cara berikut:

  • Tentukan URL sebagai argumen runtime.

    Hal ini dapat membantu saat alur kerja Anda dipanggil melalui library klien atau API. (Namun, hal ini tidak akan berfungsi jika alur kerja Anda dipicu oleh peristiwa dari Eventarc dan satu-satunya argumen yang dapat diteruskan adalah payload peristiwa.)

    Contoh

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Saat menjalankan alur kerja, Anda dapat menentukan URL. Misalnya:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Gunakan variabel lingkungan dan buat alur kerja yang dikonfigurasi secara dinamis bergantung pada lingkungan tempat alur kerja tersebut di-deploy. Atau, buat alur kerja yang dapat digunakan kembali sebagai template dan dikonfigurasi sesuai dengan variabel lingkungan yang dikelola secara terpisah.

  • Gunakan teknik penggantian yang memungkinkan Anda membuat satu file definisi alur kerja, tetapi deploy varian menggunakan alat yang mengganti placeholder dalam alur kerja Anda. Misalnya, Anda dapat menggunakan Cloud Build untuk men-deploy alur kerja dan di file konfigurasi Cloud Build, tambahkan langkah untuk mengganti URL placeholder dalam alur kerja.

    Contoh

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Kemudian, Anda dapat mengganti nilai variabel pada waktu build. Contoh:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Untuk mengetahui informasi selengkapnya, lihat Mengirim build melalui CLI dan API.

    Atau, Anda dapat menggunakan Terraform untuk menyediakan infrastruktur dan menentukan file konfigurasi yang membuat alur kerja untuk setiap lingkungan menggunakan variabel input.

    Contoh

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Saat dideklarasikan di modul root konfigurasi, variabel dapat diberi nilai dengan sejumlah cara. Misalnya

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Gunakan konektor Secret Manager untuk menyimpan URL dengan aman di Secret Manager dan mengambilnya.

Menggunakan langkah bertingkat

Setiap alur kerja harus memiliki minimal satu langkah. Secara default, Alur Kerja memperlakukan langkah-langkah seolah-olah berada dalam daftar terurut dan menjalankannya satu per satu hingga semua langkah telah berjalan. Secara logis, beberapa langkah harus dikelompokkan bersama dan Anda dapat menggunakan blok steps untuk menyusun serangkaian langkah. Hal ini praktis karena memungkinkan Anda mengarahkan ke langkah atomik yang benar untuk memproses serangkaian langkah.

Contoh

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Menggabungkan ekspresi

Semua ekspresi harus dimulai dengan $ dan diapit dalam tanda kurung kurawal:

${EXPRESSION}

Untuk menghindari masalah penguraian YAML, Anda dapat menggabungkan ekspresi dalam tanda kutip. Misalnya, ekspresi yang berisi titik dua dapat menyebabkan perilaku yang tidak terduga saat titik dua ditafsirkan sebagai menentukan peta. Anda dapat mengatasi masalah ini dengan menggabungkan ekspresi YAML dalam tanda petik tunggal:

'${"Name: " + myVar}'

Anda juga dapat menggunakan ekspresi yang mencakup beberapa baris. Misalnya, Anda mungkin perlu menggabungkan kueri SQL dalam tanda kutip saat menggunakan konektor BigQuery Worklow.

Contoh

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Untuk seluruh definisi alur kerja, lihat Menjalankan beberapa tugas BigQuery secara paralel.

Menggunakan panggilan deklaratif

Gunakan Alur Kerja untuk memanggil layanan dari alur kerja itu sendiri dan menangani hasilnya, serta untuk menjalankan tugas sederhana seperti melakukan panggilan HTTP. Alur kerja dapat memanggil layanan, mengurai respons, dan membuat input untuk layanan terhubung lainnya. Dengan memanggil layanan, Anda dapat menghindari kerumitan pemanggilan tambahan, dependensi tambahan, dan layanan yang memanggil layanan. Pertimbangkan untuk mengganti layanan yang bebas dari logika bisnis dengan panggilan API deklaratif dan gunakan Workflows untuk mengabstraksi kompleksitas.

Namun, Anda harus membuat layanan untuk melakukan pekerjaan yang terlalu rumit untuk Alur Kerja; misalnya, menerapkan logika bisnis yang dapat digunakan kembali, komputasi kompleks, atau transformasi yang tidak didukung oleh ekspresi Alur Kerja dan library standarnya. Kasus yang rumit biasanya lebih mudah diterapkan dalam kode, bukan menggunakan YAML atau JSON dan sintaksis Alur Kerja.

Hanya simpan yang Anda butuhkan

Kontrol penggunaan memori agar Anda tidak mengalami batas resource atau error yang menunjukkan hal ini seperti ResourceLimitError, MemoryLimitExceededError, atau ResultSizeLimitExceededError.

Pilih dengan cermat apa yang Anda simpan dalam variabel, dengan memfilter dan hanya menyimpan yang Anda butuhkan. Jika layanan menampilkan payload yang terlalu besar, gunakan fungsi terpisah untuk melakukan panggilan bagi Anda dan hanya menampilkan yang diperlukan.

Anda dapat mengosongkan memori dengan menghapus variabel. Misalnya, Anda mungkin ingin mengosongkan memori yang diperlukan untuk langkah berikutnya. Atau, Anda mungkin memiliki panggilan dengan hasil yang tidak Anda minati, dan Anda dapat menghapus hasil tersebut sepenuhnya.

Anda dapat menghapus variabel dengan menetapkan null. Di YAML, Anda juga dapat menetapkan nilai kosong atau ~ ke variabel. Hal ini mengidentifikasi memori yang dapat diklaim kembali tanpa masalah.

Contoh

  - step:
      assign:
        - bigVar:

Menggunakan subalur kerja dan alur kerja eksternal

Anda dapat menggunakan sub-alur kerja untuk menentukan bagian logika atau serangkaian langkah yang ingin Anda panggil beberapa kali, sehingga menyederhanakan definisi alur kerja. Subalur kerja mirip dengan fungsi atau rutinitas dalam bahasa pemrograman. Fungsi ini dapat menerima parameter dan menampilkan nilai, sehingga Anda dapat membuat alur kerja yang lebih kompleks dengan rentang aplikasi yang lebih luas.

Perhatikan bahwa subalur kerja bersifat lokal untuk definisi alur kerja Anda dan tidak dapat digunakan kembali dalam alur kerja lain. Namun, Anda dapat memanggil alur kerja dari alur kerja lain. Konektor Alur Kerja dapat membantu Anda melakukannya. Untuk mengetahui informasi selengkapnya, lihat ringkasan konektor untuk Workflow Executions API dan Workflows API.

Menggunakan konektor Workflows

Alur kerja menyediakan sejumlah konektor yang memudahkan akses ke produk Google Cloud lain dalam alur kerja. Konektor menyederhanakan layanan panggilan karena menangani pemformatan permintaan untuk Anda, menyediakan metode dan argumen sehingga Anda tidak perlu mengetahui detail Google Cloud API. Konektor juga memiliki perilaku bawaan untuk menangani percobaan ulang dan operasi yang berjalan lama sehingga Anda dapat menghindari iterasi dan menunggu panggilan selesai; konektor akan menanganinya untuk Anda.

Jika Anda perlu memanggil Google Cloud API, periksa terlebih dahulu untuk mengetahui apakah konektor Alur Kerja untuk API tersebut ada. Selain itu, jika tidak melihat konektor untuk produk Google Cloud , Anda dapat memintanya.

Pelajari cara menggunakan konektor, dan untuk referensi mendetail tentang konektor yang tersedia, lihat Referensi konektor.

Menjalankan langkah alur kerja secara paralel

Meskipun Alur Kerja dapat menjalankan langkah secara berurutan, Anda juga dapat menjalankan langkah independen secara paralel. Dalam beberapa kasus, hal ini dapat mempercepat eksekusi alur kerja Anda secara signifikan. Untuk mengetahui informasi selengkapnya, lihat Menjalankan langkah alur kerja secara paralel.

Menerapkan percobaan ulang dan pola saga

Rancang alur kerja yang tangguh dan dapat menangani kegagalan layanan sementara dan permanen. Error untuk Alur Kerja mungkin muncul, misalnya, oleh permintaan, fungsi, konektor HTTP yang gagal, atau dihasilkan oleh kode alur kerja Anda sendiri. Tambahkan penanganan error dan percobaan ulang sehingga kegagalan dalam satu langkah tidak menyebabkan seluruh alur kerja gagal.

Beberapa transaksi bisnis mencakup beberapa layanan sehingga Anda memerlukan mekanisme untuk menerapkan transaksi yang mencakup layanan. Pola desain saga adalah cara untuk mengelola konsistensi data di seluruh microservice dalam skenario transaksi terdistribusi. Saga adalah urutan transaksi yang memublikasikan peristiwa untuk setiap transaksi dan memicu transaksi berikutnya. Jika transaksi gagal, saga akan menjalankan transaksi kompensasi yang melawan kegagalan sebelumnya dalam urutan. Coba Tutorial Ulang dan Pola Saga dalam Alur Kerja di GitHub.

Menggunakan callback untuk menunggu

Callback memungkinkan eksekusi alur kerja menunggu layanan lain membuat permintaan ke endpoint callback; permintaan tersebut akan melanjutkan eksekusi alur kerja.

Dengan callback, Anda dapat memberi sinyal ke alur kerja bahwa peristiwa yang ditentukan telah terjadi, dan menunggu peristiwa tersebut tanpa polling. Misalnya, Anda dapat membuat alur kerja yang memberi tahu Anda saat produk kembali tersedia atau saat item telah dikirim; atau alur kerja yang menunggu untuk mengizinkan interaksi manusia seperti meninjau pesanan atau memvalidasi terjemahan. Anda juga dapat menunggu peristiwa menggunakan callback dan pemicu Eventarc.

Melakukan orkestrasi tugas yang berjalan lama

Jika perlu menjalankan workload pemrosesan batch yang berjalan lama, Anda dapat menggunakan Batch atau tugas Cloud Run, dan Anda dapat menggunakan Alur Kerja untuk mengelola layanan. Hal ini memungkinkan Anda menggabungkan keunggulan serta menyediakan dan mengatur seluruh proses secara efisien.

Batch adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjadwalkan, memasukkan dalam antrean, dan menjalankan beban kerja batch pada instance virtual machine (VM) Compute Engine. Anda dapat menggunakan konektor Alur Kerja untuk Batch untuk menjadwalkan dan menjalankan tugas Batch. Untuk mengetahui detailnya, coba tutorial.

Tugas Cloud Run digunakan untuk menjalankan kode yang melakukan pekerjaan (tugas) dan berhenti ketika pekerjaan tersebut selesai. Alur kerja memungkinkan Anda menjalankan tugas Cloud Run sebagai bagian dari alur kerja untuk melakukan pemrosesan data yang lebih kompleks atau mengatur sistem tugas yang ada. Coba tutorial yang menunjukkan cara menggunakan Workflows untuk menjalankan tugas Cloud Run.

Membuat container untuk tugas yang berjalan lama

Anda dapat mengotomatiskan eksekusi penampung yang berjalan lama menggunakan Alur Kerja dan Compute Engine. Misalnya, Anda dapat mengemas tugas yang berjalan lama sehingga dapat berjalan di mana saja, lalu menjalankan penampung di VM Compute Engine selama durasi maksimum eksekusi alur kerja (satu tahun).

Dengan menggunakan Alur Kerja, Anda dapat mengotomatiskan pembuatan VM, pengoperasian penampung di VM, dan penghapusan VM. Hal ini memungkinkan Anda menggunakan server dan menjalankan container, tetapi menghilangkan kompleksitas pengelolaan keduanya, dan dapat membantu jika Anda mengalami batasan waktu saat menggunakan layanan seperti fungsi Cloud Run atau Cloud Run. Coba tutorial Container yang berjalan lama dengan Alur Kerja dan Compute Engine di GitHub.

Menjalankan alat command line dari Alur Kerja

Cloud Build adalah layanan yang menjalankan build Anda di Google Cloud sebagai serangkaian langkah build, dengan setiap langkah build dijalankan di container Docker. Menjalankan langkah build serupa dengan menjalankan perintah dalam skrip.

Google Cloud CLI menyertakan alat command line gcloud, bq, dan kubectl, tetapi tidak ada cara langsung untuk menjalankan perintah gcloud CLI dari Alur Kerja. Namun, Cloud Build menyediakan image container yang menyertakan gcloud CLI. Anda dapat menjalankan perintah gcloud CLI di penampung tersebut dari langkah Cloud Build, dan Anda dapat membuat langkah tersebut di Alur Kerja menggunakan konektor Cloud Build.

Contoh

Jalankan gcloud dalam alur kerja:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Menggunakan Terraform untuk membuat alur kerja

Terraform adalah alat infrastruktur sebagai kode yang memungkinkan Anda membuat, mengubah, dan meningkatkan infrastruktur cloud secara terprediksi menggunakan kode.

Anda dapat menentukan dan men-deploy alur kerja menggunakan resource Terraform google_workflows_workflow. Untuk mengetahui informasi selengkapnya, lihat Membuat alur kerja menggunakan Terraform.

Untuk membantu Anda mengelola dan memelihara alur kerja yang besar, Anda dapat membuat alur kerja dalam file YAML terpisah dan mengimpor file tersebut ke Terraform menggunakan fungsi templatefile yang membaca file di jalur tertentu dan merender kontennya sebagai template.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Demikian pula, jika memiliki alur kerja utama yang memanggil beberapa subalur kerja, Anda dapat menentukan alur kerja utama dan subalur kerja dalam file terpisah, dan menggunakan fungsi templatefile untuk mengimpornya.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Perhatikan bahwa jika Anda merujuk ke nomor baris saat men-debug alur kerja, semua file YAML yang diimpor melalui file konfigurasi Terraform akan digabungkan dan di-deploy sebagai satu alur kerja.

Men-deploy alur kerja dari repositori Git

Cloud Build menggunakan pemicu build untuk mengaktifkan otomatisasi CI/CD. Anda dapat mengonfigurasi pemicu untuk memproses peristiwa masuk, seperti saat commit baru di-push ke repositori atau saat permintaan pull dimulai, lalu otomatis mengeksekusi build saat peristiwa baru masuk.

Anda dapat menggunakan pemicu Cloud Build untuk otomatis memulai build dan men-deploy alur kerja dari repositori Git. Anda dapat mengonfigurasi pemicu untuk men-deploy alur kerja pada setiap perubahan pada repositori sumber, atau men-deploy alur kerja hanya jika perubahan tersebut cocok dengan kriteria tertentu.

Pendekatan ini dapat membantu Anda mengelola siklus proses deployment. Misalnya, Anda dapat men-deploy perubahan pada alur kerja di lingkungan staging, menjalankan pengujian pada lingkungan tersebut, lalu meluncurkan perubahan ini secara bertahap ke lingkungan produksi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy alur kerja dari repositori Git menggunakan Cloud Build.

Mengoptimalkan penggunaan

Biaya untuk menjalankan alur kerja sangat minim. Namun, untuk penggunaan dengan volume tinggi, terapkan panduan berikut untuk mengoptimalkan penggunaan dan mengurangi biaya:

  • Daripada menggunakan domain kustom, pastikan bahwa panggilan ke layanan Google Cloudmenggunakan *.appspot.com, *.cloud.goog, *.cloudfunctions.net, atau *.run.app sehingga Anda ditagih untuk langkah internal, bukan eksternal.

  • Terapkan kebijakan percobaan ulang kustom yang menyeimbangkan kebutuhan latensi dan keandalan Anda dengan biaya. Percobaan ulang yang lebih sering akan menurunkan latensi dan meningkatkan keandalan, tetapi juga dapat meningkatkan biaya.

  • Saat menggunakan konektor yang menunggu operasi yang berjalan lama, tetapkan kebijakan polling kustom yang mengoptimalkan latensi untuk biaya. Misalnya, jika Anda memperkirakan operasi akan memerlukan waktu lebih dari satu jam, Anda mungkin menginginkan kebijakan yang awalnya melakukan polling setelah satu menit jika terjadi kegagalan langsung, lalu setiap 15 menit setelahnya.

  • Gabungkan tugas menjadi satu langkah.

  • Hindari penggunaan langkah sys.log yang berlebihan. Sebaiknya gunakan logging panggilan.

Ringkasan praktik terbaik

Tabel berikut meringkas tips umum dan praktik terbaik yang direkomendasikan dalam dokumen ini.

Tips umum
Praktik terbaik

Langkah selanjutnya