Bộ công cụ đơn giản nhất để bắt đầu với Kiểm soát nguồn, TDD và CI cho Microsoft.Net 2008/2010

Question

Tôi làm việc trên một nhóm với ba nhà phát triển khác và một nhà phân tích nghiệp vụ viết các ứng dụng kinh doanh nội bộ là gì. Chúng tôi chủ yếu xây dựng các ứng dụng trong ASP.Net, và làm như vậy theo một cách rất riêng của năm 2003. Nó giống như trở lại trong một cỗ máy thời gian. Mặc dù hai trong số các nhà phát triển khác có thể học được những điều mới mẻ, nhưng một trong những nhà phát triển thì không. Anh ấy là kiểu người nghĩ anh ấy là nhà phát triển mạnh nhất trong thị trấn và nếu anh ta không hiểu một công cụ mới trong vòng 5 phút thì anh ấy chỉ cần xây dựng công cụ của riêng mình. Anh ta cũng không nhận ra sự phát triển nhanh, TDD, hoặc về cơ bản là bất kỳ công cụ hoặc phương pháp nào không phải của Microsoft. Anh ta thậm chí còn xem xét kiểm soát nguồn từ bất cứ thứ gì khác ngoài SourceSafe là nguy hiểm. Để tín dụng của mình, anh ấy là một lập trình viên rực rỡ, chỉ cần không ai đó quan tâm đến việc phát triển phần mềm .

Vì vậy, cách duy nhất tôi có thể nhận được sự đồng thuận là nếu một công cụ thực sự dễ sử dụng. Một khi chúng tôi đánh một cú đánh duy nhất, anh ấy sẽ mất niềm tin vào một cách "tôi đã nói với bạn".

Vậy tôi nên sử dụng công cụ nào để đưa chúng ta vào hệ thống kiểm soát nguồn hiện đại, TDD và CI? Sự lựa chọn hiển nhiên trong tình huống của tôi có vẻ giống như TFS của Microsoft, nhưng tôi nghi ngờ rằng tôi có thể có được đội ngũ quản lý tiết kiệm và thờ ơ của chúng tôi để tiêu thêm tiền (họ đã nghĩ MSDN Pro là quá nhiều).

Về cơ bản, công cụ đơn giản nhất để thực hiện điều khiển Nguồn, TDD và CI cho môi trường .Net 2008/2010 là gì?

Answer 1

Trong môi trường .NET, Microsoft Visual SourceSafe thường được sử dụng nhất. (nhưng chi phí). Bên cạnh đó bạn có thể chọn SVN hoặc GIT. Git là gần đây hơn (và được phổ biến). Việc làm việc dễ dàng hơn SVN một khi bạn nhận được nó.

http://git.wiki.kernel.org/index.php/GitSvnComparison có thể giúp bạn quyết định.

Answer 2

Sẽ rất khó để giới thiệu các công cụ mới nếu bạn không thể xây dựng được sự đồng thuận. Tập trung vào việc xây dựng sự đồng thuận, hơn là trên các công cụ.

SVN là rất tốt (với Ankh và TSVN), nhưng nó có thể là một chút đáng ngạc nhiên cho những người sử dụng để SourceSafe.

TDD là một kỹ thuật, chứ không phải là bộ công cụ, vì vậy bạn cần sách, blog, v.v. Đối với các công cụ hỗ trợ nó, NUnit hoặc MSTest. Tích hợp liên tục là phải có. CruiseControl.Net là khá tốt (mặc dù một chút khó khăn để cấu hình ban đầu). Cũng xem xét TeamCity.

Bạn có hệ thống theo dõi lỗi không?

Ồ, và nếu nhóm quản lý của bạn cảm thấy thờ ơ, hãy cân nhắc việc bỏ thuốc.

Cập nhật: bạn đã nói rằng chúng không quá nhiều "thờ ơ" như "vô hiệu hóa". Câu hỏi: họ có thật sự bắt tay và họ có cho phép bạn di chuyển mọi thứ cùng không? Hay là "trạng thái" - "nó không bị phá vỡ, vì vậy đừng sửa nó, và đừng đá thuyền"?

Answer 3

Có rất nhiều sự lựa chọn tốt, nhưng cá nhân tôi có thể giới thiệu sau đây:

• Nguồn kiểm soát: Subversion với TortoiseSVN và Ankh hoặc VisualSVN
• Tích hợp liên tục: CruiseControl.NET
• cụ TDD: NUnit + khung mocking của bạn lựa chọn (Tôi sử dụng NMock, mặc dù đó là một chút trường học cũ). Tôi đồng ý với commenter Eric rằng TestDriven.NET là một-phải có, đặc biệt là nếu bạn muốn thực hiện điều này dễ dàng!

Đây là những cách dễ dàng để bắt đầu vì chúng là tất cả các sản phẩm tốt, hợp lý để được tài liệu hóa và sử dụng rộng rãi (vì vậy thật dễ dàng để nhận trợ giúp).

Answer 4

Tôi sẽ không khuyên bạn nên đổ tất cả các công cụ và phương pháp này vào nhóm của bạn cùng một lúc, thực hiện các bước cho em bé. Giới thiệu từng cái một. Một số sẽ đến một cách tự nhiên.

Answer 5

Tôi nghĩ bạn có thể tạo ra một trường hợp thực sự tốt trong vòng hai năm qua Agile đã trở nên hoàn toàn và hoàn toàn được Microsoft chấp nhận. Tôi biết một thực tế là các đội Codeplex, MEF và ASP.NET MVC khá ngập trong đó. Tôi cũng nghĩ rằng rằng studio trực quan và các bộ phận của nhóm Windows 7 là Agile. Ngoài ra, hãy xem xét rằng Visual Studio 2010 bao gồm các phép tái cấu trúc ngoài hộp không thực sự có ý nghĩa bên ngoài ngữ cảnh TDD và Agile là mẫu quản lý dự án mặc định cho TFS và một bức tranh về văn hóa doanh nghiệp hoàn toàn khác từ một trong những năm qua bắt đầu xuất hiện.

Đối với các công cụ cụ thể. TFS là OK để kiểm soát nguồn nhưng tôi thấy nó rất nặng và khó tính. Những người khác đã đề cập đến Subversion nhưng nếu bạn đang lo lắng về phước lành MS bạn có thể có may mắn hơn nhảy thẳng đến Mercurial. Nó là một SCM cao cấp hơn nhưng bây giờ nó được hỗ trợ bởi Codeplex và có tích hợp các cửa sổ tuyệt vời. Tôi đã không bao giờ sử dụng nó nhưng tôi đang ở trong tình yêu sâu sắc công cụ với nó git anh em họ.

Phát triển theo hướng thử nghiệm: Bắt đầu với MSTest, nó không phải là bóng bẩy như bất kỳ ai muốn nhưng nó không phải là điều tồi tệ nhất trên thế giới. Tôi cũng khuyên bạn nên dùng MbUnit có tất cả các tính năng của NUnit cùng với một số hỗ trợ tốt cho các bài kiểm tra tích hợp mà bạn có thể sẽ viết do tai nạn khi bạn bắt đầu với thử nghiệm. Oh, và nếu bạn có freak tùy biến tôi sẽ thúc giục anh ta nhìn vào XUnit.Net.

Mocking: Sự lựa chọn về cơ bản là Rhino Mocks hoặc MoQ. Here's a quick intro I wrote for Rhino Mocks mà đi qua tất cả các khái niệm cơ bản. Điều đó đang được nói, giao dịch có vẻ là tài liệu hướng dẫn cho RM so với cú pháp dễ bị lỗi rất ít đối với MoQ.

Test Runners: Nếu bạn bắt đầu với MSTest, bạn sẽ nhận thấy rằng bạn có thể tăng tốc độ đáng kể trong thử nghiệm bằng cách sử dụng TestDriven.Net, resharper hoặc coderush thay vì được xây dựng trong runner thử nghiệm. Điều đó đang được nói, đừng đánh giá thấp những người chạy thử nghiệm độc lập. Họ có thể khá tốt mỗi lần trong một thời gian. Tôi khuyên bạn nên sử dụng Gallio Icarus runner đi kèm với MbUnit.

Answer 6

Một công cụ khiến tôi bị hocked trên TDD là TestDriven.Net để đặt kết quả thử nghiệm vào cửa sổ Output. Tôi lập bản đồ này với phím F8 và đạt được năng suất là tuyệt vời; viết một bài kiểm tra, nhấn F8 và xem kết quả này trong cửa sổ đầu ra.

Một gợi ý tôi cũng phải phân biệt giữa việc có các xét nghiệm đơn vị và thực hiện TDD. Tôi đã thấy rằng TDD có thể rất khó để tiếp tục với một nhóm, trong khi đó; đơn vị, tích hợp hoặc kiểm tra chức năng là một bán dễ dàng hơn. Có một loạt các bài kiểm tra mà tiết kiệm một giờ đi qua một ngày thử nghiệm thủ công sau khi ngày là một chiến thắng lớn.

Sau một thời gian mọi người sẽ bắt đầu đánh giá cao một số ý tưởng mới nếu nó giúp họ trong cuộc sống hàng ngày của họ. Sau đó, bạn sẽ có thể giới thiệu một máy chủ xây dựng và di chuyển ra khỏi SourceSafe.

Answer 7

Tôi muốn lặp lại những gì George Mauer đã nói và đề xuất bắt đầu với MSTest để kiểm tra đơn vị của bạn. Đó là ngay trong hộp để bắt đầu với Visual Studio, điều này sẽ giúp trong nguyên nhân của bạn vì nó là "MS may mắn".

Tôi sẽ bắt đầu với thử nghiệm đơn vị và lấy nó từ đó, sau một vài tháng "nhìn cuộc sống của chúng tôi dễ dàng hơn bao giờ hết khi chúng tôi có các thử nghiệm này một cách tự động". Cân nhắc thêm một thứ gì đó như Selenium hoặc WatiN vào hỗn hợp. Một khi bạn đang lăn với điều đó, có được máy chủ CI của bạn lên. "Sẽ không tuyệt vời nếu chúng tôi không phải bắt đầu tất cả các thử nghiệm này theo cách thủ công? ..."

Tôi đoán SCM khá có thể là điểm gắn bó. SourceSafe là tốt hơn không có gì. Có lẽ bắt đầu sử dụng Mercurial hoặc Git cho mình? Cho thấy những người cởi mở với sự thay đổi lợi ích, cuối cùng dev của bạn bướng bỉnh sẽ đến xung quanh khi những người khác xung quanh anh ta muốn chuyển đổi. Hy vọng rằng, anh ta sẽ thấy khó hét hơn nếu anh ta ở trong nhóm thiểu số.

Kiểm tra http://www.viget.com/extend/effectively-using-git-with-subversion/ để biết các ý tưởng về cách trộn các SCM khác nhau.

Tôi cũng muốn +1 mxmissile để nói chậm rãi. Tôi nghĩ bạn sẽ thấy rất khó để giới thiệu tất cả những thay đổi này trong một lần. Đó là rất nhiều để có trong lúc đầu tiên nếu bạn không quen với nó. Cố gắng chọn phần bạn yếu nhất, hoặc sẽ thêm nhiều giá trị nhất và tích lũy từ đó.

Chúc may mắn!