Menggunakan aturan otomatisasi

Dokumen ini menjelaskan aturan otomatisasi, yang merupakan tindakan yang dapat dilakukan di pipeline pengiriman Anda secara otomatis. Misalnya, Anda dapat mengonfigurasi pipeline pengiriman sehingga promosi ke target tertentu terjadi secara otomatis, dalam situasi yang tepat.

Anda hanya dapat menggunakan aturan otomatisasi yang disertakan dalam Cloud Deploy. Aturan otomatisasi yang tersedia tercantum dalam dokumen ini.

Aturan otomatisasi yang tersedia

Aturan otomatisasi berikut tersedia di Cloud Deploy:

Aturan Deskripsi
promoteReleaseRule Otomatis mempromosikan rilis ke target yang ditunjukkan setelah berhasil

peluncuran di target sebelumnya dalam progres.
timedPromoteReleaseRule Mempromosikan secara otomatis dari satu target ke target berikutnya

berdasarkan jadwal cron.
advanceRolloutRule Otomatis melanjutkan peluncuran dari

fase ke fase berikutnya.
repairRolloutRule Mencoba ulang tugas yang gagal secara otomatis dalam peluncuran

jumlah yang ditentukan, dan melakukan rollback jika semua percobaan ulang gagal.

Mengonfigurasi aturan otomatisasi

Konfigurasi untuk setiap aturan otomatisasi bergantung pada aturan tertentu. Bagian ini menjelaskan konfigurasi yang sama untuk semua aturan, serta cara mengonfigurasi setiap aturan yang tersedia.

Setiap aturan otomatisasi dikonfigurasi sebagai bagian dari konfigurasi untuk resource otomatisasi. Ini dapat berada di dalam file yang sama dengan konfigurasi untuk pipeline pengiriman yang relevan (biasanya disebut clouddeploy.yaml) atau di file apa pun yang Anda inginkan. Pelajari lebih lanjut cara mengonfigurasi otomatisasi.

Bagian berikut menjelaskan konfigurasi khusus untuk setiap aturan otomatisasi. Lihat Mengotomatiskan deployment untuk konfigurasi otomatisasi itu sendiri.

Mengonfigurasi aturan otomatisasi promoteReleaseRule

Aturan promoteReleaseRule mempromosikan rilis Anda setelah peluncuran berhasil ke target. Misalnya, jika memiliki tiga target, Anda dapat menyiapkan aturan ini sehingga saat rilis berhasil di-deploy ke target pertama, rilis tersebut akan otomatis dipromosikan ke target kedua.

Saat mengonfigurasi otomatisasi promoteReleaseRule, Anda dapat menentukan target untuk dipromosikan ke (destinationTargetId) atau @next. Jika peluncuran berhasil diselesaikan di target yang ditentukan dalam definisi Automation, rilis kemudian dipromosikan ke target yang ditentukan dalam destinationTargetId, tunduk pada interval waktu wait.

Anda juga dapat mempromosikan rilis ke fase tertentu dalam target yang diinginkan, menggunakan properti destinationPhase. Stanza rules yang ditampilkan di sini berada di dalam definisi otomatisasi Anda.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dengan keterangan:

  • [RULE_NAME]

    Nama yang ingin Anda berikan untuk aturan ini. Nama ini harus unik dalam resource otomatisasi.

  • [WAIT_TIME]

    Adalah jumlah waktu, dalam menit, yang harus ditunggu setelah rilis siap untuk promosi sebelum dipromosikan. Misalnya, 1m. m wajib diisi.

    Nilai defaultnya adalah 0, atau tidak ada waktu tunggu. Maksimalnya adalah 20160m (atau 14 hari).

  • [TO_TARGET]

    Adalah targetId target yang akan dipromosikan.

    Ini juga dapat berupa @next, yang mempromosikan rilis secara otomatis ke target berikutnya setelah target ditentukan dalam properti selector.targets di konfigurasi otomatisasi ini. Ini adalah default jika Anda menghilangkan nilai dari destinationTargetId.

  • [TO_PHASE]

    Adalah nama fase yang ingin Anda promosikan, misalnya canary-25 atau stable. Properti ini bersifat opsional; jika Anda menghapusnya, rilis akan dipromosikan ke fase pertama dalam target.

Mengonfigurasi aturan otomatisasi timedPromoteReleaseRule

Aturan timedPromoteReleaseRule memungkinkan Anda menjadwalkan kapan harus mempromosikan rilis dari target yang dipilih ke target berikutnya dalam progres, atau ke target yang ditentukan. Saat mengonfigurasi otomatisasi timedPromoteReleaseRule, Anda menentukan kapan harus mempromosikan rilis, berdasarkan jadwal cron.

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dengan keterangan:

  • [RULE_NAME]

    Nama yang ingin Anda berikan untuk aturan ini. Nama ini harus unik dalam pipeline pengiriman.

  • [CRON]

    Adalah jadwal cron yang menentukan kapan rilis akan dipromosikan. Gunakan jadwal ini untuk menentukan tanggal dan waktu saat Anda ingin mempromosikan rilis.

    Jadwal ini menggunakan sintaksis cron standar:

    * * * * *

    Dalam jadwal ini...

    • Posisi pertama adalah menit (0-59).
    • Posisi kedua adalah jam (0-23).
    • Posisi ketiga adalah hari dalam sebulan (1-31).
    • Posisi keempat adalah bulan (1-12).
    • Posisi kelima adalah hari (0-6, Minggu hingga Sabtu)

    Misalnya, jika aturan promosi berjangka waktu Anda menyertakan jadwal berikut: 0 9 * * 1, rilis Anda akan dipromosikan setiap hari Senin pukul 09.00.

    Anda juga dapat menggunakan fitur jadwal cron standar, seperti:

    • Rentang (0-5)
    • Daftar (1,3,5)
    • Fungsi langkah (misalnya, */3 di kolom jam diaktifkan setiap jam ketiga)

  • [TIME_ZONE]

    Zona waktu yang ingin Anda gunakan untuk menjadwalkan promosi, dalam format IANA.

  • [TO_TARGET]

    Apakah targetId target yang akan dipromosikan, atau @next untuk mempromosikan rilis secara otomatis ke target berikutnya setelah target yang ditentukan dalam selector.targets property dalam konfigurasi otomatisasi ini. Ini bersifat opsional; defaultnya adalah @next.

  • [TO_PHASE]

    Adalah nama fase fase yang ingin Anda promosikan, misalnya canary-25 atau stable. Properti ini bersifat opsional; jika Anda menghapusnya, rilis akan dipromosikan ke fase pertama dalam target.

Mengonfigurasi aturan otomatisasi advanceRolloutRule

advanceRolloutRule akan memajukan peluncuran Anda secara otomatis setelah menyelesaikan satu fase, ke fase berikutnya. Aturan otomatisasi ini berguna untuk deployment canary. Misalnya, jika Anda memiliki strategi deployment canary yang dikonfigurasi di target, dengan fase 25%, 50%, dan stable, Anda dapat mengonfigurasi aturan otomatisasi yang otomatis memajukan fase ke stable setelah fase 50% selesai.

Saat mengonfigurasi otomatisasi advanceRolloutRule, Anda mengidentifikasi fase yang akan diajukan (sourcePhase). Stanza rules yang ditampilkan di sini berada di dalam definisi otomatisasi Anda.

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Dengan keterangan:

  • [RULE_NAME]

    Nama yang ingin Anda berikan untuk aturan ini. Nama ini harus unik dalam pipeline pengiriman.

  • [WAIT_TIME]

    Adalah jumlah waktu, dalam menit, yang harus ditunggu untuk melanjutkan peluncuran setelah peluncuran siap. Misalnya, 1m. m wajib diisi.

    Nilai defaultnya adalah 0, atau tidak ada waktu tunggu. Maksimalnya adalah 20160m (atau 14 hari).

  • ["[START_PHASE]", "[START_PHASE]"...]

    Fase atau fase tempat peluncuran otomatis dilanjutkan. Artinya, jika salah satu fase yang tercantum berhasil diselesaikan, peluncuran akan otomatis dilanjutkan dari fase tersebut ke fase berikutnya.

    Nama fase peka huruf besar/kecil. Selain itu, nama fase ini bersifat opsional; jika Anda menghapus sourcePhases, semua fase dalam peluncuran akan otomatis maju.

Mengonfigurasi aturan otomatisasi repairRolloutRule

Aturan repairRolloutRule mencoba ulang peluncuran yang gagal sejumlah kali yang ditentukan. Jika jumlah percobaan ulang tersebut habis, aturan ini dapat otomatis mencabut target ke rilis terakhir yang berhasil.

Saat mengonfigurasi otomatisasi repairRolloutRule, Anda dapat menentukan berapa kali untuk mencoba ulang peluncuran, dan waktu tunggu di antara percobaan ulang. Anda juga dapat mengonfigurasi fase atau tugas tertentu, atau keduanya, untuk dicoba ulang. Jika setiap upaya percobaan ulang gagal, peluncuran akan gagal. Jika percobaan ulang berhasil, otomatisasi akan berhenti dan peluncuran akan berhasil.

Secara opsional, Anda dapat mengonfigurasi otomatisasi untuk melakukan rollback ke rilis terakhir yang berhasil di target. Percobaan ulang juga bersifat opsional, tetapi Anda harus memiliki beberapa percobaan ulang atau rollback, atau keduanya.

Stanza rules yang ditampilkan di sini berada di dalam definisi otomatisasi Anda.

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

Dengan keterangan:

  • [RULE_NAME]

    Nama yang ingin Anda berikan untuk aturan ini. Nama ini harus unik dalam pipeline pengiriman.

  • [PHASES_TO_REPAIR]

    Fase peluncuran yang akan dicoba ulang. Ini bersifat opsional, dan setelan defaultnya adalah semua fase dalam peluncuran.

  • [JOBS_TO_REPAIR]

    Apakah tugas atau tugas yang akan dicoba ulang. Ini bersifat opsional, dan default-nya adalah semua tugas.

  • [NUMBER_OF_ATTEMPTS]

    Opsional, frekuensi untuk mencoba kembali peluncuran sebelum menganggapnya gagal.

  • [WAIT_TIME]

    Adalah jumlah waktu yang harus ditunggu di antara percobaan ulang. Misalnya, 1m untuk interval satu menit. Unit waktu (m dalam hal ini) wajib diisi.

    Jika mode adalah linear, interval ini sama untuk setiap percobaan ulang. Jika mode adalah exponential, interval akan meningkat setiap kali. (Lihat mode untuk mengetahui deskripsi lebih lanjut.)

  • backoffMode

    LINEAR atau EXPONENTIAL, yang menunjukkan apakah akan meningkatkan waktu antara penghentian atau tidak. Jika LINEAR, waktu antara percobaan ulang bersifat konstan, pada WAIT_TIME. Jika EXPONENTIAL, waktu di antara percobaan ulang akan berlipat ganda dengan setiap percobaan ulang berturut-turut. Default-nya adalah LINEAR.

    Misalnya, jika WAIT_TIME adalah 1m, dan backoffMode ditetapkan ke EXPONENTIAL, maka waktu antara kegagalan dan percobaan ulang pertama adalah 1 menit, waktu antara percobaan ulang pertama dan kedua adalah 2 menit, dan waktu antara percobaan ulang kedua dan ketiga adalah 4 menit.

  • rollback

    Opsional, apakah akan melakukan rollback peluncuran yang gagal atau tidak setelah semua upaya percobaan ulang habis.

  • [PHASE_NAME]

    Adalah nama fase tertentu yang ingin Anda rollback. Jika Anda menghapus toPhase, rollback akan ditetapkan secara default ke fase stable.

Membatalkan operasi otomatisasi repairRolloutRule

Jika Anda menjalankan salah satu perintah berikut pada peluncuran, otomatisasi repairRolloutRule akan dibatalkan:

Contoh

Berikut adalah contoh konfigurasi otomatisasi dengan repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Dalam otomatisasi ini, jika peluncuran gagal pada target yang diidentifikasi, peluncuran tersebut akan dicoba ulang hingga 3 kali, dengan waktu tunggu satu menit di antara upaya percobaan ulang. Jika semua upaya percobaan ulang gagal, rollback dimulai dengan membuat peluncuran baru untuk men-deploy rilis terbaru target yang berhasil ke target tersebut.

Langkah selanjutnya