Cách đánh giá việc chuyển sang Team Foundation Server

Nhóm phát triển của tôi hiện đang sử dụng phần mềm sau trong quy trình làm việc của chúng tôi:

• JIRA
• Tre (tích hợp liên tục Atlassian)
• Greenhopper (quản lý dự án nhanh Atlassian)
• Hợp lưu
• Git, được lưu trữ trên BitBucket
• Phòng thu hình ảnh 2012

Như bạn có thể thấy, chúng tôi đầu tư khá nhiều vào hệ sinh thái Atlassian. Chúng tôi đang xem xét chuyển sang TFS để chúng tôi có thể nhận được các đặc tính tích hợp Visual Studio tiên tiến như đánh giá mã và quan trọng hơn là Microsoft Test Manager.

Trải nghiệm trước đây của tôi với TFS là vào năm 2005 hoặc 2008 (tôi không thể nhớ) và tôi có những ký ức tồi tệ về nó, mặc dù không hoàn toàn tồi tệ như thời gian của tôi với ClearCase.

Những tiêu chí nào chúng ta nên xem xét để đánh giá đúng việc chúng ta chuyển sang TFS?

Cuộc khảo sát nhỏ của Martin Fowler nói rất nhiều về tình trạng của TFS trong những năm trước. "Nguy hiểm" là hoàn toàn đúng. (Tôi nghĩ rằng điều này đề cập đến cách nó không nhận ra các thay đổi được thực hiện bên ngoài VS, vì vậy bạn có thể tạo dự án WCF, sau đó sử dụng công cụ svcutil bên ngoài để tạo ứng dụng khách của mình, sau đó kiểm tra tất cả các thay đổi của bạn trong .. nhưng TFS sẽ vui vẻ bỏ qua các thay đổi của khách hàng của bạn vì chúng không được thực hiện trong VS).

Bạn phải tính chi phí: phiên bản bắt buộc của VS để có được các tính năng - ví dụ như đánh giá mã, yêu cầu phiên bản Premium đắt hơn đáng kể nếu bạn nhận được VS qua MSDN. Ngoài ra, truy cập hệ thống cho người dùng không phải là VS cũng tốt, nhưng nếu họ muốn truy cập đầy đủ thay vào đó là chế độ xem web bị cắt, thì bạn sẽ phải trả tiền cho CAL cho họ. Tổng chi phí của TFS có thể khá nhiều. Ngay cả báo cáo của Forrester gần đây. (có tới 4,5 quản trị viên trên 122 người dùng đó ... điều này rất nhiều so với việc tôi thiết lập và duy trì giải pháp SVN đầy đủ trong khi cũng làm công việc hàng ngày của mình). TFS có thể mất rất nhiều nỗ lực để tiếp tục làm việc như mọi người mong đợi.

Theo kinh nghiệm của tôi với TFS2012 (quên các phiên bản trước vì chúng là rác rưởi), đó là một quản trị hệ thống rất phức tạp, đặc biệt nếu bạn bước ra ngoài thiết lập được xác định trước. Ví dụ: nếu bạn sử dụng MSBuild để xây dựng mọi thứ, bạn sẽ ổn thôi. Nhưng nếu bạn có, giả sử, tải các dự án .vdproj cũ không còn được MSBuild hỗ trợ, bạn phải chỉnh sửa tập lệnh xây dựng xaml khổng lồ để xây dựng các dự án này. Sau vài ngày làm việc này, điều tốt nhất tôi có thể làm là xây dựng lại giải pháp bằng cách chuyển nó đến devenv, và thậm chí sau đó, đưa kết quả xây dựng ra và vào bản tóm tắt bản dựng là không thể. Các nhóm khác đã sử dụng NUnit cho các thử nghiệm của họ - nếu bạn sử dụng MSTest tích hợp, thì nó hoạt động. Nếu không, bạn bị nhồi nhét khá nhiều.

Là một người dùng, tôi thấy rằng việc tích hợp có nhiều phiền toái. Tôi thích TortoiseSVN và tôi thực hiện gần như tất cả các SCM của mình hoạt động thông qua đó (vì nó là một công cụ tuyệt vời). Với TFS, bạn kết thúc với một màn hình mới bên trong VS cho mọi thao tác. Vì vậy, bạn có một tab mới trong môi trường của mình cho nhóm thám hiểm và một tab khác cho các bản dựng và một tab khác cho mỗi bản tóm tắt bản dựng bạn muốn xem (và nếu bạn muốn xem chi tiết về bản dựng, ví dụ như lỗi, bạn có nhấp qua quá nhiều liên kết). Tôi thấy số lượng tài liệu tôi đã mở khi sử dụng TFS nhiều hơn các tệp nguồn!

Điều tương tự cũng áp dụng cho các đăng ký, cam kết các thay đổi cần thiết khi nhấp qua một số tab trên ngăn Thay đổi đang chờ xử lý trong VS để gán một mục công việc và nhận xét cho các đăng ký của bạn. Đó là một việc nhỏ, nhưng tôi thấy khó chịu vì tôi đã quen với các công cụ hợp lý hơn.

Mở rộng hệ thống xây dựng là một lĩnh vực khác mà tôi thấy thiếu. Việc thêm các tính năng mới vào bản dựng rất khó khăn vì cấu hình xaml và việc đưa kết quả của các tính năng đó vào màn hình bản dựng của bạn là rất khó hoặc không thể. Vì vậy, nếu bạn muốn thêm các công cụ như độ phức tạp của mã hoặc phân tích tĩnh hoặc thậm chí kiểm tra tự động thông qua, hãy nói selen hoặc triển khai ... hãy quên nó đi. Trừ khi, bạn đang sử dụng các công cụ của Microsoft cho các khía cạnh này (ví dụ: fxcop).

Cập nhật quy trình công việc là một vấn đề khó khăn khác - mặc dù các bộ truyền động đã giúp rất nhiều, nhưng vẫn rất khó để xử lý công việc đúng và bạn vẫn không thể định cấu hình bảng scrum với thông tin bạn thực sự muốn xem - một lần nữa, bạn nhận được mặc định hoặc không có gì .

Việc hợp nhất cũng rất khó khăn, tôi nghĩ rằng có một lý do rất chính đáng để MS chấp nhận git cho TFS (lưu ý rằng điều này chỉ hoạt động với các dự án TFS hoàn toàn mới, bạn không thể chuyển đổi từ TFS sang git backends).

Vì vậy, tất cả, nó không quá tệ vì nó hoạt động, nhưng tôi đã tìm thấy rất nhiều công cụ khác tốt hơn nhiều. Nhược điểm của những công cụ đó là chúng không được tích hợp đầy đủ, nhưng IMHO đây là một thế mạnh khi bạn có thể chọn và chọn các bit tốt nhất bạn muốn. Với TFS, bạn nhận được khá nhiều thứ mà người khác muốn bạn có. Nếu bạn quyết định hệ thống lỗi trong TFS kém (và tôi nghĩ bạn sẽ làm được), bạn sẽ khó thay đổi sang một hệ thống khác.

TFS nên được xem xét cùng với các công cụ vòng đời lớn, béo khác. Hầu hết các nhà phát triển ghét những thứ như vậy vì họ không thích những hạn chế mà các công cụ này cuối cùng áp đặt lên chúng.

Tôi sẽ thử nó mặc dù, tải về các bản dùng thử 30 ngày và cài đặt nó. Khi đánh giá hãy nhớ thay đổi một chút ở đây và ở đó, đừng chỉ sử dụng nó để kiểm tra mã nguồn, hãy đăng ký với một yêu cầu công việc và nhận báo cáo dựa trên quy trình đó. Hãy thử gán một checkin cho nhiều workitem và thử kết hợp các workitem với nhau như có liên quan. Hãy thử kết hợp một cái gì đó khác vào hệ thống xây dựng, xem cách lấy báo cáo tiến độ hàng ngày ra khỏi các dịch vụ báo cáo, liên kết tài liệu với yêu cầu quy trình công việc và theo dõi thông qua xử lý lỗi để mã hóa để xây dựng để làm lại và sau đó phát hành. Chi nhánh và hợp nhất rất nhiều. Nếu bạn không thể dễ dàng làm tất cả những điều này, thì bạn cũng có thể dính vào git. Không có nhiều điểm để sử dụng TFS nếu bạn không tận dụng hầu hết các tính năng ALM của nó.

Tôi đã chuyển từ một công ty có phần lớn Atlassian (và Mercurial) sang một công ty có chồng TFS nặng. Tôi thấy hai sự cáu kỉnh.

Đầu tiên là Kiểm soát nguồn .

Khi bạn đã quen với DVCS, việc quay trở lại CVCS thật khó khăn. TFS đặc biệt đau đớn bởi vì, để tất cả sự tích hợp đó hoạt động, nó luôn khăng khăng được kết nối với máy chủ.

Tuy nhiên, rất may, Microsoft gần đây đã cho phép tích hợp kiểm soát phiên bản Git vào phần còn lại của ngăn xếp TFS. Vì vậy, bạn không cần phải từ bỏ Git, và tôi khuyên bạn không nên, cho rằng mọi người đã biết điều đó.

Tôi vẫn chưa chắc chắn công cụ đánh giá mã hoạt động tốt như thế nào đối với Git, mặc dù nó dường như phụ thuộc rất nhiều vào các kệ (hơi giống như stash, nhưng không quá mạnh). Nhưng sau đó dựa vào các kệ để xem xét mã tự nó là đau đớn vì nó không khuyến khích các cam kết thường xuyên.

Sự khó chịu khác là lý do hầu hết mọi người sẽ không cân nhắc việc rời khỏi TFS: Visual Studio Integration .

Tôi vẫn chưa tìm ra lý do nhận thức đằng sau điều này, nhưng theo kinh nghiệm của tôi (và có tính đến việc đây là khái quát hóa), những người đã quen với TFS thích sự tích hợp. Họ không muốn di chuyển ra ngoài IDE của mình cho bất cứ điều gì.

Mặt khác, tôi đã không ấm lên sau một năm. Tôi thấy nó lộn xộn và khó điều hướng, so với việc có máy chủ xây dựng của tôi trong một tab trình duyệt, vé của tôi trong một tab trình duyệt khác, v.v. (Chỉnh sửa: Như Andrei lưu ý, có một giao diện web, nhưng nó cũng khó hiểu một cách khó hiểu, khi bạn đã quen với các phiên bản gần đây hơn của Jira và Jenkins. đó là một cái gì đó.)

Tôi không bao giờ nhìn vào các bản dựng trừ khi tôi đang cố gắng thực hiện một bản, và sau đó tôi thấy khó tìm ra nếu người khác đã làm một bản. Tôi không thấy những thay đổi của người khác trừ khi tôi được yêu cầu xem xét.

Nhưng, milage của bạn có thể thay đổi. Như tôi nói, một số người dường như tìm thấy nó không thể thiếu. Tôi chỉ không thể nhận ra rằng nói chung đó là những người chưa bao giờ làm điều đó theo cách khác.

Ngoài ra, đừng để ý rằng đây là 2 tiêu cực, một trong số đó có thể là cá nhân, trong một cơ sở hạ tầng khá lớn. Hầu hết kinh nghiệm của tôi là tốt và TFS không tệ như một số người sẽ tin bạn. Và hầu hết những thứ bạn thấy bạn đang thiếu có thể được bật (nó rất có thể cấu hình); cho rằng bạn đang di chuyển cả một nhóm, thay vì một người, bạn có thể thấy ít kháng cự hơn.

Tôi có trải nghiệm rất tích cực khi sử dụng TFS 2012. Việc cài đặt và chạy máy chủ TFS của bạn khá dễ dàng, tự động hóa xây dựng CI rất đơn giản và dễ hiểu (và bản dựng kiểm tra Gated chỉ tuyệt vời. Chúng tôi không đạt được chức năng tương tự với Thành phố đội). Tương tác nhóm rất minh bạch và đơn giản. Bạn có thể dễ dàng liên kết các đăng ký của mình với các công việc TFS, quản lý tồn đọng, theo dõi lỗi, thực hiện các lần xem mã hóa, v.v. Thậm chí còn có một trình xây dựng tin nhắn trong =)

Tuy nhiên, hãy nhớ rằng nếu bạn đã quen với quy trình làm việc của JIRA, thiết lập quy trình làm việc TFS có thể là một nhiệm vụ khó khăn. Tôi khuyên bạn nên áp dụng một trong các quy trình TFS được xác định trước. Ngoài ra, bạn sẽ phải giữ Confluence làm cơ sở kiến ​​thức hoặc chuyển sang SharePoint vì không có wiki xây dựng vào TFS.

TFS rẻ hơn nhiều nếu bạn có đăng ký MSDN (tôi tin rằng hầu hết các công ty phát triển làm việc với ngăn xếp công nghệ MS đều có nó) trong trường hợp đó bạn có TFS miễn phí.

Tôi nghĩ không có lý do gì để tiếp tục sử dụng các công cụ của các bên nếu tất cả các nhà phát triển của bạn đang làm việc với Visual Studio. TFS cung cấp hệ thống ALM tích hợp, mạnh mẽ nhưng dễ sử dụng. Tôi sẽ sẵn sàng trả lời câu hỏi của bạn nếu bạn có bất kỳ.

Mọi người nên biết, TFS không chỉ là VCS, mà là ALM .

Có vẻ nhiều người chỉ muốn có một VCS nhưng đi TFS là sai cách.
Đối với CVCS, tôi vẫn thích SVN.
Đối với solo hoặc mã nguồn mở, chắc chắn đi GIT.

Nhưng TFS2012 không tệ, dễ hiểu về hợp nhất / ngã ba rồi SVN.
Và dịch vụ nền tảng nhóm là miễn phí cho 5 người dùng / không giới hạn, repo riêng.

Client cũng miễn phí, TFS explorer xây dựng trên VS2010 và nó miễn phí.
Đối với Eclipse, nó có plugin Eclipse - TFS ở mọi nơi.

Tôi không thấy bất kỳ vấn đề chi phí về điều đó.
TFS express (miễn phí) có thể hoạt động với SQL Server Express (miễn phí).