Organisasi saat ini dari kode dan konfigurasi yang Anda gambarkan disusun oleh solusi teknis yang terlibat. Ini adalah desain yang buruk yang akan menambah banyak overhead dalam kegiatan pemeliharaan kami dan juga akan menambahkan banyak jebakan di jalan kami. Sebagai gantinya, organisasi itu harus terstruktur di sekitar artefak yang kami sebarkan.
Alasan untuk ini adalah bahwa kami ingin mempertimbangkan artefak ( misalnya gambar buruh pelabuhan atau paket perangkat lunak) sebagai objek dari kata kerja berikut:
- membangun
- uji
- menyebarkan
untuk mempertimbangkan set minimal tugas otomatis yang ingin kita lakukan. Jika kita ingin mengubah sesuatu tentang bagaimana kata kerja tes diimplementasikan, mudah untuk mengunjungi folder yang sesuai dengan artefak dalam repositori yang sesuai dan kemudian menemukan item otomatisasi khusus jenkins yang perlu diperbarui. Sebaliknya, jika resep otomasi terstruktur di sekitar solusi teknis, maka kita perlu mengetahui bahwa jenkins terlibat dalam prosedur pengujian dan menemukan item otomatisasi terkait artefak di sana. Dalam situasi yang kompleks, organisasi di sekitar solusi teknis membuat pembaruan sangat sulit, karena kita harus mengetahui secara apriori semua solusi teknis yang terlibat dalam beberapa layanan untuk memperbaruinya.
Misalnya repositori yang berisi kode untuk situs web dan layanan mikro "a" dapat memiliki sub-direktori berikut yang didedikasikan untuk operasi:
./ops/website
./ops/micro-service-a
masing-masing memiliki tiga skrip yang dipanggil build, testdan deploy. Sekarang organisasi item otomasi telah diklarifikasi, mari kita mengalihkan perhatian ke konfigurasi.
Kondisi dan persyaratan utama tentang organisasi konfigurasi ditetapkan oleh deploykata kerja ketika diterapkan pada artefak seperti layanan. Kata deploykerjanya harus memiliki parameter berikut:
- versi artefak untuk digunakan,
- target penyebaran artefak, yang menggambarkan lingkungan konkret tempat artefak yang digunakan akan dijalankan ( mis. kluster dan titik akhir yang harus diajak bicara)
- kredensial yang harus digunakan untuk terhubung ke titik akhir lainnya ( mis. database)
- konfigurasi runtime (seperti berapa lama entri cache seharusnya hidup, dll.)
Dari perspektif operasional, pemecahan parametrisasi ini sesuai dengan derajat alami kebebasan masalah penyebaran - selain dari kredensial yang dapat digabungkan dengan konfigurasi runtime, tetapi lebih baik memisahkannya untuk menghindari penyebarannya secara sembarangan.