Dasar untuk daftar ini adalah pengalaman beberapa tahun dalam mendukung otomatisasi untuk tim runtime container upstream (podman, buildah, skopeo, dll.). Saya tidak akan mengambil kredit penuh, karena banyak dari tips ini didasarkan pada campuran pengalaman yang berkembang dan kontribusi individu dari komunitas besar pengguna dan pengembang.
Sebagian besar item di bawah ini dapat diringkas menjadi satu prinsip:Hilangkan atau kurangi kerumitan . Konsep ini didasarkan pada aplikasi gabungan dari Hukum Murphy :Semakin banyak "barang pecah belah" yang Anda miliki, semakin besar kemungkinan Murphy akan muncul. Berikut adalah delapan cara untuk menghindari pertemuan kebetulan tersebut.
[ Pembaca juga menyukai: Memperkenalkan Ansible Automation Hub baru ]
1. Kurangi ketergantungan jaringan
Kurangi ketergantungan jaringan, terutama pada layanan pihak ketiga yang tidak dapat Anda kendalikan. Selain itu, layanan jaringan pihak pertama dan kedua harus dianggap "hindari jika memungkinkan." Sebenarnya ada dua aspek dari rekomendasi ini:
- Dari semua perspektif, jaringan adalah sistem yang sangat kompleks dari komponen terkait dan hubungan waktu nyata. Secara umum, semua ini harus beroperasi hampir tanpa cacat dari satu ujung ke ujung lainnya, atau Anda mungkin mengalami hari yang buruk.
- Sekali lagi, secara umum, kegagalan jaringan sering kali bersifat sementara dan bergantung pada waktu (semua orang menginginkannya diperbaiki dengan cepat). Ini dapat membuat proses debug setelah fakta menjadi sangat sulit. Bahkan dengan logging yang ekstensif, efek yang tidak teramati dapat memulai hari buruk Anda.
2. Kurangi ketergantungan perangkat lunak
Jika memungkinkan, kurangi ketergantungan perangkat lunak, terutama pada perpustakaan pihak ketiga. Ini mencakup subjek otomatisasi inti Anda dan kode otomatisasi bersama apa pun. Kecuali jika Anda mengunci versi setiap komponen ke atas dan ke bawah tumpukan, Anda berisiko mengalami kerusakan karena perilaku yang tidak terduga atau perubahan API di suatu tempat. Situasinya sedikit lebih baik ketika Anda mengontrol kode yang disertakan tetapi tetap menimbulkan risiko.
Catatan :Saya akan mengakui bahwa tip ini bisa sangat kontroversial, dan tentu saja tidak masuk akal dalam banyak situasi. Anggap ini sebagai pengingat "berpikir dua kali", terutama saat Anda ingin perpustakaan menghadirkan satu fungsi sederhana.
3. Atur tugas otomatisasi
Atur pekerjaan otomatisasi dalam urutan konsekuensi kegagalan yang menurun. Dengan kata lain, cobalah untuk menangkap item dengan dampak negatif terbesar sedini mungkin. Idenya di sini adalah untuk menghemat sumber daya (termasuk waktu) untuk "Whoopsies" yang berdampak tinggi dan berbiaya rendah. Beberapa contoh untuk pengujian integrasi berkelanjutan (CI) VCS:
- Apakah layanan jaringan pihak ketiga Anda dapat dijangkau? Misalnya, dapatkah mereka di-ping dan memvalidasi sertifikat SSL mereka?
- Apakah vendor Anda atau kode yang disertakan benar-benar cocok dengan daftar persyaratan yang didokumentasikan dan dikonfigurasi?
- Apakah seseorang secara tidak sengaja meninggalkan komentar "FIXME" di kode yang baru dibuat?
- Apakah semua komitmen baru telah ditandatangani?
- Apakah perubahan sesuai dengan konteks eksekusi, misalnya, perubahan yang tidak didokumentasikan selama pengujian rilis atau dokumentasi/update pengujian yang hilang dengan perubahan kode.
Seiring waktu, efek dari alur kerja ini adalah bahwa pemeriksaan penting akan mendapat perhatian paling besar dan pemeliharaan paling andal (karena kegagalan cenderung menahan seluruh rangkaian). Pada gilirannya, pengembang juga akan dapat melakukan siklus lebih cepat. Misalnya, mereka tidak akan menunggu lama hanya untuk mengetahui bahwa mereka salah mengeja nama mereka sendiri.
4. Persingkat pekerjaan
Buat pekerjaan sesingkat mungkin dan dalam "potongan" yang mudah diulang. Ini sebagian besar akan bergantung pada perangkat lunak orkestrasi, tetapi sebagian besar aplikasi memungkinkan beberapa tahap eksekusi. Menggunakan contoh pengujian CI lainnya, jika Anda memiliki pengujian unit, integrasi, dan sistem untuk dijalankan (dalam urutan itu), hindari menjalankan semuanya bersama-sama, satu demi satu, dalam satu skrip. Dengan cara ini, jika langkah integrasi gagal, pengguna tidak dipaksa untuk menjalankan kembali pengujian unit lagi. Hal ini meningkatkan keandalan dengan tidak menjalankan kembali operasi yang berlebihan, tanpa perlu mengundang Murphy kembali ke rangkaian roda gigi otomatisasi.
5. Hindari operasi yang tidak penting saat runtime
Hindari operasi yang tidak penting (seperti pemasangan atau konfigurasi) saat runtime. Sebagai gantinya, persiapkan lingkungan eksekusi Anda dengan semua bit yang diperlukan sebelumnya. Ini tidak hanya membuat segalanya berjalan lebih efisien, tetapi juga membantu untuk mematuhi tips lain dalam artikel ini. Ini juga memungkinkan pengamatan dan pengujian lingkungan pra-bangun pada waktu pembangunan. Jika lingkungan Anda digunakan bersama di seluruh pekerjaan dengan beberapa persyaratan yang berbeda, pertimbangkan untuk menyimpan komponen/paket tersebut di dalam gambar dalam cache. Menginstal saat runtime dari cache lokal jauh lebih aman dan lebih andal daripada menggunakan repositori jarak jauh melalui jaringan.
6. Gunakan alat yang tepat
Gunakan alat paling dasar yang tersedia untuk tugas yang ada. Misalnya, jika Anda perlu memverifikasi flag biner setelah menerapkan bit-mask, jangan coba melakukannya dalam skrip bash. Demikian pula, jika program C++ Anda hanya menjalankan serangkaian perintah, gunakan bash sebagai gantinya. Hal ini meningkatkan keandalan dengan tidak memaparkan operasi pada efek samping yang tidak terkait dengan tujuan inti pekerjaan.
7. Lacak kegagalan
Lacak kegagalan berdasarkan frekuensi tanda tangannya. Sebagian besar (tetapi tidak semua) waktu, kegagalan otomatisasi akan menghasilkan beberapa indikasi yang dicatat di suatu tempat. Identifikasi dan klasifikasikan (misalnya, berdasarkan nama permintaan) sehingga Anda dapat menyimpan catatan kejadian yang terpusat. Bisa dibilang ini membutuhkan sedikit kerja untuk dilakukan, mungkin mengharuskan Anda untuk belajar dan berinteraksi dengan beberapa layanan dan API. Namun, dengan hasil yang diurutkan berdasarkan frekuensi tanda tangan, Anda akan segera menemukan masalah mana yang paling banyak memengaruhi orang. Item tersebut harus mendapat perhatian paling besar dan akan memiliki dampak terbesar pada keandalan otomatisasi.
8. Gunakan komentar secara efektif
Komentar mengapa bukan bagaimana . Asumsikan setiap pembaca kode Anda dapat menentukan cara kerjanya. Mereka tidak dapat menentukan apa yang Anda (penulis) pikirkan ketika Anda menulis kode. Otomasi melibatkan banyak bagian yang bergerak. Beberapa hubungan mungkin tidak jelas bagi pembaca yang belum tahu. Komentar sangat berguna ketika memberi informasi tentang hubungan komponen.
Misalnya, perhatikan komentar berikut:
# Default variable value comes from CI unless executed manually.
# Detect this (`$CI == false`) to ensure the user did not leave
# the value blank. Anda harus dengan mudah membayangkan kode yang menghiasi ini—beberapa bentuk definisi atau validasi variabel. Selanjutnya, itu mengisyaratkan sumber informasi tambahan, "CI" (apa pun artinya dalam konteks skrip).
Komentar bermanfaat seperti ini tidak perlu menghiasi setiap baris skrip Anda; menargetkan mereka. Fokus pada item yang terpengaruh oleh file atau kekuatan eksternal (termasuk suar matahari). Detail ini membuat otomatisasi lebih andal dengan memastikan "saus rahasia" terus diberikan kepada siapa pun yang bertanggung jawab atas peningkatan atau pemeliharaan di masa mendatang.
[ Panduan gratis dari Red Hat:5 langkah untuk mengotomatisasi bisnis Anda. ]
Menutup
Dalam kebanyakan situasi, tidak mungkin untuk mengikuti semua tips ini. Mereka dimaksudkan sebagai pedoman untuk kompromi ketika implementasi alternatif masuk akal. Jika tidak, untuk melayani pemegang saham Anda dengan sebaik-baiknya, melanggar beberapa prinsip ini terkadang diperlukan. Namun, yang lain (seperti menulis komentar yang baik) akan cenderung memiliki efek yang halus namun stabil dari waktu ke waktu. Saya akan menjadi orang pertama yang mengakui bahwa melakukan sesuatu secara sederhana seringkali jauh lebih sulit daripada menampar lakban. Namun, seiring waktu, sebagian besar lakban menjadi kering dan berkerak, mengharuskan Anda untuk memperbaiki kembali masalahnya. Bantulah diri Anda di masa depan, habiskan waktu untuk memperbaiki ke arah kesederhanaan dari awal.