Bagaimana Microsoft berkembang dengan DevOps

Microsoft berupaya menggunakan One Engineering System untuk membangun dan menyebarkan semua produk Microsoft dengan proses DevOps solid yang berpusat pada alur percabangan dan rilis Git. Artikel ini menyoroti implementasi praktis, bagaimana sistem menskalakan dari layanan kecil ke kebutuhan pengembangan platform besar-besaran, dan pelajaran yang dipelajari dari menggunakan sistem di berbagai tim Microsoft.

Mengadopsi proses pengembangan standar adalah usaha ambisius. Persyaratan berbagai organisasi Microsoft sangat bervariasi, dan persyaratan tim-tim yang berbeda di dalam organisasi bertambah seiring dengan ukuran dan kompleksitas. Untuk mengatasi berbagai kebutuhan ini, Microsoft menggunakan strategi percabangan berbasis batang untuk membantu mengembangkan produk dengan cepat, menyebarkannya secara teratur, dan memberikan perubahan dengan aman pada produksi.

Microsoft juga menggunakan prinsip-prinsip rekayasa platform sebagai bagian dari Sistem Rekayasa Satu.

Proses alur rilis Microsoft

Setiap organisasi harus menyelesaikan proses rilis kode standar untuk memastikan konsistensi di seluruh tim. Alur rilis Microsoft menggabungkan proses DevOps dari pengembangan hingga rilis. Langkah-langkah dasar alur rilis terdiri dari branch, push, pull request, dan merge.

Cabang

Untuk memperbaiki bug atau menerapkan fitur, pengembang membuat cabang baru dari cabang integrasi utama. Model percabangan ringan Git menciptakan cabang topik jangka pendek untuk setiap kontribusi kode. Pengembang berkomitmen lebih awal dan menghindari cabang fitur yang berjalan lama dengan menggunakan bendera fitur.

Beralih

Ketika pengembang siap untuk mengintegrasikan dan mengirimkan perubahan ke anggota tim lainnya, mereka mendorong cabang lokal mereka ke cabang di server, lalu membuka pull request. Repositori dengan beberapa ratus pengembang yang bekerja di banyak cabang menggunakan konvensi penamaan untuk cabang server untuk mengurangi kebingungan dan proliferasi cabang. Pengembang biasanya membuat cabang bernama users/<username>/feature, di mana <username> adalah nama akun mereka.

Permintaan tarik

Permintaan tarik mengontrol penggabungan cabang fitur ke cabang utama dan memastikan bahwa kebijakan cabang tersebut terpenuhi. Proses permintaan penarikan mengompilasi perubahan yang diusulkan dan menjalankan pengujian cepat. Suite pengujian tingkat pertama dan kedua menjalankan sekitar 60.000 pengujian dalam waktu kurang dari lima menit. Ini bukan matriks pengujian Microsoft lengkap, tetapi cukup untuk dengan cepat memberikan keyakinan dalam permintaan pull.

Selanjutnya, anggota tim lain meninjau kode dan menyetujui perubahan. Tinjauan kode melanjutkan dari pengujian otomatis yang ditinggalkan dan sangat berguna untuk mengidentifikasi masalah arsitektur. Tinjauan kode manual memastikan bahwa teknisi lain di tim memiliki visibilitas ke dalam perubahan dan kualitas kode tersebut tetap tinggi.

Merge

Setelah permintaan untuk menarik memenuhi semua kebijakan build dan peninjau memberikan persetujuan, cabang topik bergabung ke cabang integrasi utama, dan permintaan untuk menarik selesai.

Setelah penggabungan, pengujian penerimaan lainnya berjalan yang membutuhkan lebih banyak waktu untuk diselesaikan. Tes pasca-pemeriksaan tradisional ini melakukan validasi yang lebih menyeluruh. Proses pengujian ini memberikan keseimbangan yang baik antara memiliki tes cepat selama peninjauan permintaan pull dan memiliki cakupan pengujian lengkap sebelum rilis.

Perbedaan dengan GitHub Flow

GitHub Flow adalah alur rilis pengembangan berbasis batang populer bagi organisasi untuk menerapkan pendekatan yang dapat diskalakan ke Git. Namun, beberapa organisasi menemukan bahwa seiring bertambahnya kebutuhan mereka, mereka harus menyimpang dari bagian tertentu GitHub Flow.

Misalnya, bagian yang sering diabaikan dari GitHub Flow adalah bahwa permintaan pull harus disebarkan ke produksi untuk pengujian sebelum mereka dapat bergabung ke cabang utama. Proses ini berarti bahwa semua permintaan pull menunggu dalam antrean penyebaran untuk digabungkan.

Beberapa tim memiliki beberapa ratus pengembang yang bekerja terus-menerus dalam satu repositori, yang dapat menyelesaikan lebih dari 200 permintaan pull ke cabang utama per hari. Jika setiap permintaan pull memerlukan penyebaran ke beberapa pusat data Azure di seluruh dunia untuk pengujian, pengembang menghabiskan waktu menunggu cabang untuk digabungkan, alih-alih menulis perangkat lunak.

Sebagai gantinya, tim Microsoft terus mengembangkan di cabang utama dan mengelompokkan penyebaran ke dalam rilis terjadwal, biasanya selaras dengan irama sprint tiga minggu.

Detail implementasi

Berikut adalah beberapa detail implementasi utama alur rilis Microsoft:

Pendekatan repositori Git

Tim yang berbeda memiliki strategi yang berbeda untuk mengelola repositori Git mereka. Beberapa tim menyimpan sebagian besar kode mereka dalam satu repositori Git. Kode dipecah menjadi komponen, masing-masing di folder tingkat akarnya sendiri. Komponen besar, terutama komponen yang lebih lama, mungkin memiliki beberapa subkomponen yang memiliki subfolder terpisah dalam komponen induk.

Repositori ajungan

Beberapa tim juga mengelola repositori tambahan. Misalnya, agen dan tugas untuk build dan rilis, ekstensi VS Code, dan proyek sumber terbuka dikembangkan di GitHub. Perubahan konfigurasi dimasukkan ke dalam repositori terpisah. Paket lain yang dibutuhkan tim berasal dari berbagai sumber lain dan digunakan melalui NuGet.

Repositori mono atau multi-repositori

Sementara beberapa tim memilih untuk memiliki satu repositori monolitik, mono-repo, produk Microsoft lainnya menggunakan pendekatan multi-repositori . Skype, misalnya, memiliki ratusan repositori kecil yang dijahit bersama-sama dalam berbagai kombinasi untuk membuat banyak klien, layanan, dan alat yang berbeda. Terutama untuk tim yang merangkul layanan mikro, multi-repo dapat menjadi pendekatan yang tepat. Biasanya, produk lama yang dimulai sebagai monolit menemukan pendekatan mono-repo menjadi transisi paling mudah ke Git, dan organisasi kode mereka mencerminkan hal tersebut.

Cabang rilis

Alur rilis Microsoft menjaga cabang utama tetap dapat dibangun setiap saat. Pengembang bekerja di cabang topik jangka pendek yang bergabung ke main. Ketika tim siap untuk merilis, baik pada akhir sprint atau untuk pembaruan besar, mereka membuat cabang rilis baru dari cabang utama. Cabang rilis tidak pernah bergabung kembali ke cabang utama, sehingga mereka mungkin memerlukan cherry-picking perubahan penting.

Diagram berikut menunjukkan cabang berumur pendek yang ditandai dengan warna biru dan cabang rilis berwarna hitam. Satu cabang dengan komit yang membutuhkan pemilihan ceri muncul dengan warna merah.

Kebijakan dan izin cabang

Kebijakan cabang Git membantu menegakkan struktur cabang rilis dan menjaga cabang utama tetap bersih. Misalnya, kebijakan cabang dapat mencegah dorongan langsung ke cabang utama.

Untuk menjaga hierarki cabang tetap rapi, tim menggunakan izin untuk memblokir pembuatan cabang di tingkat akar hierarki. Dalam contoh berikut, semua orang dapat membuat cabang di folder seperti pengguna/, fitur/, dan tim/. Hanya manajer rilis yang memiliki izin untuk membuat cabang di bawah rilis/, dan beberapa alat otomatisasi memiliki izin ke integrasi/ folder.

Alur kerja repositori Git

Dalam repositori dan struktur cabang, pengembang melakukan pekerjaan sehari-hari mereka. Lingkungan kerja sangat bervariasi menurut tim dan oleh individu. Beberapa pengembang lebih suka baris perintah, yang lain seperti Visual Studio, dan yang lain bekerja pada platform yang berbeda. Struktur dan kebijakan yang diberlakukan pada repositori Microsoft memastikan fondasi yang solid dan konsisten.

Alur kerja umum melibatkan tugas umum berikut:

Membangun fitur baru

Membangun fitur baru adalah inti dari pekerjaan pengembang perangkat lunak. Bagian non-Git dari proses termasuk melihat data telemetri, datang dengan desain dan spesifikasi, dan menulis kode aktual. Kemudian, pengembang mulai bekerja dengan repositori dengan menyinkronkan ke commit terbaru pada main. Cabang utama selalu dapat dibangun, sehingga dijamin menjadi titik awal yang baik. Pengembang memeriksa cabang fitur baru, membuat perubahan kode, menerapkan, mendorong ke server, dan memulai permintaan pull baru.

Menggunakan kebijakan dan pemeriksaan cabang

Setelah membuat permintaan pull, sistem otomatis memeriksa bahwa kode baru dibuat, tidak merusak apa pun, dan tidak melanggar kebijakan keamanan atau kepatuhan apa pun. Proses ini tidak menghalangi pekerjaan lain untuk berlangsung secara paralel.

Kebijakan dan pemeriksaan cabang dapat memerlukan build yang berhasil termasuk pengujian yang lulus, persetujuan oleh pemilik kode yang terkait, dan beberapa pemeriksaan eksternal untuk memverifikasi kepatuhan terhadap kebijakan perusahaan sebelum permintaan tarik dapat diselesaikan.

Mengintegrasikan dengan Microsoft Teams

Banyak tim mengonfigurasi integrasi dengan Microsoft Teams, yang mengumumkan permintaan pull baru kepada rekan tim pengembang. Pemilik kode apa pun yang disentuh secara otomatis ditambahkan sebagai peninjau. Tim Microsoft sering menggunakan peninjau opsional untuk kode yang disentuh banyak orang, seperti pembuatan klien REST dan kontrol bersama, untuk mendapatkan pandangan ahli tentang perubahan tersebut.

Menyebarkan dengan bendera fitur

Setelah peninjau, pemilik kode, dan otomatisasi memberikan persetujuan, pengembang dapat menyelesaikan permintaan pull. Jika ada konflik penggabungan, pengembang mendapatkan instruksi tentang cara menyinkronkan ke konflik, memperbaikinya, dan mendorong kembali perubahan. Otomatisasi berjalan lagi pada kode tetap, tetapi manusia tidak perlu keluar lagi.

Cabang bergabung ke dalam main, dan kode baru disebarkan dalam sprint berikutnya atau rilis utama. Itu tidak berarti fitur baru akan segera muncul. Microsoft memisahkan penyebaran dan paparan fitur baru dengan menggunakan bendera fitur.

Bahkan jika fitur ini membutuhkan sedikit lebih banyak pekerjaan sebelum siap untuk ditampilkan, tetap aman untuk pergi ke main jika produk berhasil dibangun dan dideploy. Setelah masuk main, kode menjadi bagian dari build resmi, di mana kode tersebut kembali diuji, dikonfirmasi untuk memenuhi kebijakan, dan ditandatangani secara digital.

Geser ke kiri untuk mendeteksi masalah lebih awal

Alur kerja Git ini memberikan beberapa manfaat. Pertama, bekerja di satu cabang utama hampir menghilangkan utang penggabungan. Kedua, alur permintaan pull menyediakan titik umum untuk memberlakukan pengujian, peninjauan kode, dan deteksi kesalahan di awal alur. Strategi shift kiri ini membantu mempersingkat siklus umpan balik kepada pengembang karena dapat mendeteksi kesalahan dalam hitungan menit, bukan jam atau hari. Strategi ini juga memberikan keyakinan untuk pemfaktoran ulang, karena semua perubahan diuji terus-menerus.

Saat ini, produk dengan 200+ permintaan pull dapat menghasilkan 300+ build integrasi berkelanjutan per hari, berjumlah 500+ pengujian berjalan setiap 24 jam. Tingkat pengujian ini tidak mungkin dilakukan tanpa alur kerja percabangan dan rilis berbasis batang.

Rilis pada tahapan sprint

Di akhir setiap sprint, tim membuat cabang rilis dari cabang utama. Misalnya, di akhir sprint 129, tim membuat cabang rilis baru releases/M129. Tim kemudian meluncurkan cabang sprint 129 ke dalam produksi.

Setelah cabang cabang rilis, cabang utama tetap terbuka bagi pengembang untuk menggabungkan perubahan. Perubahan ini akan diimplementasikan tiga minggu kemudian dalam penyebaran sprint berikutnya.

Rilis pembaruan cepat

Terkadang perubahan perlu masuk ke produksi dengan cepat. Microsoft biasanya tidak akan menambahkan fitur baru di tengah sprint, tetapi terkadang ingin membawa perbaikan bug dengan cepat untuk membuka blokir pengguna. Masalah mungkin kecil, seperti kesalahan ketik, atau cukup besar untuk menyebabkan masalah ketersediaan atau insiden situs langsung.

Memperbaiki masalah ini dimulai dengan alur kerja normal. Pengembang membuat cabang dari main, mendapatkan tinjauan kode, dan menyelesaikan pull request untuk menggabungkan cabang tersebut. Proses selalu dimulai dengan terlebih dahulu membuat perubahan di main. Ini memungkinkan pembuatan perbaikan dengan cepat dan memvalidasinya secara lokal tanpa harus beralih ke cabang rilis.

Mengikuti proses ini juga menjamin bahwa perubahan masuk ke main, yang sangat penting. Memperbaiki bug di cabang rilis tanpa memasukkan perubahan kembali ke main berarti bug akan berulang selama penyebaran berikutnya, ketika sprint 130 bercabang dari main. Mudah untuk lupa memperbarui main di tengah kebingungan dan stres yang bisa muncul saat pemadaman. Membawa perubahan ke main yang pertama berarti selalu memiliki perubahan di cabang utama dan cabang rilis.

Fungsionalitas Git memungkinkan alur kerja ini. Untuk membawa perubahan segera ke dalam produksi, setelah pengembang menggabungkan permintaan pull ke main, mereka dapat menggunakan halaman permintaan pull untuk menarik perubahan ke cabang rilis. Proses ini membuat permintaan pull baru yang menargetkan cabang rilis, memindahkan kembali isi yang baru digabungkan ke dalam main.

Menggunakan fungsionalitas cherry-pick membuka sebuah pull request dengan cepat, yang memberikan keterlacakan dan keandalan kebijakan cabang. Cherry-picking dapat terjadi di server, tanpa harus mengunduh cabang rilis ke komputer lokal. Membuat perubahan, memperbaiki konflik penggabungan, atau membuat perubahan kecil karena perbedaan antara kedua cabang semuanya dapat terjadi di server. Teams dapat mengedit perubahan langsung dari editor teks berbasis browser atau melalui Ekstensi Konflik Penggabungan Pull Request untuk pengalaman yang lebih maju.

Setelah permintaan pull menargetkan cabang rilis, kode tim meninjaunya lagi, mengevaluasi kebijakan cabang, menguji permintaan pull, dan menggabungkannya. Setelah penggabungan, perbaikan dikirimkan ke lingkaran pertama server yang dalam hitungan menit. Dari sana, tim secara progresif menyebarkan perbaikan ke lebih banyak akun dengan menggunakan cincin penyebaran. Saat perubahan diterapkan ke lebih banyak pengguna, tim memantau keberhasilan dan memverifikasi bahwa perubahan memperbaiki bug sambil tidak memperkenalkan kekurangan atau perlambatan. Perbaikan akhirnya disebarkan ke semua pusat data Azure.

Lanjutkan ke sprint berikutnya

Selama tiga minggu ke depan, tim selesai menambahkan fitur ke sprint 130 dan bersiap untuk menyebarkan perubahan tersebut. Mereka membuat cabang rilis baru, releases/M130 dari main, dan menyebarkan cabang tersebut.

Saat ini, sebenarnya ada dua jalur produksi. Dengan penyebaran berbasis cincin untuk membawa perubahan pada produksi dengan aman, cincin cepat mendapatkan perubahan sprint 130, dan server cincin lambat tetap pada sprint 129 sementara perubahan baru divalidasi dalam produksi.

Perbaikan cepat di tengah proses penerapan mungkin memerlukan perbaikan cepat pada dua rilis berbeda, yaitu rilis sprint 129 dan rilis sprint 130. Tim mem-port dan menyebarkan perbaikan ke kedua cabang rilis. Cabang 130 dikirim ulang dengan hotfix ke cincin distribusi yang telah ditingkatkan. cabang 129 menyebarkan ulang dengan hotfix ke lingkar luar yang belum diperbarui ke versi sprint berikutnya.

Setelah semua cincin disebarkan, cabang sprint 129 lama ditinggalkan, karena setiap perubahan yang dibawa ke cabang sprint 129 sebagai perbaikan juga telah dibuat di main. Jadi, perubahan tersebut juga akan termasuk di cabang releases/M130.

Ringkasan

Model alur rilis adalah inti dari bagaimana Microsoft berkembang dengan DevOps untuk memberikan layanan online. Model ini menggunakan strategi percabangan berbasis batang sederhana. Tetapi alih-alih menjaga pengembang tetap terjebak dalam antrean penyebaran, menunggu untuk menggabungkan perubahan mereka, alur rilis Microsoft memungkinkan pengembang terus bekerja.

Model rilis ini juga memungkinkan penyebaran fitur baru di seluruh pusat data Azure secara teratur, meskipun ukuran basis kode Microsoft dan jumlah pengembang yang bekerja di dalamnya. Model ini juga memungkinkan membawa perbaikan ke dalam produksi dengan cepat dan efisien.