Pengembangan Berbasis Batang vs. Aliran Git

Untuk mengembangkan perangkat lunak yang berkualitas, kita harus dapat melacak semua perubahan dan membalikkannya jika perlu. Sistem kontrol versi mengisi peran itu dengan melacak riwayat proyek dan membantu menggabungkan perubahan yang dibuat oleh banyak orang. Mereka sangat mempercepat pekerjaan dan memberi kami kemampuan untuk menemukan bug dengan lebih mudah.

Selain itu, bekerja dalam tim terdistribusi dimungkinkan terutama berkat alat ini. Mereka memungkinkan beberapa orang untuk mengerjakan bagian yang berbeda dari sebuah proyek pada saat yang sama dan kemudian menggabungkan hasil mereka menjadi satu produk. Mari kita lihat lebih dekat sistem kontrol versi dan jelaskan bagaimana pengembangan berbasis trunk dan aliran Git muncul.

Bagaimana Sistem Kontrol Versi Mengubah Dunia

Sebelum sistem kontrol versi dibuat, orang mengandalkan pencadangan versi proyek sebelumnya secara manual. Mereka menyalin file yang dimodifikasi dengan tangan untuk menggabungkan pekerjaan beberapa pengembang pada proyek yang sama.

Ini menghabiskan banyak waktu, ruang hard drive, dan uang.

Ketika kita melihat sejarahnya, kita dapat secara luas membedakan tiga generasi perangkat lunak kontrol versi.

Mari kita lihat mereka:

Kami melihat bahwa ketika sistem kontrol versi matang, ada kecenderungan untuk meningkatkan kemampuan untuk mengerjakan proyek secara paralel.

Salah satu perubahan yang paling inovatif adalah pergeseran dari mengunci file ke menggabungkan perubahan sebagai gantinya. Ini memungkinkan programmer untuk bekerja lebih efisien.

Perbaikan lain yang cukup besar adalah pengenalan sistem terdistribusi. Git adalah salah satu alat pertama yang menggabungkan filosofi ini. Ini benar-benar memungkinkan dunia open-source berkembang. Git memungkinkan pengembang untuk menyalin seluruh repositori, dalam operasi yang disebut forking, dan memperkenalkan perubahan yang diinginkan tanpa perlu khawatir tentang konflik penggabungan.

Kemudian, mereka dapat memulai permintaan tarik untuk menggabungkan perubahan mereka ke dalam proyek asli. Jika pengembang awal tidak tertarik untuk memasukkan perubahan tersebut dari repositori lain, maka mereka dapat mengubahnya menjadi proyek terpisah sendiri. Itu semua mungkin berkat fakta bahwa tidak ada konsep penyimpanan pusat.

Gaya Pengembangan

Saat ini, sistem kontrol versi yang paling populer pasti Git, dengan pangsa pasar sekitar 70 persen pada tahun 2016.

Git dipopulerkan dengan munculnya Linux dan sumber terbuka pada umumnya. GitHub, saat ini penyimpanan online paling populer untuk proyek publik, juga merupakan kontributor yang cukup besar untuk prevalensinya. Kami berutang pengenalan permintaan tarik yang mudah dikelola ke Git.

Sederhananya, permintaan tarik adalah permintaan yang dibuat oleh pengembang perangkat lunak untuk menggabungkan perubahan yang mereka buat dengan proyek utama. Ini termasuk proses meninjau perubahan tersebut. Peninjau dapat menyisipkan komentar pada setiap bagian yang menurut mereka dapat ditingkatkan, atau dianggap tidak perlu.

Setelah menerima umpan balik, pencipta dapat menanggapinya, membuat diskusi, atau cukup mengikutinya dan mengubah kodenya.

Git hanyalah sebuah alat. Anda dapat menggunakannya dengan berbagai cara. Saat ini, dua gaya pengembangan paling populer yang dapat Anda temui adalah aliran Git dan pengembangan berbasis trunk. Cukup sering, orang akrab dengan salah satu gaya itu dan mereka mungkin mengabaikan yang lain.

Mari kita lihat lebih dekat keduanya dan pelajari bagaimana dan kapan kita harus menggunakannya.

Aliran Git

Dalam model pengembangan aliran Git, Anda memiliki satu cabang pengembangan utama dengan akses ketat ke sana. Ini sering disebut cabang develop .

Pengembang membuat cabang fitur dari cabang utama ini dan mengerjakannya. Setelah selesai, mereka membuat permintaan tarik. Dalam permintaan tarik, pengembang lain mengomentari perubahan dan mungkin berdiskusi, seringkali cukup panjang.

Dibutuhkan beberapa waktu untuk menyetujui versi final dari perubahan. Setelah disetujui, permintaan tarik diterima dan digabungkan ke cabang utama. Setelah diputuskan bahwa cabang utama telah mencapai kedewasaan yang cukup untuk dirilis, cabang terpisah dibuat untuk menyiapkan versi final. Aplikasi dari cabang ini diuji dan perbaikan bug diterapkan hingga siap dipublikasikan ke pengguna akhir. Setelah selesai, kami menggabungkan produk akhir ke cabang master dan menandainya dengan versi rilis. Sementara itu, fitur-fitur baru dapat dikembangkan di cabang develop .

Di bawah ini, Anda dapat melihat diagram alur Git, yang menggambarkan alur kerja umum:

Salah satu keuntungan dari aliran Git adalah kontrol yang ketat. Hanya pengembang resmi yang dapat menyetujui perubahan setelah mengamatinya dengan cermat. Ini memastikan kualitas kode dan membantu menghilangkan bug lebih awal.

Namun, Anda harus ingat bahwa itu juga bisa menjadi kerugian besar. Ini menciptakan corong yang memperlambat pengembangan perangkat lunak. Jika kecepatan adalah perhatian utama Anda, maka itu mungkin masalah serius. Fitur yang dikembangkan secara terpisah dapat membuat cabang berumur panjang yang mungkin sulit untuk digabungkan dengan proyek utama.

Terlebih lagi, pull request memfokuskan tinjauan kode hanya pada kode baru. Alih-alih melihat kode secara keseluruhan dan bekerja untuk meningkatkannya, mereka hanya memeriksa perubahan yang baru diperkenalkan. Dalam beberapa kasus, mereka mungkin mengarah ke pengoptimalan prematur karena selalu memungkinkan untuk mengimplementasikan sesuatu agar berkinerja lebih cepat.

Selain itu, permintaan tarik dapat mengarah ke manajemen mikro yang ekstensif, di mana pengembang utama benar-benar mengelola setiap baris kode. Jika Anda memiliki pengembang berpengalaman yang dapat Anda percayai, mereka dapat menanganinya, tetapi Anda mungkin membuang waktu dan keterampilan mereka. Ini juga dapat sangat menurunkan motivasi pengembang.

Di organisasi yang lebih besar, politik kantor selama pull request menjadi perhatian lain. Dapat dibayangkan bahwa orang yang menyetujui permintaan tarik dapat menggunakan posisi mereka untuk dengan sengaja memblokir pengembang tertentu agar tidak membuat perubahan apa pun pada basis kode. Mereka bisa melakukan ini karena kurang percaya diri, sementara beberapa mungkin menyalahgunakan posisi mereka untuk menyelesaikan skor pribadi.

Kelebihan dan Kekurangan Git Flow

Seperti yang Anda lihat, melakukan permintaan tarik mungkin tidak selalu menjadi pilihan terbaik. Mereka harus digunakan jika sesuai saja.

Kapan Git Flow Bekerja Terbaik?

• Saat Anda menjalankan proyek sumber terbuka.
  Gaya ini berasal dari dunia sumber terbuka dan bekerja paling baik di sana. Karena setiap orang dapat berkontribusi, Anda ingin memiliki akses yang sangat ketat ke semua perubahan. Anda ingin dapat memeriksa setiap baris kode, karena sejujurnya Anda tidak dapat mempercayai orang yang berkontribusi. Biasanya, itu bukan proyek komersial, jadi kecepatan pembangunan tidak menjadi perhatian.

• Ketika Anda memiliki banyak pengembang junior.
  Jika Anda sebagian besar bekerja dengan pengembang junior, maka Anda ingin memiliki cara untuk memeriksa pekerjaan mereka dengan cermat. Anda dapat memberi mereka banyak petunjuk tentang cara melakukan sesuatu dengan lebih efisien dan membantu mereka meningkatkan keterampilan mereka lebih cepat. Orang yang menerima permintaan tarik memiliki kontrol ketat atas perubahan berulang sehingga mereka dapat mencegah penurunan kualitas kode.

  

• Ketika Anda memiliki produk yang mapan.
  Gaya ini juga tampaknya bermain dengan baik ketika Anda sudah memiliki produk yang sukses. Dalam kasus seperti itu, fokusnya biasanya pada kinerja aplikasi dan kemampuan memuat. Pengoptimalan semacam itu membutuhkan perubahan yang sangat tepat. Biasanya, waktu bukanlah kendala, jadi gaya ini bekerja dengan baik di sini. Terlebih lagi, perusahaan besar sangat cocok untuk gaya ini. Mereka perlu mengontrol setiap perubahan dengan cermat, karena mereka tidak ingin merusak investasi jutaan dolar mereka.

Kapan Aliran Git Dapat Menyebabkan Masalah?

• Ketika Anda baru memulai.
  Jika Anda baru memulai, maka aliran Git bukan untuk Anda. Kemungkinan Anda ingin membuat produk yang layak minimal dengan cepat. Melakukan permintaan tarik menciptakan hambatan besar yang memperlambat seluruh tim secara dramatis. Anda tidak mampu membelinya. Masalah dengan aliran Git adalah kenyataan bahwa permintaan tarik dapat memakan banyak waktu. Hanya saja tidak mungkin memberikan perkembangan pesat seperti itu.

• Saat Anda perlu mengulang dengan cepat.
  Setelah Anda mencapai versi pertama produk Anda, kemungkinan besar Anda perlu memutarnya beberapa kali untuk memenuhi kebutuhan pelanggan Anda. Sekali lagi, banyak cabang dan permintaan tarik mengurangi kecepatan pengembangan secara dramatis dan tidak disarankan dalam kasus seperti itu.

• Saat Anda sebagian besar bekerja dengan pengembang senior.
  Jika tim Anda sebagian besar terdiri dari pengembang senior yang telah bekerja dengan satu sama lain untuk jangka waktu yang lebih lama, maka Anda tidak benar-benar memerlukan manajemen mikro permintaan tarik yang disebutkan di atas. Anda memercayai pengembang Anda dan tahu bahwa mereka profesional. Biarkan mereka melakukan pekerjaan mereka dan jangan memperlambat mereka dengan semua birokrasi aliran Git.

Alur Kerja Pengembangan Berbasis Batang

Dalam model pengembangan berbasis trunk, semua pengembang bekerja pada satu cabang dengan akses terbuka ke sana. Seringkali itu hanya cabang master . Mereka melakukan kode untuk itu dan menjalankannya. Ini sangat sederhana.

Dalam beberapa kasus, mereka membuat cabang fitur berumur pendek. Setelah kode di cabang mereka dikompilasi dan lulus semua tes, mereka langsung menggabungkannya ke master . Ini memastikan bahwa pengembangan benar-benar berkelanjutan dan mencegah pengembang membuat konflik gabungan yang sulit diselesaikan.

Mari kita lihat alur kerja pengembangan berbasis trunk.

Satu-satunya cara untuk meninjau kode dalam pendekatan seperti itu adalah dengan melakukan tinjauan kode sumber secara lengkap. Biasanya, diskusi panjang terbatas. Tidak ada yang memiliki kontrol ketat atas apa yang sedang dimodifikasi di basis kode sumber—itulah mengapa penting untuk memiliki gaya kode yang dapat diterapkan. Pengembang yang bekerja dengan gaya seperti itu harus berpengalaman sehingga Anda tahu bahwa mereka tidak akan menurunkan kualitas kode sumber.

Gaya kerja ini bisa menjadi hebat ketika Anda bekerja dengan tim pengembang perangkat lunak berpengalaman. Ini memungkinkan mereka untuk memperkenalkan perbaikan baru dengan cepat dan tanpa birokrasi yang tidak perlu. Ini juga menunjukkan kepada mereka bahwa Anda memercayai mereka, karena mereka dapat memperkenalkan kode langsung ke cabang master . Pengembang dalam alur kerja ini sangat otonom—mereka mengirimkan secara langsung dan memeriksa hasil akhir dalam produk yang berfungsi. Jelas ada lebih sedikit manajemen mikro dan kemungkinan politik kantor dalam metode ini.

Sebaliknya, jika Anda tidak memiliki tim yang berpengalaman atau Anda tidak mempercayai mereka karena alasan tertentu, Anda sebaiknya tidak menggunakan metode ini—Anda harus memilih aliran Git sebagai gantinya. Ini akan menyelamatkan Anda dari kekhawatiran yang tidak perlu.

Pro dan Kontra Pengembangan Berbasis Batang

Mari kita lihat lebih dekat kedua sisi biaya—skenario terbaik dan terburuk.

Kapan Pengembangan Berbasis Batang Bekerja Terbaik?

• Ketika Anda baru memulai.
  Jika Anda sedang mengerjakan produk minimum yang layak, maka gaya ini sangat cocok untuk Anda. Ini menawarkan kecepatan pengembangan maksimum dengan formalitas minimum. Karena tidak ada permintaan tarik, pengembang dapat memberikan fungsionalitas baru dengan sangat cepat. Pastikan untuk mempekerjakan programmer berpengalaman.

• Saat Anda perlu mengulang dengan cepat.
  Setelah Anda mencapai versi pertama produk Anda dan Anda melihat bahwa pelanggan Anda menginginkan sesuatu yang berbeda, maka jangan berpikir dua kali dan gunakan gaya ini untuk berputar ke arah yang baru. Anda masih dalam tahap eksplorasi dan Anda harus dapat mengubah produk Anda secepat mungkin.

• Saat Anda sebagian besar bekerja dengan pengembang senior.
  Jika tim Anda sebagian besar terdiri dari pengembang senior, maka Anda harus memercayai mereka dan membiarkan mereka melakukan pekerjaan mereka. Alur kerja ini memberi mereka otonomi yang mereka butuhkan dan memungkinkan mereka untuk menggunakan penguasaan profesi mereka. Beri mereka tujuan (tugas yang harus diselesaikan) dan perhatikan bagaimana produk Anda tumbuh.

Kapan Pengembangan Berbasis Batang Dapat Menimbulkan Masalah?

• Saat Anda menjalankan proyek sumber terbuka.
  Jika Anda menjalankan proyek sumber terbuka, maka aliran Git adalah pilihan yang lebih baik. Anda memerlukan kontrol yang sangat ketat atas perubahan dan Anda tidak dapat mempercayai kontributor. Lagi pula, siapa pun dapat berkontribusi. Termasuk troll online.

• Ketika Anda memiliki banyak pengembang junior.
  Jika Anda mempekerjakan sebagian besar pengembang junior, maka lebih baik untuk mengontrol dengan ketat apa yang mereka lakukan. Permintaan tarik yang ketat akan membantu mereka untuk meningkatkan keterampilan mereka dan akan menemukan bug potensial lebih cepat.

• Ketika Anda telah menetapkan produk atau mengelola tim besar.
  Jika Anda sudah memiliki produk yang sukses atau mengelola tim besar di perusahaan besar, maka aliran Git mungkin merupakan ide yang lebih baik. Anda ingin memiliki kontrol ketat atas apa yang terjadi dengan produk mapan senilai jutaan dolar. Mungkin, kinerja aplikasi dan kemampuan memuat adalah hal yang paling penting. Pengoptimalan semacam itu membutuhkan perubahan yang sangat tepat.

Gunakan Alat yang Tepat untuk Pekerjaan yang Tepat

Seperti yang saya katakan sebelumnya, Git hanyalah sebuah alat. Seperti setiap alat lainnya, itu perlu digunakan dengan tepat.

Aliran Git mengelola semua perubahan melalui permintaan tarik. Ini memberikan kontrol akses yang ketat untuk semua perubahan. Ini bagus untuk proyek sumber terbuka, perusahaan besar, perusahaan dengan produk mapan, atau tim pengembang junior yang tidak berpengalaman. Anda dapat dengan aman memeriksa apa yang dimasukkan ke dalam kode sumber. Di sisi lain, ini mungkin mengarah pada manajemen mikro yang luas, perselisihan yang melibatkan politik kantor, dan perkembangan yang jauh lebih lambat.

Pengembangan berbasis trunk memberi programmer otonomi penuh dan mengekspresikan lebih banyak kepercayaan pada mereka dan penilaian mereka. Akses ke kode sumber gratis, jadi Anda benar-benar harus bisa memercayai tim Anda. Ini memberikan kecepatan pengembangan perangkat lunak yang sangat baik dan mengurangi proses. Faktor-faktor ini membuatnya sempurna saat membuat produk baru atau memutar aplikasi yang sudah ada ke arah yang benar-benar baru. Ini bekerja sangat baik jika Anda bekerja sebagian besar dengan pengembang berpengalaman.

Namun, jika Anda bekerja dengan programmer junior atau orang yang tidak sepenuhnya Anda percayai, aliran Git adalah alternatif yang jauh lebih baik.

Berbekal pengetahuan ini, saya harap Anda dapat memilih alur kerja yang sesuai dengan proyek Anda.