Bagikan melalui

Arsitektur garis besar CI/CD dengan Azure Pipelines

  • Artikel

Artikel ini menjelaskan alur kerja DevOps tingkat tinggi untuk menyebarkan perubahan aplikasi pada lingkungan penahapan dan produksi di Azure. Solusi ini menggunakan praktik integrasi berkelanjutan/penyebaran berkelanjutan (CI/CD) dengan Azure Pipelines.

Penting

Artikel ini membahas arsitektur CI/CD umum menggunakan Azure Pipelines. Ini tidak dimaksudkan untuk mencakup spesifikasi penyebaran ke lingkungan yang berbeda, seperti Azure App Services, Virtual Machines, dan Azure Power Platform. Spesifikasi platform penyebaran dibahas dalam artikel terpisah.

Arsitektur

Diagram Arsitektur alur CI/CD menggunakan Azure Pipelines.

Unduh file Visio dari arsitektur ini.

Nota

Meskipun artikel ini membahas CI/CD untuk perubahan aplikasi, Azure Pipelines juga dapat digunakan untuk membangun alur CI/CD untuk perubahan infrastruktur sebagai kode (IaC).

Aliran Data

Data mengalir melalui skenario sebagai berikut:

  1. alur PR - Permintaan pull (PR) ke Azure Repos Git memicu alur PR. Alur ini menjalankan pemeriksaan kualitas cepat. Pemeriksaan ini harus mencakup:

    • Membangun kode, yang memerlukan penarikan dependensi dari sistem manajemen dependensi.
    • Penggunaan alat untuk menganalisis kode, seperti analisis kode statis, linting, dan pemindaian keamanan
    • Pengujian unit

    Jika salah satu pemeriksaan gagal, eksekusi alur berakhir dan pengembang harus membuat perubahan yang diperlukan. Jika semua pemeriksaan lolos, alur harus memerlukan peninjauan PR. Jika tinjauan PR gagal, alur berakhir dan pengembang harus membuat perubahan yang diperlukan. Jika semua pemeriksaan dan ulasan PR lolos, PR akan berhasil digabung.

  2. CI pipeline - Penggabungan ke Azure Repos Git memicu CI pipeline. Alur ini menjalankan pemeriksaan yang sama dengan alur PR dengan beberapa tambahan penting. Alur CI menjalankan pengujian integrasi. Pengujian integrasi dapat intensif sumber daya, sehingga menjalankannya dalam alur CI menyeimbangkan kecepatan pengembangan dan deteksi bug. Penting juga untuk dicatat bahwa lulus tes dalam PR tidak selalu memastikan mereka akan berhasil setelah penggabungan, karena perubahan di cabang utama dapat memperkenalkan masalah baru, menyoroti kebutuhan pengujian pasca-penggabungan. Faktor-faktor ini membuat alur CI menjadi tempat yang lebih baik untuk pengujian integrasi daripada alur PR. Pengujian integrasi ini seharusnya tidak memerlukan penyebaran solusi, karena artefak build belum dibuat. Jika pengujian integrasi memerlukan rahasia, alur mendapatkan rahasia tersebut dari Azure Key Vault. Jika salah satu pemeriksaan gagal, alur berakhir dan pengembang harus membuat perubahan yang diperlukan. Hasil dari jalannya dengan sukses alur ini adalah pembuatan dan penerbitan artefak build.

  3. pemicu alur CD - Penerbitan artefak mengaktifkan alur CD.

  4. Rilis CD ke lingkungan penahapan - Jalur CD mengunduh artefak build yang dibuat dalam jalur CI dan menyebarkan solusi ke lingkungan penahapan. Alur kemudian menjalankan pengujian penerimaan terhadap lingkungan penahapan untuk memvalidasi penyebaran. Jika ada pengujian penerimaan yang gagal, alur berakhir dan pengembang harus membuat perubahan yang diperlukan. Jika pengujian berhasil, tugas validasi manual dapat diimplementasikan untuk mengharuskan seseorang atau grup memvalidasi penyebaran dan melanjutkan alur.

  5. rilis CD ke produksi - Jika intervensi manual dilanjutkan kembali, atau tidak ada intervensi manual yang diterapkan, pipeline akan merilis solusi ke produksi. Pipeline harus menjalankan uji asap dalam lingkungan produksi untuk memastikan rilis berfungsi seperti yang diharapkan. Jika langkah intervensi manual menghasilkan pembatalan, rilis gagal, atau uji asap gagal, rilis digulung balik, alur berakhir, dan pengembang harus membuat perubahan yang diperlukan.

  6. Monitoring - Azure Monitor mengumpulkan data observabilitas seperti log dan metrik sehingga operator dapat menganalisis data kesehatan, performa, dan penggunaan. Application Insights mengumpulkan semua data pemantauan khusus aplikasi, seperti jejak. Azure Log Analytics digunakan untuk menyimpan semua data tersebut.

Komponen

  • Repositori Azure Repos Git berfungsi sebagai repositori kode yang menyediakan kontrol versi dan platform untuk proyek kolaboratif.

  • Azure Pipelines menyediakan cara untuk membangun, menguji, mengemas, dan merilis aplikasi dan kode infrastruktur. Contoh ini memiliki tiga alur yang berbeda dengan tanggung jawab berikut:

    • Alur PR memvalidasi kode sebelum memungkinkan PR untuk bergabung melalui pengujian linting, bangunan, dan unit.
    • Alur CI berjalan setelah kode digabungkan. Mereka melakukan validasi yang sama dengan alur PR, tetapi menambahkan pengujian integrasi dan menerbitkan artefak hasil build jika semuanya berhasil.
    • Alur CD menyebarkan artefak build, menjalankan pengujian penerimaan, dan merilis ke produksi.

  • Umpan Artefak Azure memungkinkan Anda mengelola dan berbagi paket perangkat lunak, seperti Maven, npm, dan NuGet. Umpan artefak memungkinkan Anda mengelola siklus hidup paket Anda, termasuk penerapan versi, mempromosikan, dan menghentikan paket. Ini membantu Anda memastikan bahwa tim Anda menggunakan versi terbaru dan paling aman dari paket Anda.

  • Key Vault menyediakan cara untuk mengelola data aman untuk solusi Anda, termasuk rahasia, kunci enkripsi, dan sertifikat. Dalam arsitektur ini, digunakan untuk menyimpan rahasia aplikasi. Rahasia ini diakses melalui pipa data. Rahasia dapat diakses oleh Azure Pipelines dengan menggunakan tugas Key Vault atau menautkan rahasia dari Key Vault dengan.

  • Monitor adalah sumber daya pengamatan yang mengumpulkan dan menyimpan metrik dan log, telemetri aplikasi, dan metrik platform untuk layanan Azure. Gunakan data ini untuk memantau aplikasi, menyiapkan pemberitahuan, dasbor, dan melakukan analisis akar penyebab kegagalan.

  • Application Insights adalah layanan pemantauan yang memberikan wawasan real time tentang performa dan penggunaan aplikasi web Anda.

  • ruang kerja Analitik Log menyediakan lokasi pusat tempat Anda dapat menyimpan, mengkueri, dan menganalisis data dari beberapa sumber, termasuk sumber daya, aplikasi, dan layanan Azure.

Alternatif

Meskipun artikel ini berfokus pada Azure Pipelines, Anda dapat mempertimbangkan alternatif ini:

  • Azure DevOps Server dapat digunakan sebagai pengganti lokal.

  • Jenkins adalah alat sumber terbuka yang digunakan untuk mengotomatiskan build dan penyebaran.

  • GitHub Actions memungkinkan Anda mengotomatiskan alur kerja CI/CD langsung dari GitHub.

  • Repositori GitHub dapat diganti sebagai repositori kode. Azure Pipelines terintegrasi dengan mulus dengan repositori GitHub.

Artikel ini berfokus pada praktik CI/CD umum dengan Azure Pipelines. Berikut ini adalah beberapa lingkungan komputasi yang dapat Anda pertimbangkan untuk menyebarkan:

  • App Service adalah layanan berbasis HTTP untuk menghosting aplikasi web, REST API, dan back end seluler. Anda dapat mengembangkan dalam bahasa favorit Anda, dan aplikasi berjalan dan menskalakan dengan mudah di lingkungan berbasis Windows dan Linux. Web Apps mendukung slot penyebaran seperti uji coba dan produksi. Anda dapat menyebarkan aplikasi ke slot penahapan dan merilisnya ke slot produksi.

  • Azure Virtual Machines menangani beban kerja yang memerlukan tingkat kontrol tinggi, atau bergantung pada komponen dan layanan OS yang tidak dimungkinkan dengan Web Apps.

  • Azure Power Platform adalah kumpulan layanan cloud yang memungkinkan pengguna untuk membangun, menyebarkan, dan mengelola aplikasi tanpa perlu keahlian infrastruktur atau teknis.

  • Azure Functions adalah platform komputasi tanpa server yang dapat Anda gunakan untuk membangun aplikasi. Dengan Functions, Anda dapat menggunakan pemicu dan pengikatan untuk mengintegrasikan layanan. Functions juga mendukung slot penerapan seperti staging dan produksi. Anda dapat menyebarkan aplikasi ke slot uji coba dan merilisnya ke slot produksi.

  • Azure Kubernetes Service (AKS) adalah kluster Kubernetes terkelola di Azure. Kubernetes adalah platform orkestrasi kontainer sumber terbuka.

  • Azure Container Apps memungkinkan Anda menjalankan aplikasi kontainer di platform tanpa server.

Detail skenario

Menggunakan praktik CI dan CD yang terbukti untuk menyebarkan perubahan aplikasi atau infrastruktur memberikan berbagai manfaat termasuk:

  • Siklus rilis yang lebih pendek - Proses CI/CD otomatis memungkinkan Anda untuk menyebarkan lebih cepat daripada praktik manual. Banyak organisasi melakukan penerapan beberapa kali per hari.
  • Kualitas kode yang lebih baik - Gerbang kualitas dalam alur CI, seperti linting dan pengujian unit, menghasilkan kode kualitas yang lebih tinggi.
  • Penurunan risiko merilis - Praktik CI/CD yang tepat secara dramatis mengurangi risiko merilis fitur baru. Penyebaran dapat diuji sebelum rilis.
  • Peningkatan produktivitas - CI/CD otomatis membebaskan pengembang dari bekerja pada integrasi dan penyebaran manual sehingga mereka dapat fokus pada fitur baru.
  • Mengaktifkan rol balik - Meskipun praktik CI/CD yang tepat menurunkan jumlah bug atau regresi yang dirilis, kejadian tersebut masih dapat terjadi. CI/CD dapat mengaktifkan pemutaran kembali otomatis ke rilis sebelumnya.

Potensi kasus penggunaan

Pertimbangkan proses Azure Pipelines dan CI/CD untuk:

  • Mempercepat pengembangan aplikasi dan siklus hidup penyebaran.
  • Membangun kualitas dan konsistensi ke dalam proses build dan rilis otomatis.
  • Meningkatkan stabilitas dan waktu aktif aplikasi.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keunggulan operasional

  • Pertimbangkan untuk menerapkan Infrastructure as Code (IaC) untuk mendefinisikan infrastruktur Anda dan untuk mendistribusikannya dalam pipeline Anda.

  • Pertimbangkan untuk menggunakan salah satu Tugas Tokenisasi yang tersedia di pasar VSTS, yang dalam konteks ini sering merujuk ke proses di mana informasi sensitif (seperti kunci API, kata sandi, atau rahasia lainnya) diganti dengan token atau tempat penampung selama penyebaran atau konfigurasi.

  • Gunakan Variabel Rilis dalam definisi rilis Anda untuk mendorong perubahan konfigurasi lingkungan Anda. Variabel rilis dapat dicakup ke seluruh rilis atau lingkungan tertentu. Saat menggunakan variabel untuk informasi rahasia, pastikan Anda memilih ikon gembok.

  • Pertimbangkan untuk menggunakan agen yang dihost sendiri jika Anda menyebarkan ke sumber daya yang berjalan di jaringan virtual yang aman. Anda mungkin juga mempertimbangkan agen yang dikelola sendiri jika Anda menjalankan build dengan volume yang tinggi. Dalam kasus volume build yang tinggi, agen yang dihost sendiri dapat digunakan untuk mempercepat build dengan cara yang hemat biaya.

  • Pertimbangkan untuk menggunakan Application Insights dan alat pemantauan lainnya sedini mungkin dalam alur rilis Anda. Banyak organisasi hanya mulai memantau di lingkungan produksi mereka. Dengan memantau lingkungan Anda yang lain, Anda dapat mengidentifikasi bug sebelumnya dalam proses pengembangan dan menghindari masalah di lingkungan produksi Anda.

  • Pertimbangkan untuk menggunakan sumber daya pemantauan terpisah untuk produksi.

  • Pertimbangkan untuk menggunakan alur YAML alih-alih antarmuka Klasik. Alur YAML dapat diperlakukan seperti kode lainnya. Alur YAML dapat dimasukkan ke kontrol versi dan diberi versi, misalnya.

  • Pertimbangkan untuk menggunakan templat YAML untuk mempromosikan penggunaan kembali dan menyederhanakan alur. Misalnya, alur PR dan CI serupa. Templat berparameter tunggal dapat digunakan untuk kedua alur.

  • Pertimbangkan untuk membuat lingkungan selain penahapan dan produksi untuk mendukung aktivitas seperti pengujian penerimaan pengguna manual, pengujian kinerja dan beban, serta pemulihan.

Pengoptimalan biaya

Pengoptimalan biaya adalah tentang melihat cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Ringkasan pilar pengoptimalan biaya.

Biaya Azure DevOps bergantung pada jumlah pengguna di organisasi Anda yang memerlukan akses, bersama dengan faktor lain seperti jumlah build/rilis bersamaan yang diperlukan dan jumlah pengguna pengujian. Untuk informasi selengkapnya, lihat harga Azure DevOps.

Kalkulator harga ini memberikan perkiraan untuk menjalankan Azure DevOps dengan 20 pengguna.

Azure DevOps ditagih per pengguna per bulan. Mungkin ada lebih banyak biaya tergantung pada alur bersamaan yang diperlukan, selain pengguna pengujian atau lisensi dasar pengguna lainnya.

Keamanan

  • Pertimbangkan manfaat keamanan menggunakan agen yang dihosting Microsoft saat memilih apakah akan menggunakan agen yang dihosting Microsoft atau dihost sendiri.

  • Pastikan semua perubahan pada lingkungan dilakukan melalui alur. Terapkan kontrol akses berbasis peran (RBAC) pada prinsip hak istimewa paling sedikit, mencegah pengguna mengakses lingkungan.

  • Pertimbangkan untuk mengintegrasikan langkah-langkah di Azure Pipelines untuk melacak dependensi, mengelola lisensi, memindai kerentanan, dan menjaga dependensi hingga saat ini.

Langkah berikutnya

Tinjau sumber daya berikut untuk mempelajari selengkapnya tentang CI/CD dan Azure DevOps: