Haruskah riwayat komit digunakan untuk menyampaikan informasi penting kepada pengembang?


94

Selama pertemuan mengenai kemunduran SDK pihak ketiga dari versi terbaru, dicatat bahwa pengembang kami telah menandai dalam komit sejarah bahwa versi terbaru tidak boleh digunakan.

Beberapa pengembang berpendapat bahwa ini adalah praktik yang buruk dan seharusnya dicatat dalam file sumber (yaitu // Don't upgrade SDK Version x.y.z, see ticket 1234) atau dalam READMEfile tingkat proyek . Yang lain berpendapat bahwa karena sejarah komit adalah bagian dari dokumentasi proyek, maka itu adalah lokasi yang dapat diterima untuk informasi tersebut karena kita semua harus membacanya.

Haruskah riwayat komit digunakan untuk menyampaikan informasi penting kepada pengembang lain atau haruskah informasi tersebut diduplikasi ke lokasi lain seperti proyek READMEatau komentar dalam file sumber yang relevan?


60
Sepertinya proyek Anda memiliki masalah komunikasi yang cukup serius.
tzerb

82
Apakah Anda memerlukan karyawan baru untuk melewati seluruh riwayat komit?
Steven Evers

3
Karyawan baru tidak boleh melalui basis kode dan mengubah dependensi tanpa arah khusus untuk melakukannya.
Midnotion

28
@ Madnotion Jadi di suatu tempat di jalan dari perekrutan baru ke pengembang utama Anda meluangkan waktu untuk menelusuri seluruh sejarah komit? Menarik.
Nathan Cooper

6
Itu masih tidak membuatnya menjadi ide yang baik untuk memasukkan informasi penting hanya dalam sejarah commit.
17 dari 26

Jawaban:


143

Jika saya akan melihat peningkatan ke versi yang lebih baru dari SDK pihak ketiga, tempat terakhir yang saya lihat adalah dalam sejarah sistem kontrol sumber.

Jika produk Anda menggunakan SDK versi 2.0 dan seseorang tertarik untuk memutakhirkan ke 3.0, saya rasa tidak masuk akal untuk berpikir bahwa mereka harus melihat ke belakang dalam waktu dalam sistem kontrol sumber Anda untuk mengetahui bahwa itu bukan ide yang baik.

Di sini, kami memiliki tim wiki yang memiliki beberapa halaman dengan info menarik yang dibaca setiap pengembang (konvensi pengkodean, cara mengatur lingkungan pengembangan untuk membangun produk, hal-hal pihak ketiga apa yang perlu Anda instal, dll). Ini adalah jenis tempat yang sesuai untuk peringatan terhadap pemutakhiran perpustakaan pihak ketiga.


52
Memang, sejarah komit adalah sejarah proyek. Sama seperti itu akan bodoh untuk memiliki informasi penting dalam sejarah suntingan wiki, dan tidak pada halaman itu sendiri. Riwayat (baik kode atau wiki) adalah untuk referensi tentang apa yang terjadi sebelumnya, bukan pada apa yang seharusnya terjadi sekarang.
Biasa

48
Jika memungkinkan untuk SDK fiksi, saya akan menambahkan unit test yang dirancang khusus untuk lulus di bawah V2 dan gagal di bawah V3 dengan pernyataan tegas yang memberikan alasan untuk tidak meningkatkan ke V3. Komit sejarah adalah tempat yang baik untuk menyatakan mengapa Anda membuat perubahan itu untuk peninjau kode, bukan untuk mendokumentasikan praktik terbaik.
Klors

3
@ Klor Selama Anda tidak membatasi diri pada definisi tes unit yang paling bagus dan menolak untuk melakukan jenis tes otomatis lainnya, tes yang didasarkan pada memeriksa sistem file / dll untuk nama perpustakaan (jika ada versi yang dikodekan). di dalamnya) atau hash / checksum dari file itu sendiri dapat digunakan untuk melempar bendera merah pada siapa pun yang ingin memperbarui perpustakaan bahkan dalam kasus-kasus di mana cacat versi baru sulit / tidak mungkin ditangkap dalam suatu pengujian. (mis., kondisi lomba multi-utas)
Dan Neely

18
@ Klor Saya memikirkan hal yang sama, tetapi menurut pendapat saya, tes unit harus menunjukkan alasan untuk menggunakan v2 lebih dari v3, dengan cara itu jika tes unit lulus dengan v4, Anda tidak memiliki unit test yang memerlukan v2 tanpa alasan.
Matius

9
Alasan lain untuk tidak menggunakan riwayat komit untuk ini: riwayat komit adalah catatan permanen. Jika alasan untuk tidak memutakhirkan hilang, riwayat komit masih akan berisi peringatan untuk tidak memutakhirkan, yang bisa membingungkan. Anda perlu suatu tempat di mana daftar persyaratan seperti ini terus diperbarui, sehingga pengembang tidak perlu memeriksa ulang apakah hal-hal itu masih relevan.
Jules

69

Itu harus dicatat dalam histori komit tetapi tempat terbaik mutlak untuk menempatkan pemberitahuan adalah di tempat yang sama Anda mendefinisikan ketergantungan. Jika Anda memiliki misalnya file .pom maven yang menyatakan dependensi artefak Anda, saya akan melakukan sesuatu seperti:

<!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 -->

Tepat di atas <dependency>garis Anda .

Masalah # 123 akan mencakup rincian tentang bagaimana crash, versi yang Anda perbarui yang menyebabkan crash, dan mungkin kemudian harus ditambahkan ke backlog Anda lagi untuk meninjau kembali nanti - mungkin ada versi yang lebih baru lagi yang memperbaiki masalah. Baik secara otomatis dengan mengedit tiket, atau secara manual sendiri, itu akan mengirim email kepada tim untuk memberi tahu mereka tentang masalah saat ini sekarang, dan dengan berada di pelacak itu memungkinkan orang menemukannya lagi nanti.

Alasan untuk memasukkannya dengan deklarasi dependensi adalah karena siapa pun yang ingin mengubah versi akan melihatnya pada saat mereka ingin mengubahnya dan memahami mengapa mereka tidak boleh.

Saya tidak akan berkomentar dalam kode sumber karena saya dapat dengan mudah menggambarkan situasi di mana seseorang menjalankan pemeriksaan pada dependensi Anda dan mulai memutakhirkannya. Mereka seharusnya tidak perlu menjelajahi basis kode untuk setiap komentar TODO untuk melakukan itu.

Menautkan ke tiket masalah memungkinkan pengembang yang penasaran tahu bagaimana kegagalannya dan berpotensi mengunjungi kembali nanti. Tanpa itu, mungkin menjadi cukup statis dan tidak pernah diperbarui lagi.


11
Saya setuju: lokasi terbaik untuk informasi penting adalah "di tempat sebanyak mungkin." Mungkin pom.xmlfile proyek setara atau, readme, dll. Tetapi komit sejarah masih bagus. Jika saya ingin memutakhirkan pustaka, saya dapat memeriksa riwayat versi yang ada untuk melihat kapan itu diperbarui dan juga catatan tentang masalah yang dialami pengendara. Tetapi saya tidak ingin menggali sejarah untuk mengumpulkan semua dokumentasi. Ini adalah sumber tambahan yang bagus .

35

Potongan informasi yang kritis dan tidak intuitif harus didokumentasikan di mana orang akan mencari ketika mempertimbangkan informasi tersebut.

Untuk tim dan proyek yang saya kerjakan, saya akan melakukan roll-back dengan komentar tentang mengapa versi baru gagal. Saya akan menambahkan cerita backlog untuk mencoba kembali upgrade jika versi baru diperbaiki. Saya akan menambahkan komentar ke sistem build / membangun skrip di mana perpustakaan terhubung.

Roll-back akan memberikan konteks masa depan pengembang ketika melihat ke dalam sejarah proyek. Kisah backlog menjaga perlunya peningkatan ini sebagai bagian aktif dari proyek. Komentar membangun sistem tepat di mana perubahan harus ketika perpustakaan akhirnya diperbarui.

Saya tidak akan berkomentar dalam kode dan saya tidak akan menambahkannya ke README. Pengembang yang berpikir untuk mencoba peningkatan tidak akan melihat potongan-potongan ini. Jika Anda menambahkannya di sana, maka ketika masalah dengan perpustakaan akhirnya diperbaiki dan pemutakhiran selesai, Anda harus menghapusnya. Langkah ini sering dilupakan: menghasilkan catatan yang kontra produktif dengan proyek.


Jika proyek Anda memiliki pengaturan yang berbeda atau alur yang berbeda, maka jawaban Anda mungkin berbeda. Saya pikir kuncinya adalah untuk meluruskan informasi bahwa pengembang akan melihatnya ketika melakukan pekerjaan untuk upgrade. Dengan begitu, jika waktunya tidak tepat untuk peningkatan, pengembang akan melihatnya dan berhenti, dan ketika waktunya tepat pengembang akan melihatnya dan menghapus catatan sehingga tidak akan membingungkan pengembang di masa depan.


7
Ya, komentar perlu ditempatkan "di jalur" perubahan. Jadi secara teknis tidak mungkin melakukan tindakan tanpa melihat peringatan. Ini sangat mirip kontrol keamanan.
dss539

Beri +1 pada saran untuk membuat cerita / tiket untuk peningkatan dalam pelacak masalah Anda, setel ke "Ditunda" dengan penjelasan mengapa itu belum bisa dilakukan. Pelacak masalah adalah satu tempat Anda benar - benar dapat meminta orang untuk melihat sebelum mengerjakan sesuatu.
Andrew Spencer

+1 Mengutip Jeff Attwood (meskipun ia berbicara tentang, ugh, "pengguna"): "Lain kali Anda merancang [X], pertimbangkan miopia [klien]. Anda mungkin akan terkejut betapa rabunnya [klien] Anda. Berpikir panjang dan keras tentang menempatkan benda-benda tepat di depan mereka, di mana mereka tidak hanya terlihat, tetapi tidak dapat dihindari. Kalau tidak, mereka mungkin tidak terlihat sama sekali. " blog.codinghorror.com/treating-user-myopia
heltonbiker

17

Saya ingin memberi komentar Matthew lebih banyak perhatian dengan menyoroti ide pentingnya dalam sebuah jawaban. Ada alasan mengapa Anda tidak ingin memutakhirkan SDK Anda, dan alasan itu harus ditangkap dalam unit test. Bukan cek untuk nomor revisi, tetapi alasan mendasar yang sebenarnya.

Misalnya, ada bug di versi baru. Tulis unit test yang memeriksa bug itu. Jika nanti mereka memperbaiki bug itu di SDK, maka pemutakhiran akan terjadi dengan lancar. Jika ada perubahan API yang tidak kompatibel, tulis tes yang memeriksa apakah kode Anda mendukung API baru atau SDK mendukung API lama. Itu lebih dari tes integrasi daripada tes unit, tetapi harus tetap bisa dilakukan.

Perusahaan saya menghasilkan 50+ komitmen per hari, dan kami tidak terlalu besar. Bahkan jika setiap pengembang membaca setiap pesan komit, yang sejujurnya tidak, seluruh alasan kita memerlukan riwayat komit yang direkam adalah karena orang tidak dapat mengingatnya. Dan orang tidak kembali dan membaca sejarah nanti kecuali ada masalah. Dan mereka tidak memiliki alasan untuk mencurigai masalah pada peningkatan yang sejauh yang mereka tahu belum terjadi.

Dengan segala cara, kirim email untuk mencegah duplikasi pekerjaan dalam waktu dekat, dan catat di skrip build Anda dan README atau errata. Namun, terutama jika masalah dengan versi baru itu halus dan memakan waktu untuk memecahkan masalah, Anda perlu cara untuk membuatnya jelas. Itu berarti unit test.


1
Ini adalah satu jawaban yang benar. Menangkap kegagalan dalam unit test mencegah peningkatan yang buruk terjadi. Titik.
Dirk Bester

15

Saya menyusun ulang pertanyaan sebagai "Haruskah saya mengomunikasikan informasi penting yang saya temukan kepada anggota tim lainnya hanya melalui pesan komit?" Karena saya pikir itu membuat jelas bahwa tidak, Anda tidak boleh. Saya berusaha keras untuk banyak berkomunikasi (ini adalah sesuatu yang oleh sebagian besar tim pengembangan, dalam pengalaman saya, perlu melakukan upaya aktif) dan saya tentu melakukan segala yang saya bisa untuk menghindari membuat jebakan atau membiarkan mereka berbohong.

Jika rantai tindakan yang membawa saya ke penemuan seperti itu dipicu oleh tiket, saya akan memperbarui tiket (dan memastikan orang-orang yang seharusnya tahu ini memiliki visibilitas), saya mungkin akan menyebutkannya secara langsung (berharap untuk setidaknya meninggalkan seseorang dengan perasaan mengomel bahwa "Wah, saya pikir Damon mengatakan sesuatu tentang memperbarui itu"), dan tentu saja saya akan meninggalkan komentar dalam kode pada titik SDK dimasukkan sehingga tidak ada yang bisa memperbarui tanpa memiliki kesempatan untuk melihatnya. Saya mungkin melihat apakah saya bisa memasukkannya ke wiki dev kami juga, meskipun itu dilakukan lebih dengan pandangan ke arah perekrutan masa depan, bukan tim saat ini.

Hanya perlu beberapa menit lebih lama dibandingkan dengan waktu yang dibutuhkan untuk menemukan dan menemukan masalahnya. Saya tentu saja tidak akan memutuskan bahwa salah satu dari potongan-potongan dokumentasi kami yang paling sedikit digunakan, dan membiarkannya.


4
+1 Kata kunci asli hanya . Tentu tidak ada salahnya jika info tersebut disimpan dalam pesan komit di samping tempat lain yang lebih cocok. Itu mengenai OP, karena komit log adalah satu - satunya dokumentasi yang tersedia.
JensG

13

Itu harus dalam sejarah komit tetapi seharusnya tidak hanya dalam sejarah komit, bayangkan sejenak Anda menyewa pengembang baru. Apakah Anda berharap pengembang baru membaca setiap pesan komit selama 10 tahun terakhir dari proyek Anda karena beberapa di antaranya akan sangat penting untuk memahami basis kode Anda?

Kedua, katakan situasinya tetapi bukan perubahan kode, apakah Anda akan membuat komitmen "dokumentasi" sehingga Anda dapat menambahkan pesan komit di sepanjang baris "komit pesan dari revisi 5432 sekarang salah, inilah situasi saat ini."


11

Saya tidak yakin bagaimana tim Anda berkomunikasi tapi saya percaya cara yang paling efektif untuk mengatakan ini adalah untuk pertama mengirim dan email ke grup email tim, ditandai sebagai "URGENT" dengan tubuh mengatakan

Kawan, kita tidak bisa menggunakan SDK v xyz karena hal itu menyebabkan buffer Foo meluap dan layanan Bar akan macet. Tetap dengan versi xyy

Itulah yang kami lakukan di sini dan ini adalah cara paling andal untuk menyampaikan pesan di sana. Jika Anda benar - benar ingin cerewet (dan jika sistem email Anda memungkinkannya), mintalah "tanda terima baca" pada email tersebut.

Setelah Anda memberi tahu seluruh tim, dokumentasi yang lebih detail harus dimasukkan ke dalam wiki tim. Ini akan bervariasi, tergantung pada bagaimana Anda menyusun dokumentasi Anda. Jika Anda memiliki bagian khusus untuk Ketergantungan dan Persyaratan aplikasi Anda, itu akan menjadi tempat yang baik untuk menambahkannya.

Tempat tambahan untuk mendokumentasikan masalah semacam ini mungkin ada dalam kode sumber itu sendiri, meskipun itu mungkin tidak selalu berhasil. Jika SDK version ...hanya direferensikan di satu atau dua tempat yang jelas, Anda dapat menyertakan catatan tentang tidak meningkatkan.

Riwayat file dalam kontrol sumber bisa sangat panjang, dan tergantung pada pengembang, bisa memiliki beberapa entri per hari. Seseorang yang sedang berlibur selama seminggu mungkin tidak punya waktu untuk membaca sejarah komitmen selama seminggu. File README adalah tempat yang lebih baik karena sedikit lebih sentral dan orang mungkin lebih cenderung untuk membacanya, tetapi Anda tidak dapat memastikan bahwa semua orang benar-benar akan membaca README. Yah, saya kira mereka mungkin jika mereka melihat itu telah berubah ...


4
Saya suka ide grup email. Terlalu banyak tempat yang saya kerjakan bergantung pada alamat individual dan hal-hal yang tidak diteruskan ke anggota baru.
JeffO

20
Apa yang terjadi jika seseorang baru datang ke tim Anda? Siapa yang bertanggung jawab untuk memberi mereka pengetahuan pseudo-institusional semacam ini?
ABMagil

3
@ABMagil: Informasi masuk ke wiki. Pengembang yang baru mengenal tim biasanya mulai dari sana, di beberapa halaman pengantar. Kemudian mereka mendatangi individu-individu tertentu (yang telah menyediakan waktu untuk membantu para dev baru) ketika mereka memiliki pertanyaan spesifik (dan mereka selalu melakukannya). Bagi kami, itu mungkin akan berakhir di "Panduan Pengaturan Pengembang untuk ApplicationX" karena NOTE: Do not use SDK vers. x.y.z because...tetapi komunikasi awal harus berupa email.
FrustratedWithFormsDesigner

16
-1 email tidak berfungsi dengan baik sebagai dokumentasi
BlueRaja - Danny Pflughoeft

6
@ BlueRaja-DannyPflughoeft: Email menyediakan metode yang sederhana dan mudah digunakan untuk membuat semua orang di tim segera mengetahui bahwa masalah telah ditemukan dalam menggunakan versi tertentu dari perpustakaan tertentu dan bahwa versi ini tidak boleh digunakan. Seperti yang disebutkan, dokumentasi jangka panjang paling baik dilakukan di wiki tim atau semacam basis pengetahuan lainnya.
FrustratedWithFormsDesigner

5

Sesuatu seperti ini seharusnya dimasukkan dalam komentar komit, tetapi itu akan mendapat manfaat dari berada di tempat lain juga.

Siapa pun yang membuat keputusan untuk meningkatkan, perlu memiliki fakta. Orang itu mungkin tidak hidup dalam kendali sumber. Bagaimana jika seseorang akan membaca tentang masalah ini pada SO dan tidak pernah memasukkannya ke dalam basis kode?

Perlu ada semacam dokumen tentang SDK pihak ketiga ini.

  • Masalah apa yang dipecahkannya?
  • Mengapa yang satu ini dipilih?
  • Pertimbangan apa yang perlu dibuat sejauh: versi, peningkatan, pengujian, dll.
  • Siapa yang membuat keputusan ini?

Anda memiliki kasus di mana sesuatu seperti ini masuk ke kontrol versi, dan Anda harus merekomendasikan semua orang menggunakan informasi ini sebanyak mungkin. Hanya tim Anda yang dapat memutuskan di mana seseorang akan melakukan pencarian dalam dokumentasi, kontrol sumber, atau pelacak bug apa pun untuk mendapatkan informasi sebanyak mungkin mengenai subjek tersebut. Kalau tidak, Anda akan lupa, bagaimanapun juga, seseorang akan melakukannya, dan Anda akan beruntung jika itu menghafal ingatan seseorang dan dengan cepat mengembalikannya.


2

Sejarah adalah tempat yang tepat untuk menaruh data yang ditujukan bagi pembaca yang secara sadar mencarinya, dan memiliki pengertian umum tentang di mana seharusnya. Ini adalah tempat yang sangat buruk untuk menaruh data yang harus disodorkan kepada pengguna, daripada dicari.

Sejarah adalah badan yang sangat besar dari teks yang relatif tidak disortir. Mereka biasanya dimaksudkan untuk menyediakan pengembang dengan informasi terperinci tentang apa yang diubah, dan mengapa itu diubah. Ini bisa menjadi informasi yang berlebihan kecuali ada yang tahu apa yang mereka cari.

Jika pengguna tidak tahu apa yang mereka cari, maka informasi tersebut dengan cepat dikubur di bawah ratusan log komit, dan mereka tidak memiliki alat untuk memangkas tumpukan informasi di depan mereka.


ini lebih mirip komentar daripada jawaban. Lihat: Bagaimana Menjawab
nyamuk

Poin bagus, saya mengembangkannya. Semoga ini memenuhi kriteria StackExchange lebih baik.
Cort Ammon

Saya pikir jawaban ini paling baik membahas topik pertanyaan. Commit history baik untuk menyimpan info jika seseorang tahu mereka harus mencari catatan. Jika tidak ada alasan untuk memeriksa 'kesalahan' untuk baris yang diberikan, seperti dimasukkannya SDK, maka dokumentasi itu tidak akan dibaca.
Seth Battin

1

Saya menafsirkan situasi ini sebagai memiliki dua masalah dasar, mungkin tiga.

  • Pemutakhiran SDK yang tidak diinginkan membuatnya menjadi sumber, di mana hal itu dapat berdampak negatif pada produk.
  • Dari pertanyaan: kontributor yang melakukan peningkatan yang tidak diinginkan tidak tahu tentang keputusan sebelumnya yang spesifik untuk tidak meningkatkan.

Yang pertama, menurut saya, adalah yang paling serius. Jika pemutakhiran SDK yang tidak diinginkan dapat membuatnya menjadi kode, demikian juga masalah lainnya.

Seseorang menyarankan menambahkan case test unit yang akan gagal jika mendeteksi upgrade. Sementara itu akan mencegah upgrade terjadi, saya percaya ini adalah jalur berbahaya, yang mengarah ke aliran lava dari waktu ke waktu. Tampaknya tak terhindarkan bahwa di beberapa titik di masa depan SDK akan ditingkatkan, untuk menghadirkan fitur baru atau perbaikan bug, atau karena versi lama tidak lagi didukung. Bayangkan head-scratching, bahkan mungkin argumen, yang akan terjadi ketika unit test seperti itu gagal.

Saya pikir solusi paling umum adalah menyesuaikan proses pengembangan. Untuk git, gunakan proses tarik permintaan . Untuk Subversion dan alat yang lebih lama, gunakan cabang dan diff. Tetapi memiliki beberapa proses yang memungkinkan pengembang senior untuk menangkap masalah semacam ini sebelum mereka membuatnya menjadi basis kode dan mempengaruhi pengembang lain.

Jika proses permintaan tarikan telah digunakan dalam situasi Anda, dan jika setiap permintaan tarikan sempit dan spesifik, tidak banyak waktu akan terbuang sia-sia. Permintaan tarikan untuk memutakhirkan SDK akan diajukan, dan ditolak dengan komentar bahwa pemutakhiran tidak diinginkan. Tidak ada orang lain yang akan terkena dampak, dan sekarang tidak perlu mengembalikan upgrade SDK.

Tetapi untuk langsung menjawab pertanyaan awal, saya setuju dengan yang lain yang mengharapkan semua pengembang untuk sepenuhnya membaca seluruh sejarah revisi kode, catatan rilis, dll untuk pemberitahuan seperti ini adalah buang-buang waktu yang berharga. Ada apa dengan email tim pendek?

Kemungkinan masalah ketiga: Mengapa pembaruan tidak diinginkan sejak awal? Jelas setidaknya satu pengembang mengira peningkatan akan menjadi hal yang baik. Ada banyak alasan bagus untuk menunda upgrade, tetapi juga banyak alasan buruk. Berhati-hatilah untuk menghindari aliran lahar (kode kompatibilitas ke belakang yang tidak perlu) dan kultus kargo ("kami tidak dapat memutakhirkannya, tetapi saya tidak tahu mengapa") anti-pola!


Sementara peningkatan SDK, yang merupakan nomor versi minor sebagai lawan utama, adalah apa yang akhirnya mengarah ke pertanyaan ini, garis penalaran ini telah bermunculan di grup untuk sementara waktu sekarang.
rjzii

Mengapa permintaan tarik ditolak? Bagaimana orang yang bertanggung jawab atas keputusan itu seharusnya menemukan (atau mengingat) batasan versi?
Ben Voigt

@ BenVoigt Nah, pimpinan tim tahu tentang pembatasan, atau tidak ada yang mengingatnya dan ini ditemukan kembali setelah menemui masalah. Either way, menggunakan permintaan tarik, tidak ada menyalahkan pengembang mempekerjakan rendah baru, karena para senior akan menyetujui perubahan sebelum diizinkan masuk.
wberry

@wberry: Atau pengembang senior yang berbeda memproses permintaan tarikan dari orang yang tahu tentang pembatasan versi. Kecuali jika semua permintaan tarik harus disetujui oleh semua pengembang, yang tampaknya seperti pengeluaran sumber daya yang meragukan.
Ben Voigt

0

Saya akan mengatakan menambahkan bahwa jenis informasi ke riwayat komit ok tetapi masih perlu didokumentasikan dengan baik. Kami baru-baru ini mulai menggunakan pertemuan (oleh atlassian). Ini dapat dicari, Anda dapat mengatur halaman tertentu sebagai favorit, dll.

Beberapa alat lain mungkin berupa buku catatan umum di evernote atau google docs.


0

Memperluas jawaban Karl , saya akan pergi dengan pendekatan yang secara otomatis memberlakukan pembatasan sebagai bagian dari proses checkin itu sendiri. Anda memerlukan sesuatu yang tidak memerlukan tindakan proaktif atas nama pengembang, seperti membaca dokumen / wiki / README, dan tidak dapat ditimpa secara terselubung.

Di tanah kendali sumber TFS Anda dapat membuat kode kebijakan checkin khusus yang menjalankan aturan pada checkin. Misalnya, Anda bisa menetapkan kebijakan yang mengevaluasi versi dalam file konfigurasi dengan checkin yang tertunda dan akan gagal jika tidak sama dengan xyz Aturan ini sebenarnya mencegah pengembang melakukan checkin dan dapat memberikan pesan deskriptif. Kebijakan dapat ditimpa, tetapi dimungkinkan untuk menghasilkan peringatan ketika ini terjadi.

Alternatif dapat dibuat-checkin yang gagal akan dengan beberapa bentuk unit test yang baik secara langsung atau tidak langsung mengevaluasi versi SDK, seperti yang disebutkan Karl.

Saya menghargai jawaban ini sangat TFS-sentris, tetapi mungkin fitur serupa ada di sistem kontrol versi / CI yang berlaku dalam situasi Anda (jika tidak TFS).

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.