Bagikan melalui

Pola DevOps

  • Artikel

Kodekan dari satu lokasi dan sebarkan ke beberapa target di lingkungan pengembangan, pengujian, dan produksi yang mungkin ada di pusat data lokal, cloud pribadi, atau cloud publik Anda.

Konteks dan masalah

Kontinuitas penyebaran aplikasi, keamanan, dan keandalan sangat penting bagi organisasi dan penting bagi tim pengembangan.

Aplikasi sering memerlukan refaktor kode untuk berjalan di setiap lingkungan target. Ini berarti bahwa aplikasi tidak sepenuhnya portabel. Aplikasi harus diperbarui, diuji, dan divalidasi saat berpindah melalui setiap lingkungan. Misalnya, kode yang ditulis dalam lingkungan pengembangan kemudian harus ditulis ulang untuk bekerja di lingkungan pengujian dan ditulis ulang saat akhirnya mendarat di lingkungan produksi. Selain itu, kode ini secara khusus terkait dengan host. Ini meningkatkan biaya dan kompleksitas pemeliharaan aplikasi Anda. Setiap versi aplikasi terkait dengan setiap lingkungan. Meningkatnya kompleksitas dan duplikasi meningkatkan risiko keamanan dan kualitas kode. Selain itu, kode tidak dapat dengan mudah disebarkan ulang saat Anda menghapus host yang gagal memulihkan atau menyebarkan host tambahan untuk menangani peningkatan permintaan.

Solusi

Pola DevOps memungkinkan Anda membuat, menguji, dan menyebarkan aplikasi yang berjalan di beberapa cloud. Pola ini menyatukan praktik integrasi berkelanjutan dan pengiriman berkelanjutan. Dengan integrasi berkelanjutan, kode dibuat dan diuji setiap kali anggota tim melakukan perubahan pada kontrol versi. Pengiriman berkelanjutan mengotomatiskan setiap langkah dari build ke lingkungan produksi. Bersama-sama, proses ini menciptakan proses rilis yang mendukung penyebaran di berbagai lingkungan. Dengan pola ini, Anda dapat menyusun kode, kemudian menyebarkan kode yang sama ke lingkungan premis, cloud privat yang berbeda, dan cloud publik. Perbedaan lingkungan memerlukan perubahan pada file konfigurasi daripada perubahan pada kode.

DevOps pattern

Dengan seperangkat alat pengembangan yang konsisten di seluruh lingkungan lokal, cloud privat, dan cloud publik, Anda dapat menerapkan praktik integrasi berkelanjutan dan pengiriman berkelanjutan. Aplikasi dan layanan yang digunakan menggunakan Pola DevOps dapat dipertukarkan dan dapat berjalan di salah satu lokasi ini, memanfaatkan fitur dan kemampuan cloud lokal dan publik.

Menggunakan alur rilis DevOps membantu Anda:

  • Memulai build baru berdasarkan penerapan kode ke satu repositori.
  • Secara otomatis menyebarkan kode yang baru Anda buat ke cloud publik untuk pengujian penerimaan pengguna.
  • Secara otomatis menyebarkan ke cloud privat setelah kode Anda lulus pengujian.

Masalah dan pertimbangan

Pola DevOps dimaksudkan untuk memastikan konsistensi di seluruh penyebaran terlepas dari lingkungan target. Namun, kemampuan bervariasi di seluruh lingkungan cloud dan lokal. Pertimbangkan poin-poin berikut:

  • Apakah fungsi, titik akhir, layanan, dan sumber daya lain dalam penyebaran Anda tersedia di lokasi penyebaran target?
  • Apakah artefak konfigurasi disimpan di lokasi yang dapat diakses di seluruh cloud?
  • Apakah parameter penyebaran akan berfungsi di semua lingkungan target?
  • Apakah properti khusus sumber daya tersedia di semua cloud target?

Untuk informasi selengkapnya, lihat Mengembangkan templat Azure Resource Manager untuk konsistensi cloud.

Selain itu, pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

Skalabilitas

Sistem otomatisasi penyebaran adalah titik kontrol utama dalam Pola DevOps. Implementasi dapat bervariasi. Memilih ukuran server yang benar bergantung pada ukuran beban kerja yang diharapkan. Biaya VM lebih besar untuk skala daripada kontainer. Namun, untuk menggunakan kontainer untuk penskalaan, proses build Anda harus berjalan dengan kontainer.

Ketersediaan

Ketersediaan dalam konteks DevPattern berarti dapat memulihkan informasi status apa pun yang terkait dengan alur kerja Anda, seperti hasil pengujian, dependensi kode, atau artefak lainnya. Untuk menilai persyaratan ketersediaan Anda, pertimbangkan dua metrik umum:

  • Recovery Time Objective (RTO) menentukan berapa lama Anda bisa melakukan pekerjaan tanpa sistem.

  • Recovery Point Objective (RPO) menunjukkan berapa banyak data yang dapat Anda hilangkan jika gangguan dalam layanan memengaruhi sistem.

Dalam praktiknya, RTO, dan RPO menyiratkan redundansi dan cadangan. Di cloud Azure global, ketersediaan bukanlah masalah pemulihan perangkat keras—ini adalah bagian dari Azure—melainkan memastikan Anda mempertahankan status sistem DevOps Anda. Di Azure Stack Hub, pemulihan perangkat keras mungkin menjadi pertimbangan.

Pertimbangan utama lainnya saat merancang sistem yang digunakan untuk otomatisasi penyebaran adalah kontrol akses dan pengelolaan hak yang tepat yang diperlukan untuk menyebarkan layanan ke lingkungan cloud. Hak apa yang diperlukan untuk membuat, menghapus, atau memodifikasi penyebaran? Misalnya, serangkaian hak biasanya diperlukan untuk membuat grup sumber daya di Azure dan satu lagi untuk menyebarkan layanan di grup sumber daya.

Pengelolaan

Desain sistem apa pun berdasarkan pola DevOps harus mempertimbangkan otomatisasi, pengelogan, dan peringatan untuk setiap layanan di seluruh portofolio. Gunakan layanan bersama, tim aplikasi, atau keduanya, dan lacak kebijakan dan tata kelola keamanan juga.

Sebarkan lingkungan produksi dan lingkungan pengembangan/pengujian dalam grup sumber daya terpisah di Azure atau Azure Stack Hub. Lalu, Anda dapat memantau setiap sumber daya lingkungan dan melakukan roll up biaya penagihan berdasarkan grup sumber daya. Anda juga dapat menghapus sumber daya sebagai satu set, yang berguna untuk penyebaran pengujian.

Kapan menggunakan pola ini

Gunakan pola ini untuk:

  • Anda dapat mengembangkan kode dalam satu lingkungan yang memenuhi kebutuhan pengembang, dan menyebarkan ke lingkungan khusus untuk solusi saat mungkin sulit untuk mengembangkan kode baru.
  • Anda dapat menggunakan kode dan alat yang diinginkan pengembang, selama mereka dapat mengikuti integrasi berkelanjutan dan proses pengiriman berkelanjutan dalam Pola DevOps.

Pola ini tidak direkomendasikan:

  • Jika Anda tidak dapat mengotomatiskan infrastruktur, penyediaan sumber daya, konfigurasi, identitas, dan tugas keamanan.
  • Jika tim tidak memiliki akses ke sumber daya cloud hibrid untuk menerapkan pendekatan Continuous Integration/Continuous Development (CI/CD).

Langkah berikutnya

Untuk mempelajari lebih lanjut tentang topik yang diperkenalkan dalam artikel ini:

Saat Anda siap menguji contoh solusi, lanjutkan dengan Panduan penyebaran solusi CI/CD hibrid DevOps. Panduan penyebaran memberikan petunjuk langkah demi langkah untuk menyebarkan dan menguji komponennya. Anda mempelajari cara menyebarkan aplikasi ke Azure dan Azure Stack Hub menggunakan alur integrasi berkelanjutan/pengiriman berkelanjutan hibrid (CI/CD).