Bugün, çalışma arkadaşımdan biri ve ben "Teknik özellikler belgelerini SVN gibi kaynak kontrol sistemine koymalı mıyız?" Bence öyle olmalı. Gelişmekte olan proje ile ilgili her şey kaynak kontrol sistemi ile dikkatlice kontrol edilmelidir. Yazılım geliştirme sürecinde yanlış bir kavram mı?
Yanıtlar:
Peki ya çoğu kaynak kontrol sistemi sadece blob olarak depolarsa? Çoğu kişi dokümanlar arasındaki farklar hakkında bir rip vermez, ancak yaparsanız, her zaman iki sürüm alabilir ve bunları dağıtmak için geliştirme sisteminin özelliğini kullanabilirsiniz.
Ayda bir gigabayt başına peni sabit disk alanıyla, kaynak kontrol sistemine belge koymamak için iyi bir neden yoktur ve muhtemelen yararlı olacaktır. Kişisel tercihim satır içi işaretleme kullanarak belge yazmak, örneğin Wiki İşaretleme veya DocBook . Bu, belge karşılaştırma ve revizyon için güçlü araçların kullanılmasına izin verir.
Spesifikasyon belgelerinin versiyonlanması kesinlikle değerli bir hedeftir.
Ancak, teknik özellik belgeleriniz yalnızca metin mi ve düz metin dosyasında mı? Eğer öyleyse, bu iyi bir çözüm olabilir.
Değilse, kaynak denetimi muhtemelen onlar için doğru yer değildir - kaynak denetimi ikili dosyalar için kötüdür .
Düz metin dosyaları genellikle biçimlendirme veya hızlı görüntüleme için iyi değildir, bu nedenle sürümlendirme içeren bir wiki muhtemelen daha iyi bir fikirdir.
Tüm belgeler bir çeşit arşiv biçiminde olmalıdır (tercihen revizyon kontrolleri ile).
Kaynak kontrol sistemleri bir çözümdür. Ancak genellikle bu sistemler düz metin belgeler için tasarlanmıştır. Bu nedenle, Word veya RTF belgeleri gibi şeyler çok iyi uymuyor (özellikle farklı sürümü denediğinizde ve karşılaştırdığınızda).
Ancak , belgeler için özel olarak tasarlanmış başka çözümler de vardır. SharePoint akla geliyor, ama eminim başkaları da var.
Kesinlikle. Belgelerin ikili olarak depolanması sorunu (örneğin, kelime belgeleri) sinir bozucu. Tortoise araçlarından birini (SVN ve Mercurial'ı denedim) kullanırsanız, docdiff'i seçmenize izin veren "Visual Diff" i seçebilirsiniz. Docdiff ile renk ve malzeme ile tüm değişiklikleri görmek olsun :-). Ana dezavantaj, her değişiklik yaptığınızda belgenin tamamının yeniden işlenmesi (sadece değişiklik değil). Ancak metin belgelerinin normalde çok büyük olmadığı ve bu alanın muhtemelen ana sorununuz olmadığı göz önüne alındığında, bu sorun değil.
Tortoise olmadan docdiff kullanabileceğinizden eminim, sadece denemedim.
Tartışmanız gereken alternatif bir yaklaşım var: BDD
Lütfen yürütülebilir özelliklerle Davranış Odaklı Geliştirme'yi göz önünde bulundurun. Spesifikasyonlarınız, metin dosyalarında depolanan bir dizi Verilen - Ne Zaman - Sonra ifadelerine basitleştirilir. Salatalık veya SpecFlow gibi bir BDD aracı, bu metin dosyalarını oluşturma aracınızın yürütebileceği yürütülebilir testlere dönüştürür.
Salatalık: http://cukes.info/ - Ruby için BDD
SpecFlow: http://www.specflow.org/ - .Net için BDD
SpecFlow gibi bir araçla iş akışının hızlı bir demosunu görmek için Rob Conery's SpecFlow uygulamasına göz atın: http://tekpub.com/view/concepts/5
Şimdi, yalnızca kodunuzu değil, spesifikasyonlarınızı ve Sürekli Entegrasyon aracınızın (TeamCity, CruiseControl, Hudson, vb.) Tüm sürümlerin hala HER yapıda geçerli olmasını zorunlu kılıyor ... Bu sizin için değerli mi?