Memahami peran DSC dalam alur CI/CD

Artikel ini menjelaskan jenis pendekatan yang tersedia untuk menggabungkan konfigurasi dan sumber daya. Tujuan untuk setiap skenario sama, untuk mengurangi kompleksitas ketika beberapa konfigurasi lebih disukai untuk mencapai status akhir penyebaran server. Contohnya adalah beberapa tim yang berkontribusi pada hasil penyebaran server, seperti pemilik aplikasi yang mempertahankan status aplikasi dan tim pusat yang merilis perubahan pada garis besar keamanan. Nuansa setiap pendekatan termasuk manfaat dan risiko dirinci di sini.

Jenis Teknik Penulisan Kolaboratif

Ada dua solusi bawaan Configuration Manager Lokal untuk mengaktifkan konsep ini:

Konsep	Informasi Terperinci
Konfigurasi Parsial	Dokumentasi
Sumber Daya Komposit	Dokumentasi

Memahami Dampak Setiap Pendekatan

Salah satu solusi ini dapat digunakan untuk mengelola hasil penyebaran server. Namun, ada perbedaan signifikan dalam dampak penggunaan setiap pendekatan.

Konfigurasi Parsial

Saat menggunakan Konfigurasi Parsial, Configuration Manager Lokal dikonfigurasi untuk mengelola beberapa konfigurasi secara independen. Konfigurasi dikompilasi secara independen dan kemudian ditetapkan ke simpul. Ini mengharuskan LCM dikonfigurasi terlebih dahulu dengan nama setiap konfigurasi.

Konfigurasi Parsial menyediakan dua, atau lebih, tim kontrol penuh atas konfigurasi server, sering kali tanpa manfaat komunikasi atau kolaborasi.

Pelanggan telah memberikan umpan balik bahwa ini dapat menyebabkan konflik sumber daya, penimpaan yang tidak disengaja, dan pada akhirnya kehilangan kontrol konfigurasi aset yang sebenarnya.

Selain itu, pelanggan telah memberikan umpan balik bahwa saat menggunakan model ini, setiap tim yang mengontrol perubahan konfigurasi tidak mungkin sepenuhnya diuji melalui alur rilis, yang mengarah ke hasil yang tidak terduga dalam produksi.

Sangat penting bahwa satu alur digunakan untuk mengevaluasi semua perubahan yang dirilis ke server.

Dalam ilustrasi di bawah ini, Tim B merilis konfigurasi parsial mereka ke Tim A. Tim A kemudian menjalankan pengujian mereka terhadap server dengan kedua konfigurasi diterapkan. Dalam model ini, hanya satu otoritas yang memiliki izin untuk membuat perubahan dalam produksi.

Ketika perubahan diperlukan dari Tim B, mereka harus mengirimkan Permintaan Pull terhadap lingkungan kontrol sumber Tim A. Tim A kemudian akan meninjau perubahan menggunakan otomatisasi pengujian dan rilis ke produksi ketika ada keyakinan bahwa perubahan tidak akan menyebabkan kesalahan dalam aplikasi atau layanan yang dihosting oleh server.

Sumber Daya Komposit

Sumber daya komposit hanyalah Konfigurasi DSC yang dikemas sebagai sumber daya. Tidak ada persyaratan khusus untuk mengonfigurasi LCM untuk menerima sumber daya komposit. Sumber daya digunakan dalam konfigurasi baru dan satu kompilasi menghasilkan satu file MOF.

Ada dua skenario umum untuk sumber daya komposit. Yang pertama adalah mengurangi kompleksitas dan konsep unik abstrak. Yang kedua adalah memungkinkan garis besar dipaketkan bagi tim aplikasi untuk menyebarkan dengan aman melalui alur rilis mereka ke produksi setelah semua pengujian lulus.

Configuration Name
{
  File 1
  {
    Ensure = "Present"
    Path = "c:\inetpub\file1.zip"
    Source = "http://uri/file1.zip"
  }
  Service A
  {
    Ensure = "Present"
    Name = "ServiceA"
    Status = "Running"
  }
  SecurityBaseline Settings
  {
    Ensure = "Present"
    Datacenter = "NorthAmerica"
  }
}

Sumber daya komposit mempromosikan komposisi dan kolaborasi menggunakan alur sambil membangun kematangan operasional.

Anda mungkin sudah menggunakan sumber daya komposit tanpa menyadarinya. Contohnya adalah ServiceSet. Sumber daya ini mengelola status beberapa Layanan Windows tanpa mencantumkannya satu per satu. Properti Nama menerima array string untuk memberikan nama setiap layanan. Saat konfigurasi dikompilasi, MOF akan berisi bagian Layanan unik untuk setiap Nama yang diteruskan ke ServiceSet.

Organisasi mungkin memiliki "agen" atau "middleware" yang harus diinstal di setiap server. Sumber daya komposit adalah jawaban terbaik untuk mengelola dependensi, penyiapan, dan konfigurasi alat dan utilitas tersebut.

Orang atau tim yang bertanggung jawab atas solusi yang mencakup beberapa server menulis konfigurasi yang berisi persyaratan mereka. Selanjutnya, konfigurasi akan dibungkus sebagai sumber daya komposit menggunakan instruksi yang disediakan dalam dokumentasi sumber daya komposit. Terakhir, sumber daya komposit baru harus diterbitkan ke lokasi seperti berbagi file atau umpan NuGet tempat tim aplikasi dapat menggunakannya dalam konfigurasi mereka.

Setiap kali tim merilis versi baru, mereka akan menaikkan nomor versi dalam manifes modul untuk sumber daya komposit mereka. Tim aplikasi menyertakan sumber daya komposit dalam konfigurasi yang mereka tulis untuk mengelola dependensi aplikasi. Ketika tim Operasi/Keamanan merilis versi baru sumber daya mereka, mereka memberi tahu tim aplikasi tentang perubahan baru.

Tim aplikasi mungkin memicu rilis ke produksi di mana satu-satunya perubahan adalah garis besar. Namun, ini memberikan kesempatan untuk mengevaluasi dampak pada aplikasi sebelum risiko pemadaman layanan.

Catatan

Umpan balik mengenai penggunaan sumber daya komposit telah mencakup kritik bahwa membuat perubahan memerlukan kompilasi dan merilis MOF baru. Ini memang disengaja. Setiap rilis konfigurasi baru harus menyertakan referensi statis ke versi tertentu dari setiap sumber daya, dan harus divalidasi oleh pengujian sebelum mencapai node server produksi. Proses pengujian dan melepaskan perubahan dari kontrol sumber menciptakan lingkungan yang aman untuk merilis perubahan dalam batch kecil tetapi sering.