Share via

Praktik DevOps untuk LUIS

  • Artikel

Penting

LUIS akan dihentikan pada 1 Oktober 2025 dan mulai 1 April 2023 Anda tidak akan dapat membuat sumber daya LUIS baru. Sebaiknya migrasikan aplikasi LUIS Anda ke pemahaman bahasa percakapan untuk mendapatkan manfaat dari dukungan produk berkelanjutan dan kemampuan multibahasa.

Teknisi perangkat lunak yang mengembangkan aplikasi Pemahaman Bahasa (LUIS) dapat menerapkan praktik DevOps seputar kontrol sumber, pembangunan otomatis, pengujian, dan manajemen rilis dengan mengikuti panduan ini.

Kontrol sumber dan strategi cabang untuk LUIS

Salah satu faktor kunci yang bergantung pada keberhasilan DevOps adalah kontrol sumber. Sistem kontrol sumber memungkinkan pengembang untuk berkolaborasi dalam kode dan melacak perubahan. Penggunaan cabang memungkinkan pengembang untuk beralih di antara berbagai versi basis kode, dan bekerja secara independen dari anggota tim lainnya. Saat pengembang mengajukan permintaan pull (PR) untuk mengusulkan pembaruan dari satu cabang ke cabang lainnya, atau saat perubahan digabungkan, ini dapat menjadi pemicu pembangunan otomatis untuk membangun dan terus menguji kode.

Dengan menggunakan konsep dan panduan yang dijelaskan dalam dokumen ini, Anda dapat mengembangkan aplikasi LUIS sambil melacak perubahan dalam sistem kontrol sumber, dan mengikuti praktik terbaik rekayasa perangkat lunak berikut:

  • Kontrol Sumber

    • Kode sumber untuk aplikasi LUIS Anda dalam format yang dapat dibaca manusia.
    • Model dapat dibangun dari sumber dengan cara yang berulang.
    • Kode sumber dapat dikelola oleh repositori kode sumber.
    • Info masuk dan rahasia, seperti kunci tidak pernah disimpan dalam kode sumber.

  • Pencabangan dan Penggabungan

    • Pengembang dapat bekerja dari cabang independen.
    • Pengembang dapat bekerja di beberapa cabang secara bersamaan.
    • Dimungkinkan untuk mengintegrasikan perubahan ke aplikasi LUIS dari satu cabang ke cabang lain melalui penentuan basis ulang atau penggabungan.
    • Pengembang dapat menggabungkan permintaan pull ke cabang induk.

  • Penerapan Versi

    • Setiap komponen dalam aplikasi besar harus diberi versi secara independen, memungkinkan pengembang mendeteksi perubahan atau pembaruan yang rusak hanya dengan melihat nomor versi.

  • Peninjauan Kode

    • Perubahan dalam permintaan pull disajikan sebagai kode sumber yang dapat dibaca manusia yang dapat ditinjau sebelum menerima permintaan pull.

Kontrol sumber

Untuk mempertahankan Definisi skema aplikasi dari aplikasi LUIS dalam sistem pengelolaan kode sumber, gunakan representasi format LUDown (.lu) dari aplikasi. Format .lu lebih disukai daripada format .json karena dapat dibaca manusia, yang memudahkan untuk membuat dan meninjau perubahan dalam permintaan pull.

Menyimpan aplikasi LUIS menggunakan format LUDown

Untuk menyimpan aplikasi LUIS dalam format .lu dan menempatkannya di bawah kontrol sumber:

  • BAIK: Mengekspor versi aplikasi sebagai .lu dari portal LUIS dan menambahkan ke repositori kontrol sumber Anda

  • ATAU: Menggunakan editor teks untuk membuat file .lu untuk aplikasi LUIS dan menambahkan ke repositori kontrol sumber Anda

Tip

Jika bekerja dengan ekspor JSON dari aplikasi LUIS, Anda dapat mengonversinya ke LUDown. Gunakan opsi --sort untuk memastikan bahwa niat dan ungkapan diurutkan menurut abjad.
Perhatikan bahwa kemampuan ekspor .LU yang dibangun ke dalam portal LUIS sudah mengurutkan output.

Membangun aplikasi LUIS dari sumber

Untuk aplikasi LUIS, membangun dari sumber berarti membuat versi aplikasi LUIS baru dengan mengimpor sumber .lu , untuk melatih versi dan untuk menerbitkan aplikasi. Anda dapat melakukan ini di portal LUIS, atau di baris perintah:

File untuk dipelihara di bawah kontrol sumber

Jenis file berikut untuk aplikasi LUIS Anda harus dipertahankan di bawah kontrol sumber:

Info masuk dan kunci tidak diperiksa

Jangan sertakan kunci atau nilai rahasia serupa dalam file yang Anda periksa ke repositori, di mana mereka mungkin terlihat oleh personel yang tidak berwenang. Kunci dan nilai lain yang harus Anda cegah dari cek masuk meliputi:

  • Kunci Penulisan dan Prediksi LUIS
  • Titik akhir Penulisan dan Prediksi LUIS
  • Kunci sumber daya Azure
  • Token akses, seperti token untuk perwakilan layanan Azure yang digunakan untuk autentikasi otomatisasi

Strategi untuk mengelola rahasia dengan aman

Strategi untuk mengelola rahasia dengan aman meliputi:

  • Jika menggunakan kontrol versi Git, Anda dapat menyimpan rahasia runtime di file lokal dan mencegah cek masuk file dengan menambahkan pola yang cocok dengan nama file menjadi file .gitignore
  • Dalam alur kerja otomatisasi, Anda dapat menyimpan rahasia dengan aman dalam konfigurasi parameter yang ditawarkan oleh teknologi otomatisasi tersebut. Misalnya, jika menggunakan Tindakan GitHub, Anda dapat menyimpan rahasia dengan aman di rahasia GitHub.

Pencabangan dan penggabungan

Sistem kontrol versi terdistribusi seperti Git memberikan fleksibilitas dalam cara anggota tim menerbitkan, berbagi, meninjau, dan mengulangi perubahan kode melalui cabang pengembangan yang dibagikan dengan orang lain. Gunakan strategi pencabangan Git yang sesuai untuk tim Anda.

Strategi pencabangan mana pun yang Anda adopsi, prinsip utama dari semuanya adalah bahwa anggota tim dapat mengerjakan solusi dalam cabang fitur secara terpisah dari pekerjaan yang sedang berlangsung di cabang lain.

Untuk mendukung kerja mandiri di cabang dengan proyek LUIS:

  • Cabang utama memiliki aplikasi LUIS sendiri. Aplikasi ini mewakili status solusi Anda saat ini untuk proyek dan versi aktifnya saat ini harus selalu dipetakan ke sumber .lu yang ada di cabang utama. Semua pembaruan pada sumber .lu untuk aplikasi ini harus ditinjau dan diuji sehingga aplikasi ini dapat disebarkan untuk membangun lingkungan seperti Produksi kapan saja. Saat pembaruan .lu digabungkan menjadi utama dari cabang fitur, Anda harus membuat versi baru di aplikasi LUIS dan mengganti nomor versi.

  • Setiap cabang fitur harus menggunakan instans aplikasi LUIS milik masing-masing cabang sendiri. Pengembang bekerja dengan aplikasi ini di cabang fitur tanpa risiko memengaruhi pengembang yang bekerja di cabang lain. Aplikasi 'cabang pengembang' ini adalah salinan pekerjaan yang harus dihapus ketika cabang fitur dihapus.

Cabang fitur Git

Pengembang dapat bekerja dari cabang independen

Pengembang dapat mengerjakan pembaruan pada aplikasi LUIS secara independen dari cabang lain dengan:

  1. Membuat cabang fitur dari cabang utama (tergantung strategi cabang Anda, biasanya utama atau dikembangkan).

  2. Buat aplikasi LUIS baru di portal LUIS ("aplikasi cabang pengembang") hanya untuk mendukung pekerjaan di cabang fitur.

    • Jika sumber .lu untuk solusi Anda sudah ada di cabang, karena telah disimpan setelah pekerjaan selesai di cabang lain sebelumnya dalam proyek, buat aplikasi LUIS cabang pengembang dengan mengimpor file .lu.

    • Jika mulai mengerjakan proyek baru, Anda belum memiliki sumber .lu untuk aplikasi LUIS utama di dalam repositori. Anda akan membuat file .lu dengan mengekspor aplikasi cabang pengembang dari portal ketika telah menyelesaikan pekerjaan cabang fitur, dan mengirimkannya sebagai bagian dari permintaan pull.

  3. Kerjakan versi aktif aplikasi cabang pengembang Anda untuk menerapkan perubahan yang diperlukan. Kami menyarankan Anda bekerja hanya dalam satu versi aplikasi cabang pengembang untuk semua pekerjaan cabang fitur. Jika Anda membuat lebih dari satu versi di aplikasi cabang pengembang, berhati-hatilah untuk melacak versi mana yang berisi perubahan yang ingin diperiksa saat menaikkan permintaan pull.

  4. Uji pembaruan - lihat Menguji DevOps LUIS untuk detail tentang pengujian aplikasi cabang pengembang Anda.

  5. Ekspor versi aktif aplikasi cabang pengembang Anda sebagai .lu dari daftar versi.

  6. Periksa pembaruan dan undang ulasan serekan dari pembaruan Anda. Jika menggunakan GitHub, Anda akan mengajukan permintaan pull.

  7. Ketika perubahan disetujui, gabungkan pembaruan ke cabang utama. Pada titik ini, Anda akan membuat versi baru dari aplikasi utama LUIS, menggunakan .lu yang diperbarui di utama. Lihat Penerapan Versi untuk pertimbangan dalam mengatur nama versi.

  8. Saat cabang fitur dihapus, ada baiknya untuk menghapus aplikasi LUIS cabang pengembang yang Anda buat untuk pekerjaan cabang fitur.

Pengembang dapat bekerja di beberapa cabang secara bersamaan

Jika mengikuti pola yang dijelaskan di atas dalam Pengembang dapat bekerja dari cabang independen, maka Anda akan menggunakan aplikasi LUIS unik di setiap cabang fitur. Pengembang tunggal dapat bekerja di beberapa cabang secara bersamaan, selama mereka beralih ke aplikasi LUIS cabang pengembang yang benar untuk cabang yang sedang mereka kerjakan.

Kami menyarankan Anda menggunakan nama yang sama untuk cabang fitur dan aplikasi LUIS cabang pengembang yang dibuat untuk pekerjaan cabang fitur, guna memperkecil kemungkinan Anda tidak sengaja bekerja pada aplikasi yang salah.

Seperti disebutkan di atas, kami menyarankan agar untuk kesederhanaan, Anda bekerja dalam satu versi di setiap aplikasi cabang pengembang. Jika Anda menggunakan beberapa versi, berhati-hatilah untuk mengaktifkan versi yang benar saat beralih di antara aplikasi cabang pengembang.

Beberapa pengembang dapat bekerja di cabang yang sama secara bersamaan

Anda dapat mendukung beberapa pengembang yang mengerjakan cabang fitur yang sama secara bersamaan:

  • Pengembang memeriksa cabang fitur yang sama dan mendorong dan menarik perubahan yang diajukan oleh mereka sendiri dan pengembang lain saat pekerjaan berlangsung, seperti biasa.

  • Jika Anda mengikuti pola yang dijelaskan di atas dalam Pengembang dapat bekerja dari cabang independen, maka cabang ini akan menggunakan aplikasi LUIS unik untuk mendukung pengembangan. Aplikasi LUIS 'cabang pengembang' tersebut akan dibuat oleh anggota pertama tim pengembangan yang mulai bekerja di cabang fitur.

  • Tambahkan anggota tim sebagai kontributor ke aplikasi LUIS cabang pengembang.

  • Saat pekerjaan cabang fitur selesai, ekspor versi aktif aplikasi LUIS cabang pengembang sebagai .lu dari daftar versi, simpan file .lu yang diperbarui dalam repositori, dan cek masuk dan permintaan pull perubahan.

Menggabungkan perubahan dari satu cabang ke cabang lain dengan penentuan basis ulang atau penggabungan

Beberapa pengembang lain di tim Anda yang bekerja di cabang lain mungkin telah membuat pembaruan pada sumber .lu dan menggabungkannya ke cabang utama setelah membuat cabang fitur. Anda mungkin ingin memasukkan perubahannya ke dalam versi kerja sebelum melanjutkan membuat perubahan sendiri dalam cabang fitur. Anda dapat melakukan hal ini dengan penentuan basis ulang atau gabungkan ke utama dengan cara yang sama seperti aset kode lainnya. Karena aplikasi LUIS dalam format LUDown dapat dibaca manusia, aplikasi ini mendukung penggabungan menggunakan alat gabungan standar.

Ikuti tips ini jika menentukan basis ulang aplikasi LUIS Anda di cabang fitur:

  • Sebelum Anda melakukan menentukan basis ulang atau menggabungkan, pastikan salinan lokal dari sumber .lu untuk aplikasi memiliki semua perubahan terbaru yang telah diterapkan menggunakan portal LUIS, dengan mengekspor ulang aplikasi dari portal terlebih dahulu. Dengan begitu, Anda dapat memastikan bahwa setiap perubahan yang dibuat di portal dan belum diekspor tidak hilang.

  • Selama penggabungan, gunakan alat standar untuk menyelesaikan konflik penggabungan apa pun.

  • Jangan lupa setelah penentuan basis ulang atau penggabungan selesai untuk mengimpor ulang aplikasi ke portal, sehingga Anda bekerja dengan aplikasi yang diperbarui saat Anda terus menerapkan perubahan Anda sendiri.

Gabungkan permintaan pull

Setelah permintaan pull disetujui, Anda dapat menggabungkan perubahan ke cabang utama. Tidak ada pertimbangan khusus yang berlaku untuk sumber LUDown untuk aplikasi LUIS: ini dapat dibaca manusia sehingga mendukung penggabungan menggunakan alat Penggabungan standar. Konflik penggabungan apa pun dapat diselesaikan dengan cara yang sama seperti file sumber lainnya.

Setelah permintaan pull Anda digabungkan, disarankan untuk membersihkan:

  • Menghapus cabang di repositori Anda

  • Hapus aplikasi LUIS 'cabang pengembang' yang Anda buat untuk pekerjaan cabang fitur.

Dengan cara yang sama seperti aset kode aplikasi, Anda harus menulis pengujian unit untuk menyertai pembaruan aplikasi LUIS. Anda harus menggunakan alur kerja integrasi berkelanjutan untuk menguji:

  • Pembaruan dalam permintaan pull sebelum permintaan pull digabungkan
  • Aplikasi LUIS cabang utama setelah permintaan pull disetujui dan perubahan telah digabungkan menjadi utama.

Untuk informasi selengkapnya tentang pengujian untuk DevOps LUIS, lihat Menguji DevOps untuk LUIS. Untuk detail selengkapnya tentang penerapan alur kerja, lihat Alur kerja otomatisasi untuk DevOps LUIS.

Peninjauan kode

Aplikasi LUIS dalam format LUDown dapat dibaca manusia, yang mendukung komunikasi perubahan dalam permintaan pull yang sesuai untuk ditinjau. File uji unit juga ditulis dalam format LUDown dan juga mudah ditinjau dalam permintaan pull.

Penerapan versi

Aplikasi terdiri dari beberapa komponen yang mungkin menyertakan hal-hal seperti bot yang berjalan di Azure AI Bot Service, QnA Maker, layanan Azure AI Speech, dan banyak lagi. Untuk mencapai tujuan aplikasi yang digabungkan secara longgar, gunakan kontrol versi sehingga setiap komponen aplikasi yang diberi versi secara independen, memungkinkan pengembang mendeteksi perubahan atau pembaruan yang rusak hanya dengan melihat nomor versi. Lebih mudah untuk membuat versi aplikasi LUIS Anda secara independen dari komponen lain jika mempertahankannya di repositori aplikasi LUIS sendiri.

Aplikasi LUIS untuk cabang utama harus memiliki skema penerapan versi yang diterapkan. Saat menggabungkan pembaruan ke .lu untuk aplikasi LUIS ke utama, Anda kemudian akan mengimpor sumber yang diperbarui tersebut ke versi baru di aplikasi LUIS untuk cabang utama.

Anda disarankan menggunakan skema penerapan versi numerik untuk versi aplikasi LUIS utama, misalnya:

major.minor[.build[.revision]]

Setiap pembaruan nomor versi yang dinaikkan pada digit terakhir.

Versi utama / minor dapat digunakan untuk menunjukkan cakupan perubahan pada fungsionalitas aplikasi LUIS:

  • Versi Utama: Perubahan signifikan, seperti dukungan untuk Niat atau Entitas baru
  • Versi Minor: Perubahan minor yang kompatibel ke belakang, seperti setelah pelatihan baru yang signifikan
  • Build: Tidak ada perubahan fungsionalitas, hanya build yang berbeda.

Setelah menentukan nomor versi untuk revisi terbaru aplikasi LUIS utama, Anda perlu membangun dan menguji versi aplikasi baru, dan menerbitkannya ke titik akhir yang dapat digunakan di lingkungan build yang berbeda, seperti Penjaminan Kualitas atau Produksi. Sangat disarankan agar Anda mengotomatiskan semua langkah ini dalam alur kerja Integrasi Berkelanjutan (CI).

Lihat:

  • Alur kerja otomatisasi untuk detail tentang cara menerapkan alur kerja CI untuk menguji dan merilis aplikasi LUIS.
  • Manajemen Rilis untuk informasi tentang cara menyebarkan aplikasi LUIS Anda.

Menerapkan versi aplikasi LUIS 'cabang fitur'

Saat Anda bekerja dengan aplikasi LUIS 'cabang pengembang' yang telah dibuat untuk mendukung pekerjaan di cabang fitur, Anda akan mengekspor aplikasi saat pekerjaan selesai dan akan menyertakan 'lu yang diperbarui dalam permintaan pull. Cabang di repositori Anda, dan aplikasi LUIS 'cabang pengembang' harus dihapus setelah permintaan pull digabungkan ke utama. Karena aplikasi ini hanya ada untuk mendukung pekerjaan di cabang fitur, tidak ada skema penerapan versi tertentu yang perlu Anda terapkan dalam aplikasi ini.

Saat perubahan permintaan pull Anda digabungkan menjadi yang utama, saat itulah penerapan versi harus diterapkan, sehingga semua pembaruan ke utama diberi versi secara independen.

Langkah berikutnya