Kontrol Sumber: Peran dan Tanggung Jawab - Praktik Terbaik

Saya mencari "Praktik Terbaik" mengenai peran dan tanggung jawab, khususnya yang bertanggung jawab untuk penggabungan dari cabang pembangunan ke batang (atau utama). Pada dasarnya saya mencari amunisi untuk membantu tujuan saya.

Biarkan saya menggambarkan apa yang saya hadapi. Saya adalah pengembang utama (pemilik) aplikasi tertentu. Perusahaan kami baru-baru ini pindah dari VSS (di mana saya adalah administrator dari database VSS di mana aplikasi saya disimpan) ke TFS (di mana saya hanya memiliki izin pada cabang pengembangan yang dibuat oleh tim "operasi" kami). Dalam pekerjaan sebelumnya, saya adalah seorang Admin TFS, jadi saya tahu jalan saya di TFS dan MSBuild.

Saya tidak memiliki masalah dengan strategi percabangan dan penggabungan yang digunakan (cabang utama, dengan cabang pengembangan bug / proyek dibuat sesuai kebutuhan, digabungkan kembali ke utama kemudian dipromosikan ke cabang pelepas). Masalah yang saya miliki adalah:

1. Saya tidak bisa membuat cabang sendiri. Saya harus membuat tugas TFS agar anggota tim "operasi" membuat cabang untuk saya.

2. Saya tidak dapat menggabungkan dari Main ke cabang pengembangan saya. Saya harus membuat tugas TFS untuk meminta anggota tim "operasi" melakukan penggabungan, dan kemudian berharap dia tidak "menginjak" perubahan tim saya karena "ops guy" mungkin atau mungkin bukan pengembang dan tentunya memiliki sedikit atau tidak ada pengetahuan tentang kode yang dia gabungkan.

3. Saya tidak dapat menggabungkan dari pengembangan ke Utama. Sekali lagi saya harus membuat tugas TFS untuk memiliki "ops guy" melakukan penggabungan, berharap dia melakukannya dengan benar. Kemudian saya harus membuat tugas TFS lain untuk bergabung kembali ke cabang saya sehingga saya bisa menyelesaikan masalah apa pun yang terjadi dengan memiliki penggabungan non-pengembang ke Main.

4. Saya tidak bisa membuat atau mengedit skrip MSBuild. Sekali lagi saya harus bekerja dengan tim "ops" yang baru untuk MSBuild sehingga hanya tugas membangun paling dasar yang dapat dilakukan. (Lupakan segala hal yang rumit, atau surga-melarang tugas khusus).

5. Saya tidak bisa menjalankan skrip MSBuild. Sekali lagi hanya tim "ops" yang dapat melakukan ini.

6. Untuk melengkapi semua ini, biasanya ini adalah sumber daya "lepas pantai" yang melakukan tugas yang diminta, jadi bahkan jika saya membuat tugas untuk (cabang / gabung / bangun) di pagi hari, itu mungkin tidak akan selesai sampai malam itu.

Sekarang saya tidak punya masalah dengan tim "operasi" mempertahankan cabang rilis. Karena yang mereka lakukan adalah (pada dasarnya) mengambil versi terbaru dari Main dan mempromosikannya ke cabang rilis; jadi selama "Main" stabil dan siap, cabang rilis akan baik.

Pendapat saya adalah bahwa arahan teknis (seperti saya) harus bertanggung jawab untuk memelihara trunk ("Utama") dan penggabungan ke / dari cabang pengembangan. Pemimpin tim juga harus memiliki kemampuan untuk menghasilkan skrip MS Build untuk membangun dan menyebarkan ke lingkungan pengujian Integrasi.

Adakah yang bisa mengarahkan saya ke dokumen Praktik Terbaik yang akan membantu saya membuktikan kasus saya? Semua pencarian saya hanya menemukan Praktik Terbaik tentang teknik percabangan dan penggabungan, dan tidak ada yang menyebutkan WHO harus melakukan percabangan / penggabungan tersebut.

Pandangan umum saya tentang praktik terbaik adalah bahwa setiap anggota tim pengembangan harus dapat melakukan tindakan apa pun di pohon dengan anggapan tindakan tersebut tidak melakukan hal-hal seperti memulai penyebaran produksi. Dalam kasus di mana cabang / tag / repositori tertentu memang bertindak sebagai sumber untuk penyebaran otomatis yang memasukkan beberapa kontrol perubahan yang masuk akal atau hambatan untuk masuk masuk akal, lebih dari menjaga kesalahan hanya kesalahan perspektif daripada beberapa sudut kontrol-aneh. Saya akan mendorong pengembang untuk membuat cabang dan meningkatkan skrip build. Saya akan menemukan cara untuk mendapatkan akses pengembang ke produksi jika diperlukan. Bagian dari titik kontrol sumber adalah itu adalah penghapus kesalahan efektif sihir - yang terburuk yang perlu Anda lakukan adalah memutar mundur satu atau dua dan bercabang itu.

Sayangnya ini tidak terdengar seperti pendekatan yang mereka ambil di sini. Untuk mengalahkan ini saya pikir Anda perlu membahas beberapa sudut:

a) Buktikan bahwa kebijakan-kebijakan ini merugikan perkembangan sesuatu. Catat semua waktu yang Anda habiskan untuk menunggu ops untuk mengerjakan sesuatu. Ini saja harus menjual manajemen yang masuk akal tentang mengapa ini adalah kebijakan yang buruk.

b) Mencari teman di Ops - mungkin ada alasan untuk kebijakan ini. Mungkin alasan itu dapat diatasi dengan cara yang lebih efektif.

Semoga ini membantu.

Praktik yang saya lihat adalah:

1. Siapa saja dapat membuat cabang kerja sesuka hatinya. Pengembang harus dapat membuat cabang fitur di detik mereka menemukan ada gunanya menyimpan pekerjaan mereka saat ini dalam proses. Karena mereka ingin / harus mendukungnya di akhir hari, ingin membagikannya dengan anggota tim lain, perlu dilindungi dari perubahan pada main atau apa pun.

2. Siapa saja dapat melakukan apa saja untuk pengembangan cabang. Pengembang harus dapat menggabungkan dari main begitu pengembang lain memberi tahu mereka sesuatu yang mereka butuhkan telah terintegrasi di main.

3. Untuk menggabungkan ke utama (integrasi), ada tiga opsi:

   • Pengembang melakukan ini sendiri. Mereka hanya mendiskusikan risiko dengan pengembang utama dan menguji fitur-fiturnya dengan tepat. Itu menyiratkan siapa pun yang memiliki izin; jika seseorang melanggar aturan, mereka hanya dimarahi dan perubahan yang salah dikembalikan.
   • Pengembang lain melakukannya setelah meninjau perubahan. Itu masih mengharuskan setiap orang memiliki izin untuk melakukannya; aturan masih ditegakkan oleh pengembang utama.
   • Ada integrator yang ditunjuk yang meninjau dan menggabungkan ke utama. Tetapi integrator adalah bagian dari tim dan perlu memahami kode. Pada tim yang lebih kecil itu akan menjadi orang yang sama dengan arsitek, pada yang lebih besar mereka akan terpisah, tetapi perlu bekerja sama secara erat.

4. Siapa pun yang menyiapkan fitur harus mengadaptasi skrip build. Tapi saya tidak yakin cara kerjanya dengan TFS; dalam sistem saya menggunakan skrip build selalu hanya file berversi, jadi pengembang mengeditnya seperti yang lain dan itu terintegrasi bersama dengan yang lainnya.

5. Jika ada integrator yang ditunjuk, mereka biasanya mengurus mendefinisikan (skrip mana yang harus dijalankan) dan mulai membangun. Kalau tidak, ketua tim yang melakukannya, anggota tim yang ditunjuk melakukannya atau siapa pun memiliki izin dan delegasi pemimpin tim mendirikan dan memulai pembangunan khusus berdasarkan kasus per kasus.

6. Dalam keadaan apa pun operasi di atas tidak memerlukan operator di luar tim. Operator hanya diperlukan untuk mengatur izin, membuat replika dan semacamnya.

Jangan pedulikan "praktik terbaik" (bersabarlah) ini adalah masalah manajemen - pada dasarnya Anda tidak dapat melakukan pekerjaan Anda dengan baik karena kendala yang diberikan kepada Anda.

Sebenarnya tidak masalah apa "praktik terbaik" itu - ini adalah masalah yang sederhana, dapat dibuktikan, yang akan memengaruhi produktivitas Anda dan tim Anda dan Anda harus mengambilnya dengan manajemen lini Anda atas dasar itu.

Saya dapat melihat bahwa mengacungkan dokumen praktik terbaik mungkin (tetapi hanya mungkin ) menjadi bantuan dalam upaya membujuk mereka tetapi jauh lebih baik adalah gagasan bahwa Anda harus meminta anggota tim dev duduk di tangan mereka sambil menunggu seseorang di zona waktu yang berbeda untuk menyatukan tindakan mereka kecuali jika prosesnya diperbaiki / dirasionalisasi.

Dan jangan terlalu konfrontatif - sebanyak apa pun yang Anda ingin tahu mengapa pembatasan itu ada, apa pembenarannya ...