Cara Microsoft memberikan perangkat lunak dengan DevOps

Microsoft memiliki pengalaman puluhan tahun memberikan layanan yang sangat dapat diskalakan ke lingkungan produksi. Ketika layanan dan lingkungan Microsoft telah diperluas, 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 harus mendukung tim yang menumpuk utang. Biaya tambahan berkembang melalui jalur pengiriman dan masuk ke dalam produksi.

Menghapus masa stabilisasi dengan cepat meningkatkan cara tim mengelola utang mereka. Daripada mendorong pekerjaan pemeliharaan penting ke periode stabilisasi, tim yang mengumpulkan utang harus menggunakan sprint berikutnya untuk mengejar target utang mereka. Tim dengan cepat belajar mengelola utang pengujian mereka selama sprint. Fitur disampaikan ketika terbukti dan sepadan dengan biaya implementasi.

Sepenuhnya mengotomatiskan alur

Sebagian besar peningkatan yang dapat segera diperoleh tim pengembangan adalah dengan sepenuhnya mengotomatiskan pipeline dari repositori kode hingga 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 lama waktu antara peluncuran, semakin menumpuk masalah. Jika kode tidak mutakhir, ada utang pengiriman.

Lebih mudah untuk bekerja dalam bagian yang lebih kecil dengan sering melakukan peluncuran. Ide ini mungkin tampak jelas dalam retrospeksi, tetapi pada saat itu bisa tampak tidak intuitif. Penyebaran yang sering juga memotivasi tim untuk memprioritaskan pembuatan alat dan alur penyebaran yang lebih efisien dan andal.

Menggunakan alat dalam perusahaan

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 seberapa banyak yang dapat diselesaikan oleh tim dan individu secara wajar selama periode waktu yang ditentukan, namun beberapa fitur akan tersedia lebih awal, dan sebagian lainnya akan muncul kemudian. Tim dapat memprioritaskan pekerjaan agar fitur paling penting dapat masuk ke 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

Insinyur dulu bekerja di bidang yang terpisah. Konflik penggabungan pada setiap cabang meningkat hingga pengembang 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 kemampuan Git untuk membuat cabang secara ringan. Manfaat rekayasa internal adalah menghilangkan hierarki cabang yang dalam dan limbahnya. Semua waktu yang biasanya dihabiskan untuk mengintegrasikan sekarang dialokasikan untuk 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

Pergeseran ke kanan untuk pengujian langsung dalam produksi membantu memastikan bahwa pengujian pra produksi valid, dan bahwa lingkungan produksi yang selalu berubah siap menangani penyebaran.

Pengujian dan metrik instrumen

Terlepas dari tempat aplikasi disebarkan, penting untuk menginstrumentasi 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 dari metrik, tim mempertimbangkan apa yang perlu diukur oleh metrik tersebut. 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 memasukkan metrik ke dalam 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

• Ini bukan garis lurus untuk mencapai dari A ke B, dan B bukanlah 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.