Kontrol Sumber: Peran dan Tanggung Jawab - Praktik Terbaik


10

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.


WHO should be performing said branching/merging.adalah keputusan organisasi internal. Bukan sesuatu yang bisa kami bantu ...
yannis

2
Ingin memberi tahu kami alasan diduga yang diberikan untuk prosedur Bizantium seperti itu? Dugaan saya adalah "Kepatuhan Level N CMM" atau "Sarbanes Oxley".
Bruce Ediger

SOX, tetapi hanya sebagian. Ketika kami pertama kali pergi ke TFS, pengembang memiliki akses ke Main dan Dev. Tapi kemudian "beberapa" pengembang (tidak ada di tim saya) memutuskan untuk hanya melakukan pekerjaan pengembangan di Main daripada di cabang Dev, jadi sekarang semua tim sedang dihukum.
Michael Chatfield

Jawaban:


8

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.


3
+1, saya mengetik sesuatu yang serupa: mendokumentasikan waktu dan upaya yang hilang: biarkan pembuat keputusan membuat pilihan berdasarkan informasi: apakah risiko apa pun yang mereka coba hindari dengan kebijakan pembatasan saat ini sepadan dengan biayanya?
Jamie F

Saya berencana mengadakan pertemuan seperti itu, tetapi akan membantu jika saya dapat menunjukkan kebijakan ini bertentangan dengan "praktik terbaik" industri.
Michael Chatfield

Kena kau. Tidak yakin apakah ada sesuatu yang spesifik di sana, tetapi bit pada kontrol sumber di The Pragmatic Programmer mungkin memiliki beberapa permata di dalamnya. Dari apa yang terdengar seperti itu adalah reaksi berlebihan terhadap beberapa pengembang yang buruk daripada keputusan kebijakan yang dipikirkan atau politik. Saya akan menyetujui kesepakatan di mana Ops memiliki merger ke Main. Saya juga mendorong untuk membuat ops bertanggung jawab untuk memastikan penggabungan tidak merusak apa pun, yang mungkin akan berakhir dengan mereka keluar dari itu. . .
Wyatt Barnett

Aku Jamie kedua, semua waktu yang dihabiskan untuk bergabung atau menunggu penggabungan terjadi harus dicatat sehingga Anda memiliki bukti. Tidak ada "praktik terbaik" yang cocok untuk semua perusahaan. Saya telah bekerja di perusahaan besar di mana tugas ini dilakukan oleh tim manajemen konfigurasi khusus. Saya perusahaan saya saat ini ada tim manajemen rilis khusus yang tidak melakukan pekerjaan fisik penggabungan ke utama tetapi mereka adalah pemilik logis dan melakukan audit. Tapi ops IMHO biasanya bukan yang menyentuh kode sumber.
softveda

2

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.


Saya akan menjadi "integrator yang ditunjuk", asalkan itu sebenarnya pengembang di tim. Lagipula itulah rute yang saya harapkan; ini adalah tim kecil (4 orang termasuk saya). Mudah-mudahan saya bisa mendapatkan akses untuk membuat / mengeksekusi skrip MS Build juga, itu akan konyol bagi saya untuk membuat skrip nAnt untuk penyebaran pengembangan dan kemudian untuk tim "ops" untuk membangun dasarnya skrip yang sama untuk MSBuild. Tapi, itulah yang akan saya lakukan jika perlu.
Michael Chatfield

2

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 ...


1
Ya, berusaha sangat keras untuk tidak bersikap konfrontatif ... datang dari seorang pria yang istrinya membelikannya sebuah "Saya setuju dengan Anda, tapi kemudian kita berdua akan salah" T-Shirt. :)
Michael Chatfield

Ini adalah pembunuh mutlak ketika Anda benar (-: Dan dalam hal ini sulit untuk menyatakan bahwa Anda tidak ... tetapi Anda memerlukan manajemen lini Anda di sisi jika ada hal yang akan berubah
Murph
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.