Apa itu alur kerja berbasis rilis?

  • 8 menit

Di sini, kami membahas bagaimana Anda dapat membuat alur kerja berbasis rilis menggunakan GitHub.

Apa itu alur kerja berbasis rilis?

Alur kerja berbasis rilis adalah serangkaian pola dan kebijakan yang berfokus pada melepaskan perangkat lunak. Meskipun gagasan ini mungkin tampak seperti tujuan yang jelas untuk tim pengembangan, nilai perspektif ini lebih bernuansa. Dalam unit ini kita membahas bagaimana hal itu mendorong tiga bagian siklus rilis yang berbeda: mengelola proyek, memilih strategi percabangan, dan merilis kepada pelanggan.

Merencanakan pekerjaan dengan papan proyek GitHub

Dari pola pikir perencanaan, menjadi rilis-sentris berarti bahwa masalah dibagi menjadi iterasi berbeda yang menghasilkan versi baru. Iterasi ini sering disebut sprint, dan dibatasi waktu dalam periode yang kira-kira sama untuk menghasilkan perubahan bertahap. Tim lain lebih suka mengemas seluruh versi rilis ke dalam satu iterasi yang dapat berlangsung beberapa bulan atau lebih lama. Di GitHub, iterasi ini dikelola sebagai proyek.

Fitur dominan dari sebuah proyek adalah dewannya. Papan adalah rencana pusat catatan untuk iterasi dan berisi semua kartu yang akan diselesaikan. Kartu dapat mewakili masalah, permintaan pull, atau bahkan hanya catatan umum.

Tangkapan layar pelacak Rilis 1.0.

Secara bawaan, setiap kartu dimulai di kolom To do dan berpindah ke kolom In progress setelah pekerjaan dimulai, dan berakhir di kolom Selesai. Anda dapat menyesuaikan kolom ini, menambahkan lebih banyak kolom, atau menerapkan otomatisasi ke pergerakan kartu ini dan propertinya agar sesuai dengan proses tim Anda.

Pelajari selengkapnya tentang mengelola papan proyek.

Status proyek kartu terintegrasi di seluruh repositori. Misalnya, menyeret kartu dari Untuk dilakukan ke Sedang berlangsung mengubah statusnya, dan memperbarui indikator visual di samping judul proyek. Bagian hijau menunjukkan bagian kartu yang ditandai sebagai Selesai, sedangkan ungu digunakan untuk kartu Sedang berlangsung. Ruang yang tersisa mewakili kuantitas kartu yang belum dimulai. Selain menyeret kartu di sekitar papan, Anda dapat memperbaruinya dari tampilan utama mereka.

Cuplikan layar dari memindahkan kartu proyek.

Ketika Anda menggunakan papan proyek, semua pemangku kepentingan memiliki cara mudah untuk memahami status dan kecepatan proyek. Anda juga dapat membuat papan yang dicakup untuk pengguna individual atau kumpulan repositori yang dimiliki oleh organisasi.

Pelajari selengkapnya tentang melacak kemajuan pekerjaan Anda dengan papan proyek.

Melacak milestone tertentu

Untuk tim, atau mungkin subset tim, GitHub menawarkan pelacakan pencapaian tonggak.

Cuplikan layar papan proyek GitHub.

Tonggak pencapaian mirip dengan pelacakan proyek karena ada penekanan pada penyelesaian masalah dan permintaan pull yang diprioritaskan. Namun, di mana proyek mungkin berfokus pada proses tim, tonggak pencapaian difokuskan pada produk.

Cuplikan layar situs yang siap untuk penyebaran pertama.

Pelajari selengkapnya tentang melacak kemajuan pekerjaan Anda dengan tonggak pencapaian.

Memilih strategi percabangan

Repositori yang memiliki beberapa pengembang yang bekerja secara paralel membutuhkan strategi percabangan yang terdefinisi dengan baik. Menyelesaikan pendekatan terpadu di awal proyek menghemat kebingungan dan frustrasi saat tim dan basis kode menskalakan.

Alur GitHub

Selain menyediakan platform untuk pengembangan perangkat lunak kolaboratif, GitHub juga menawarkan alur kerja yang ditentukan, yang dirancang untuk mengoptimalkan penggunaan berbagai fiturnya. Meskipun GitHub dapat bekerja dengan hampir semua proses pengembangan perangkat lunak, kami sarankan Anda mempertimbangkan alur GitHub jika tim Anda belum menyelesaikan proses.

Bekerja dengan cabang berumur panjang

Cabang berumur panjang adalah cabang Git yang tidak pernah dihapus. Beberapa tim lebih memilih untuk sepenuhnya menghindari perulangan demi fitur jangka pendek dan cabang perbaikan bug. Bagi tim-tim tersebut, tujuan dari upaya apa pun adalah untuk menghasilkan permintaan pull yang menggabungkan pekerjaan mereka kembali ke main. Pendekatan ini dapat efektif untuk proyek yang tidak pernah memiliki kebutuhan untuk melihat ke belakang, seperti aplikasi web pihak pertama yang tidak mendukung versi sebelumnya.

Namun, ada skenario tertentu di mana cabang berumur panjang melayani kepentingan terbaik tim. Kasus paling umum untuk cabang berumur panjang adalah ketika produk memiliki beberapa versi yang harus didukung untuk jangka waktu yang lama. Ketika tim perlu untuk merencanakan untuk komitmen ini, repositori harus mengikuti konvensi standar, seperti release-v1.0, release-v2.0, dan seterusnya. Cabang-cabang tersebut juga harus ditandai sebagai dilindungi di GitHub sehingga akses tulis dikontrol dan tidak dapat dihapus secara tidak sengaja.

Tim masih harus mempertahankan main sebagai cabang akar dan menggabungkan cabang rilis mereka berubah di upstram selama mereka sesuai dengan masa depan proyek. Ketika saatnya tiba, release-v3.0 harus didasarkan pada main sehingga pekerjaan servis karena release-v2.0 tidak memperumit repositori.

Melayani cabang berumur panjang

Misalkan perbaikan bug digabungkan ke dalam cabang release-v2.0, dan kemudian digabungkan lagi ke upstram ke dalam main. Kemudian ditemukan bahwa bug ini juga ada di cabang dan perbaikan perlu didukung untuk pelanggan yang masih menggunakan versi tersebut release-v1.0 . Apa cara terbaik untuk mendukung perbaikan ini?

main Menggabungkan cabang ke dalam release-v1.0 tidak akan menjadi opsi yang layak, karena akan berisi sejumlah besar penerapan yang tidak dimaksudkan untuk menjadi bagian dari versi itu. Untuk alasan yang sama, melakukan rebasing release-v1.0 ke penerapan saat ini main tidak akan menjadi pilihan.

Pilihan alternatif adalah dengan mengisi kembali perbaikan secara manual pada cabang release-v1.0, tetapi pendekatan itu akan membutuhkan banyak pengerjaan ulang dan tidak menskalakan dengan baik di beberapa versi. Namun, Git memang menawarkan solusi otomatis untuk masalah ini dalam bentuk perintah cherry-pick nya.

Apa itu perintah cherry-pick Git?

git cherry-pick adalah perintah yang memungkinkan Anda menerapkan penerapan tertentu dari satu cabang ke cabang lainnya. Ini hanya mengulangi penerapan yang dipilih dan menerapkannya ke cabang target sebagai penerapan baru. Jika perlu, pengembang dapat menggabungkan konflik apa pun sebelum menyelesaikan backport.

Pelajari lebih lanjut tentang Git cherry-pick.

Merilis ke konsumen

Ketika versi produk siap dirilis, GitHub menyederhanakan proses pengemasan dan memberi tahu konsumen.

Cuplikan layar pembuatan rilis GitHub.

Membuat versi sangatlah mudah seperti mengisi formulir:

  • Masukkan tag Git untuk diterapkan, yang harus mengikuti versi semantik, seperti v1.0.2. GitHub mengelola proses pembuatan tag Git yang Anda tentukan.
  • Masukkan naman untuk rilis Anda. Beberapa praktik umum adalah:
    • Menggunakan nama deskriptif
    • Menggunakan versi Git
    • Gunakan ringkasan ringkasan tentang bagaimana rilis berubah sejak yang sebelumnya
    • Menggunakan nama kode atau frasa acak
  • Memberikan catatan rilis. Anda dapat mengotomatiskan tugas ini dengan aplikasi Release Drafter, yang menganalisis perubahan sejak versi sebelumnya dan menyertakan judul permintaan pull terkait.
  • Jika Anda ingin menyediakan file sebagai bagian dari rilis, seperti alat penginstal bawaan, Anda dapat menyeret dan meletakkannya ke formulir. Anda tidak perlu mengemas sumber karena GitHub menanganinya untuk Anda secara otomatis.
  • Tunjukkan apakah versi telah dilewati dengan mencentang kotak tersebut. Indikasi ini membantu pelanggan menghindari versi prarilis jika mereka mau.

Cuplikan layar menampilkan rilis GitHub.

Setelah rilis diterbitkan, semua orang yang menonton repositori menerima pemberitahuan.

Pelajari selengkapnya tentang rilis GitHub.