Buat deployment berikutnya dapat diulang

Kumpulkan input yang dapat diidentifikasi

Gunakan aplikasi yang dapat Anda bangun di lingkungan non-produksi, akses ke sumber dan registri artefaknya, skema konfigurasi berversi dan penyimpanan rahasia eksternal. Simpan rilis yang diketahui berfungsi. Ini adalah input untuk otomatisasi Anda; PrivacyNodes tidak menyediakan API penerapan atau pelari pipeline melalui situs web ini.

Sematkan artefak alih-alih mengandalkan label yang dapat berubah seperti latest. Docker mendokumentasikan penyematan digest untuk mengidentifikasi image dasar yang tepat, dengan kebutuhan untuk meninjau pembaruan secara sengaja. Reproduksibilitas dan penambalan keduanya adalah tanggung jawab: menyimpan image rentan lama selamanya bukanlah rencana pemeliharaan.

Referensi teknis: Praktik terbaik build Docker.

Tulis catatan rilis sebelum mengubah lalu lintas

Ini adalah format dokumen, bukan skrip yang dapat dieksekusi. Isi placeholder dari artefak yang telah ditinjau. Revisi sumber saja tidak mendeskripsikan perubahan lingkungan. Sertakan durasi migrasi yang diamati, perilaku kunci yang diharapkan, perbedaan konfigurasi dan artefak terakhir yang berfungsi.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Simpan catatan di tempat yang dapat dijangkau saat aplikasi mati. Referensikan kredensial pemulihan terlindungi tanpa menyertakan nilainya. Sebutkan pemelihara yang dapat menghentikan promosi dan titik setelah rollback yang direncanakan tidak lagi valid.

Pisahkan persiapan dari promosi

Bangun dan periksa artefak terlebih dahulu. Validasi konfigurasi dan referensi rahasia sebelum memulai proses baru. Terapkan hanya langkah skema yang ditinjau untuk rilis ini. Jalankan versi baru di lingkungan yang dimaksud dan periksa dependensi sebelum memindahkan lalu lintas; hindari menggabungkan migrasi destruktif yang belum ditinjau dengan pembaruan image biasa.

Dengan Compose, kontainer yang dimulai tidak menetapkan kesiapan. Pemeriksaan kesehatan yang bermakna dan condition: service_healthy dapat membuat penantian dependensi berguna, tetapi tidak dapat memverifikasi alur kerja pelanggan. Aplikasi tetap harus menangani dependensi yang menjadi tidak tersedia setelah startup.

Referensi teknis: Urutan startup Docker Compose.

Verifikasi lebih dari sekadar port yang hijau

Untuk API pelaporan, periksa permintaan uji yang terautentikasi, pembacaan terhadap skema yang dimaksud, satu ekspor kecil dalam antrean, dan akses ke filenya. Gunakan namespace uji khusus dan matikan notifikasi produksi. Pastikan versi yang tumpang tindih tidak dapat secara tidak sengaja menduplikasi pekerjaan terjadwal.

Tulis keluaran yang diharapkan sebelum pemeriksaan: cakupan akun yang benar, contoh catatan yang diharapkan, satu ekspor yang selesai, dan tidak ada data lintas akun yang tidak sah. Catat keluaran aktual dan waktunya setelahnya. Halaman beranda yang mengembalikan HTTP 200 tidak cukup jika worker berulang kali gagal atau migrasi membuat API membaca nilai usang.

Buat keputusan pemulihan eksplisit

Jika proses gagal dimulai, pertahankan lalu lintas pada versi yang berfungsi. Jika pemeriksaan alur kerja gagal, hentikan promosi dan simpan bukti yang telah disunting. Skema aditif yang kompatibel dengan artefak lama dapat memungkinkan rollback aplikasi. Setelah transformasi yang tidak kompatibel, kode lama bisa tidak aman; ikuti rencana perbaikan maju atau pemulihan data yang telah ditinjau.

Jangan mengulang migrasi yang gagal tanpa batas. Tentukan apa yang telah dikomit, apakah percobaan ulang aman, dan apakah pengguna menulis di bawah skema baru. panduan migrasi mengembangkan batas ini dengan perubahan kolom. Jangan menganggap keberadaan tombol rollback sebagai bukti bahwa data dapat dibalik.

Tinggalkan catatan yang dapat diikuti pemelihara lain

Bandingkan pengidentifikasi artefak dan konfigurasi yang diterapkan dengan catatan yang direncanakan. Simpan pemeriksaan, upaya yang gagal, dan tindakan pemulihan yang dipilih. Simpan artefak terakhir yang berfungsi di bawah kebijakan retensi yang eksplisit; jangan menghapusnya selama validasi belum selesai.

Rehearsal yang berguna memungkinkan pemelihara resmi lain menjelaskan input, mengulang pemeriksaan, dan menemukan instruksi pemulihan tanpa mencari riwayat shell Anda. Ini tidak membuktikan zero downtime atau keberhasilan di masa depan. Tinjau kembali ketika skema, perilaku worker, atau dependensi berubah. Selanjutnya, persempit izin identitas deployment.