Team Foundation Server'a geçiş nasıl değerlendirilir

Geliştirme ekibim şu anda iş akışımızda şu yazılımı kullanıyor:

• JIRA
• Bambu (Atlassian sürekli entegrasyonu)
• Greenhopper (Atlassian çevik proje yönetimi)
• izdiham
• Git, BitBucket'te barındırılıyor
• Visual Studio 2012

Gördüğünüz gibi, Atlassian ekosistemine oldukça yoğun yatırım yapıyoruz. Kod incelemeleri ve daha da önemlisi Microsoft Test Yöneticisi gibi gelişmiş Visual Studio entegrasyonlarının özelliklerini alabilmemiz için TFS'ye geçmeyi düşünüyoruz.

TFS ile önceki deneyimim 2005 veya 2008 (hatırlayamıyorum) ile oldu ve ClearCase'deki zamanım kadar kötü olmasa da, kötü anılarım var.

TFS'ye geçişimizi doğru bir şekilde değerlendirmek için hangi kriterlere bakmalıyız?

Martin Fowler'in küçük araştırması , önceki yıllarda TFS'nin durumu hakkında çok şey söylüyor. 'tehlikeli' oldukça doğru. (Bence bu, VS dışında yapılan değişiklikleri tanımadığı anlamına gelir, böylece bir WCF projesi oluşturabilir, ardından müşterinizi oluşturmak için harici svcutil aracını kullanabilirsiniz, sonra tüm değişikliklerinizi kontrol edebilirsiniz .. ancak TFS VS içinde yapılmadığı için müşteri değişikliklerinizi göz ardı edin).

Maliyeti saymanız gerekir: güzellikleri elde etmek için gerekli VS sürümü - kod incelemeleri, örneğin, MSDN üzerinden VS alırsanız önemli ölçüde daha pahalı olan Premium sürümü gerektirir . Ayrıca, VS olmayan kullanıcılar için sisteme erişmek iyidir, ancak kısmi web görünümü yerine tam erişim istiyorlarsa, onlar için CAL'leri kabuklandırmanız gerekir. TFS'nin toplam maliyeti oldukça fazla olabilir. Son Forrester raporu bile(Microsoft tarafından görevlendirildi, bu yüzden satırlar arasında biraz okumak zorundasınız) TFS'nin önemli yönetim desteği gerektirdiğini söylüyor - 122 müşterinin vaka çalışması için TFS'yi desteklemek için 2 danışman ve 6 yöneticinin (zamanlarının% 25'ini harcayan) (bu 122 kullanıcı üzerinde 4.5 yöneticiye çalışır ... bu sadece benim günlük işimi yaparken tam bir SVN çözümü kurmak ve korumakla karşılaştırıldığında çok fazla). TFS, insanların beklediği gibi çalışmaya devam etmek için çok çaba harcayabilir.

TFS2012 ile olan tecrübelerime göre (önceki sürümleri bok gibi unutun), özellikle önceden tanımlanmış kurulumun dışına çıktığınızda çok karmaşık bir sistem yönetimi. Örneğin, her şeyi oluşturmak için MSBuild kullanıyorsanız, sorun yok. Ancak, MSBuild tarafından artık desteklenmeyen bir sürü eski .vdproj projeniz varsa, bu projeleri oluşturmak için büyük xaml oluşturma komut dosyasını düzenlemeniz gerekir. Bunun üzerinde çalıştıktan birkaç gün sonra, yapabileceğim en iyi şey, çözümü devenv'e geçirerek yeniden oluşturmaktı ve o zaman bile, yapı sonuçlarını dışarı ve yapı özetine almak imkansızdı. Testleri için NUnit kullanan diğer ekipler tarafından benzer sonuçlar elde edildi - eğer yerleşik MSTest kullanıyorsanız, o zaman işe yarar. Aksi takdirde, doldurulmuş olursunuz.

Bir kullanıcı olarak, entegrasyonun daha fazla sıkıntı olduğunu görüyorum. TortoiseSVN'yi tercih ediyorum ve neredeyse tüm SCM işimi bu şekilde yapıyorum (harika bir araç olduğu için). TFS ile her işlem için VS içinde yeni bir ekran elde edersiniz. Böylece, ortamınızda ekip gezgini için yeni bir sekme ve derlemeler için başka bir sekme ve görmek istediğiniz her derleme özeti için başka bir sekme var (ve bir derlemenin ayrıntılarını görmek istiyorsanız, örneğin bir hata var tıklamak için). TFS kullanırken açık olduğum belgelerin sayısının kaynak dosyalardan daha fazla olduğunu buldum!

Aynı durum, bir iş öğesi atamak ve check-in'lerinize yorum yapmak için VS'deki Bekleyen Değişiklikler bölmesindeki birkaç sekmeyi tıklatarak gerekli değişiklikleri gerçekleştirerek check-in'ler için de geçerlidir. Bu küçük bir şey, ama daha akıcı araçlara alışkın olduğum için sinir bozucu buldum.

Yapı sistemini genişletmek, eksik bulduğum başka bir alan oldu. Yapıya yeni özellikler eklemek xaml yapılandırması nedeniyle zordur ve bu özelliklerin sonuçlarını oluşturma ekranlarınıza almak çok zor veya imkansızdır. Yani kod karmaşıklığı veya statik analiz gibi şeyler eklemek, hatta selenyum veya dağıtımlar yoluyla otomatik test yapmak isterseniz ... unutun. Bu yönler için Microsoft araçlarını kullanmıyorsanız (örn. Fxcop).

İş akışını güncellemek başka bir hareketsizlikti - powertoys muazzam bir şekilde yardımcı olmasına rağmen, iş akışını doğru bir şekilde elde etmek hala garipti ve yine de scrum panosunu gerçekten görmek istediğiniz bilgilerle yapılandıramazsınız - yine, varsayılanları alırsınız veya hiçbir şey almazsınız .

Birleştirme de acı vericiydi, MS'in TFS için git'i benimsemesinin çok iyi bir nedeni olduğunu düşünüyorum (bunun sadece yeni TFS projeleriyle çalıştığını unutmayın, TFS'den git arka uçlarına dönüşemezsiniz).

Sonuçta, işe yaradığı kadar kötü değil, ama diğer birçok aracın çok daha iyi olduğunu gördüm. Bu araçların dezavantajı, tamamen entegre olmamalarıdır, ancak IMHO, istediğiniz en iyi bitleri seçip seçebileceğiniz için bir güçtür. TFS ile bir başkasının sahip olmasını istediklerinizi hemen hemen elde edersiniz. TFS'deki hata sisteminin zayıf olduğuna karar verirseniz (ve sanırım yapacağınız), farklı bir sisteme geçmekte zorlanacaksınız.

TFS, diğer büyük, yağ dolu yaşam döngüsü araçlarıyla birlikte düşünülmelidir. Çoğu geliştirici, bu araçların kendilerine empoze ettiği kısıtlamalardan hoşlanmadığı için nefret eder.

Yine de denemek, 30 günlük denemeleri indirmek ve yüklemek. Değerlendirirken, burada ve orada biraz değişiklik yapmayı unutmayın, sadece bir iş kodu ile check-in, gerekli bir çalışma öğesiyle check-in ve bu çalışma öğesine dayalı raporlar almak için bir kaynak kodu için kullanmayın. Birden fazla iş öğesine bir check-in atamayı ve iş öğelerini ilişkili olarak birleştirmeyi deneyin. Oluşturma sistemine farklı bir şey eklemeye çalışın, raporlama hizmetlerinden günlük ilerleme raporunu nasıl alacağınızı görün, bir belgeyi bir iş akışı gereksinimine bağlayın ve yeniden işleme oluşturmak ve daha sonra yayınlamak için hata triyajı ile kodlamaya kadar takip edin. Çok dal ve birleştir. Tüm bunları kolayca yapamıyorsanız, git'e de yapışabilirsiniz. ALM özelliklerinin çoğundan yararlanmıyorsanız TFS'yi kullanmanın pek bir anlamı yoktur.

Büyük ölçüde Atlassian yığını olan bir şirketten (ve Mercurial) ağır TFS yığınına sahip bir şirkete geçtim. İki tahriş buluyorum.

Birincisi Kaynak Kontrolü .

DVCS'ye alıştığınızda, bir CVCS'ye geri dönmek acı vericidir. TFS özellikle acı vericidir, çünkü tüm bu entegrasyonun çalışması için her zaman sunucuya bağlanmakta ısrar eder.

Ancak, neyse ki Microsoft, Git sürüm kontrolünün TFS yığınının geri kalanına entegrasyonuna izin verdi . Bu yüzden Git'ten vazgeçmenize gerek yok ve herkesin zaten bildiği göz önüne alındığında size tavsiye etmiyorum.

Raf setlerine çok fazla güveniyor gibi göründüğü halde kod inceleme aracının Git'e karşı ne kadar iyi çalıştığından henüz emin değilim (biraz stashes gibi, ancak çok güçlü değil). Ancak daha sonra kod incelemesi için raf setlerine güvenmek kendi başına acı vericidir, çünkü düzenli taahhütleri caydırır.

Diğer tahriş, çoğu insanın TFS'den uzaklaşmayı düşünmemesinin sebebidir: Visual Studio Entegrasyonu .

Henüz bunun arkasındaki bilişsel akıl yürütmeyi anlayamadım, ancak deneyimlerime göre (ve bunun genelleştiğini göz önünde bulundurarak) TFS'ye alışkın olan insanlar entegrasyonu çok seviyor. Hiçbir şey için IDE'lerinin dışına çıkmak istemiyorlar.

Öte yandan, bir yıl sonra ısınmadım. Oluşturma sunucumun bir tarayıcı sekmesinde, biletlerimin başka bir tarayıcı sekmesinde vb. (Düzenleme: Andrei'nin belirttiği gibi, bir web arayüzü var, ancak Jira ve Jenkins'in daha yeni sürümlerine alıştığınızda da açıklanamaz derecede tıknaz. Ancak yine de, en azından şu anda IE dışındaki tarayıcılarda çalışıyor. bu bir şey.)

Yapmaya çalışmadıkça yapılara asla bakmıyorum ve sonra başka birinin zaten yaptıklarını bulmakta zorlanıyorum. İncelenmem istenmedikçe başkalarının değişikliklerini göremiyorum.

Ancak milajınız değişebilir. Dediğim gibi, bazı insanlar bunu vazgeçilmez buluyor. Genelde bunu asla başka bir şekilde yapmayan insanlar olduğunu fark edemiyorum.

Ayrıca, bunun oldukça büyük bir altyapıda biri kişisel olabilecek 2 negatif olduğunu fark etmeyin. Deneyimlerimin çoğu iyi ve TFS bazı insanların inandığı kadar kötü değil. Ve eksik olduğunu düşündüğünüz çoğu şey açılabilir (çok yapılandırılabilir); tek bir kişiden ziyade tüm bir takımı taşıdığınız göz önüne alındığında, daha az direnç bulabilirsiniz.

TFS 2012'yi kullanma konusunda çok olumlu bir deneyimim var. TFS sunucunuzu kurmak ve çalıştırmak oldukça kolaydır, CI derleme otomasyonu çok basit ve basittir (ve Gated check-in derlemesi sadece harikadır. Aynı işlevselliği elde edemedik Team City ile). Takım etkileşimi de çok şeffaf ve anlaşılır. Check-in'lerinizi TFS iş öğeleriyle kolayca ilişkilendirebilir, bir biriktirme listesini yönetebilir, hataları izleyebilir, kod görüntülemeleri yapabilir vb. =) İçinde bir messenger inşa bile var

Ancak, JIRA'nızın iş akışına alışkınsanız, TFS iş akışını ayarlamanın zor bir görev olabileceğini unutmayın. Önceden tanımlanmış TFS iş akışlarından birini kabul etmenizi öneririm. Ayrıca bilgi tabanı olarak Confluence'ı tutmanız veya TFS'de wiki oluşturma olmadığından SharePoint'e geçmeniz gerekecek.

Bir MSDN aboneliğiniz varsa (MS teknoloji yığını ile çalışan çoğu geliştirici şirketin buna sahip olduğuna inanıyorum) TFS çok daha ucuzdur, bu durumda ücretsiz TFS'ye sahipsiniz.

Tüm geliştiricileriniz Visual Studio ile çalışıyorsanız yan taraf araçlarını kullanmaya devam etmek için bir neden olmadığını düşünüyorum. TFS, entegre, sağlam ancak kullanımı kolay ALM sistemi sağlar. Eğer varsa sorularınızı memnuniyetle cevaplayacağım.

Halklar bilmeli, TFS sadece VCS değil, ALM .

Görünüşe göre birçok insan sadece bir VCS istiyor ama TFS'ye gitmek yanlış bir yol.
CVCS için hala SVN'yi tercih ediyorum.
Solo veya açık kaynak için mutlaka GIT'i tercih edin.

Ancak TFS2012 kötü değil, birleştirme / çatal üzerinde SVN'yi anlamak kolaydır.
Ve takım kuruluş hizmeti 5 kullanıcı / sınırsız, özel repo için ücretsizdir.

İstemci de ücretsiz, VS2010 üzerine TFS explorer inşa ve ücretsiz.
Eclipse için, her yerde Eclipse eklentisi var - TFS.

Bu konuda herhangi bir maliyet problemi görmüyorum.
TFS express (ücretsiz) SQL Server Express (ücretsiz de) ile çalışabilir.