Cara Microsoft memberikan perangkat lunak dengan DevOps

Microsoft memiliki pengalaman puluhan tahun memberikan layanan yang sangat dapat diskalakan ke lingkungan produksi. Karena layanan Microsoft dan lingkungan telah berkembang, praktik pengiriman mereka juga telah berkembang dari waktu ke waktu. Banyak pelanggan Microsoft juga telah mengadopsi dan mendapatkan manfaat dari praktik pengiriman yang efisien ini. Prinsip dan proses DevOps inti berikut dapat berlaku untuk upaya pengiriman perangkat lunak modern apa pun.

Untuk menerapkan proses pengiriman DevOps, Microsoft mengadopsi inisiatif berikut:

• Fokuskan pola pikir dan irama organisasi pada pengiriman.
• Membentuk tim otonom, akuntabel yang memiliki, menguji, dan memberikan fitur.
• Geser ke kanan untuk menguji dan memantau sistem dalam produksi.

Fokus pada pengiriman

Pengiriman lebih cepat adalah manfaat yang jelas yang dapat diukur dan dihargai oleh organisasi dan tim dengan mudah. Irama DevOps yang khas melibatkan siklus sprint pendek dengan penyebaran reguler ke produksi.

Khawatir kurangnya stabilitas produk dengan sprint pendek, beberapa tim telah mengkompensasi dengan periode stabilisasi pada akhir siklus sprint mereka. Teknisi ingin mengirimkan sebanyak mungkin fitur selama sprint, sehingga mereka menimbulkan utang pengujian yang harus mereka bayarkan selama stabilisasi. Tim yang mengelola utang mereka selama sprint kemudian harus mendukung tim yang membangun utang. Biaya tambahan dimainkan melalui alur pengiriman dan ke dalam produksi.

Menghapus masa stabilisasi dengan cepat meningkatkan cara tim mengelola utang mereka. Alih-alih mendorong pekerjaan pemeliharaan utama ke periode stabilisasi, tim yang membangun utang harus menghabiskan sprint berikutnya mengejar target utang mereka. Tim dengan cepat belajar mengelola utang pengujian mereka selama sprint. Fitur memberikan ketika terbukti dan sepadan dengan biaya penyebaran.

Mengotomatiskan alur sepenuhnya

Sebagian besar tim perbaikan dapat segera mendapatkan adalah sepenuhnya mengotomatiskan alur dari repositori kode ke produksi. Automation mencakup alur rilis dengan integrasi berkelanjutan (CI), pengujian otomatis, dan pengiriman berkelanjutan (CD).

Teams mungkin menghindari penyebaran karena sulit, tetapi semakin jarang mereka menyebarkan, semakin sulit. Semakin banyak waktu antara penyebaran, semakin banyak masalah menumpuk. Jika kode tidak segar, ada utang penyebaran.

Lebih mudah untuk bekerja dalam gugus yang lebih kecil dengan sering menyebarkan. Ide ini mungkin tampak jelas dalam pandangan belakang, tetapi pada saat itu bisa tampak berlawanan. Penyebaran yang sering juga memotivasi tim untuk memprioritaskan pembuatan alat dan alur penyebaran yang lebih efisien dan andal.

Menggunakan alat in-house

Microsoft menggunakan sistem manajemen rilis yang mereka buat, dan mengirimkannya kepada pelanggan. Satu investasi meningkatkan produktivitas tim dan produk Microsoft. Menggunakan sistem sekunder akan menyedot pengembangan dan kecepatan pengiriman.

Otonomi dan akuntabilitas tim

Tidak ada indikator kemajuan utama (KPI) tertentu yang mengukur produktivitas atau performa tim, atau apakah fitur sedang dilacak. Tim harus dapat mengelola rencana dan backlog mereka sendiri, sambil menemukan cara untuk menyelaraskan dengan tujuan organisasi.

Penting untuk berkomunikasi langsung dengan tim untuk melacak kemajuan. Alat harus memfasilitasi komunikasi, tetapi percakapan adalah cara paling transparan untuk berkomunikasi.

Memprioritaskan fitur

Tujuan penting adalah untuk fokus pada pengiriman fitur. Jadwal dapat menilai berapa banyak tim dan individu yang dapat diselesaikan secara wajar selama periode waktu tertentu, tetapi beberapa fitur akan dikirimkan lebih awal dan beberapa akan datang nanti. Teams dapat memprioritaskan pekerjaan sehingga fitur terpenting membuatnya untuk produksi.

Menggunakan layanan mikro

Layanan mikro menawarkan berbagai manfaat teknis yang meningkatkan dan menyederhanakan pengiriman. Layanan mikro juga memberikan batasan alami untuk kepemilikan tim. Ketika tim memiliki otonomi atas investasi dalam layanan mikro, mereka dapat memprioritaskan cara menerapkan fitur dan mengelola utang. Teams dapat fokus pada rencana untuk faktor-faktor seperti penerapan versi, terlepas dari keseluruhan layanan yang bergantung pada layanan mikro.

Bekerja di bagian utama

Teknisi digunakan untuk bekerja di cabang terpisah. Menggabungkan utang pada setiap cabang tumbuh sampai teknisi mencoba mengintegrasikan cabang mereka ke cabang utama. Semakin banyak tim dan insinyur di sana, semakin besar integrasinya.

Agar integrasi terjadi lebih cepat, lebih terus menerus, dan dalam gugus yang lebih kecil, teknisi sekarang bekerja di cabang utama. Salah satu alasan besar untuk pindah ke Git adalah penawaran Git bercabang ringan. Manfaat rekayasa internal adalah menghilangkan hierarki cabang yang dalam dan limbahnya. Semua waktu yang digunakan untuk dihabiskan untuk mengintegrasikan sekarang dituangkan ke dalam pengiriman.

Menggunakan bendera fitur

Beberapa fitur belum sepenuhnya selesai untuk penyebaran sprint, tetapi masih dapat memperoleh manfaat dari pengujian dalam produksi. Teams dapat menggabungkan dan menyebarkan kode ini dengan bendera fitur untuk mengaktifkan fitur untuk pengguna tertentu, seperti tim pengembangan atau segmen kecil adopsi awal. Bendera fitur mengontrol paparan tanpa berisiko masalah dengan basis pengguna secara keseluruhan, dan dapat membantu tim menentukan apakah dan cara menyelesaikan fitur.

Pengujian dalam produksi

Mengalihkan hak untuk menguji dalam produksi membantu memastikan bahwa pengujian pra-produksi valid, dan lingkungan produksi yang terus berubah siap untuk menangani penyebaran.

Pengujian dan metrik instrumen

Terlepas dari tempat aplikasi disebarkan, penting untuk melengkapi semuanya. Instrumentasi tidak hanya membantu mengidentifikasi dan memperbaiki masalah, tetapi dapat memberikan penelitian yang sangat berharga tentang penggunaan dan apa yang harus ditambahkan berikutnya.

Menguji pola ketahanan

Risiko untuk penyebaran yang kompleks adalah kegagalan bertingkat, di mana satu kegagalan komponen menyebabkan komponen dependen gagal, dan sebagainya sampai seluruh sistem rusak. Penting untuk dipahami di mana titik kegagalan tunggal (SPOF) dan bagaimana mereka dimitigasi, dan untuk menguji proses mitigasi, terutama dalam produksi.

Memilih metrik yang tepat

Merancang metrik bisa sulit. Kesalahan umum adalah menyertakan terlalu banyak metrik, untuk menghindari kehilangan apa pun. Tetapi ini dapat menyebabkan mengabaikan atau menyalahgunakan nilai metrik yang tidak memenuhi kebutuhan tertentu. Sebagai gantinya, tim Microsoft membutuhkan waktu untuk menentukan data yang mereka butuhkan untuk mengukur keberhasilan. Teams mungkin menambahkan atau mengubah metrik, tetapi memahami tujuan dari awal memfasilitasi proses tersebut.

Selain dasar metrik, tim mempertimbangkan apa yang mereka butuhkan metrik untuk diukur. Misalnya, kecepatan atau akselerasi perolehan pengguna mungkin merupakan metrik yang lebih berguna daripada jumlah total pengguna. Metrik bervariasi dari proyek ke proyek, tetapi yang paling membantu adalah mereka yang berpotensi mendorong keputusan bisnis.

Menggunakan metrik untuk memandu pekerjaan

Microsoft menyertakan metrik dengan ulasan di tingkat kepemimpinan tertinggi. Setiap enam minggu, organisasi menyajikan bagaimana mereka melakukan kesehatan, bisnis, skenario, dan telemetri pelanggan. Organisasi mendiskusikan metrik dengan eksekutif dan dengan tim mereka.

Tim di seluruh organisasi memeriksa metrik pengguna yang terlibat untuk menentukan arti untuk fitur mereka. Teams tidak hanya mengirim fitur, tetapi melihat apakah dan bagaimana orang menggunakannya. Teams menggunakan metrik ini untuk menyesuaikan backlog dan menentukan apakah fitur memerlukan lebih banyak pekerjaan untuk memenuhi tujuan.

Pedoman pengiriman

• Jalan tidak pernah mulus untuk melangkah dari A ke B, B juga bukan titik akhir.
• Akan selalu ada kemunduran dan kesalahan.
• Lihat kemunduran sebagai peluang pembelajaran untuk mengubah taktik untuk menyelesaikan bagian tertentu dari proses.
• Seiring waktu, setiap tim mengembangkan praktik DevOps-nya dengan membangun pengalaman dan menyesuaikan untuk memenuhi kebutuhan yang berubah.
• Kuncinya adalah fokus pada memberikan nilai, baik kepada pengguna akhir maupun ke proses pengiriman itu sendiri.