FishEye có thể làm gì mà chúng ta không thể nhận được từ các công cụ khác cho kho lưu trữ git?

Question

Chúng tôi đã quyết định về Jira và Confluence và hiện đang xem xét các công cụ Atlassian khác có thể làm cho cuộc sống của chúng ta dễ dàng hơn.

Tôi hiểu rằng FishEye cho phép tất cả các loại hình ảnh hóa của kho lưu trữ mã nguồn mà công cụ gốc cho CVS không. Tuy nhiên, chúng tôi đã chuyển sang git, có hệ sinh thái lớn với các công cụ rất hữu ích.

Câu hỏi là: FishEye có thể cho chúng tôi biết điều gì đó hữu ích mà chúng tôi không thể có được từ các công cụ gốc không? (Hoặc các công cụ thương mại với giá cạnh tranh)?

Answer 1

Một trong những lợi ích chính mà chúng tôi nhận được từ việc sử dụng FishEye là phân lớp trên Crucible trên đầu trang của nó, tạo điều kiện đánh giá mã từ xa.

Answer 2

Cập nhật tháng 1 năm 2013: được gọi là Stash ngay bây giờ.
(xem sendmoreinfo 's comment)

---

Original câu trả lời tháng 2 năm 2012:

Từ FishEye2.7, bạn không thể truy cập chỉ repo từ xa, nhưng cũng tạo trong máy chủ fisheye Git mới repo.
Xem "the FishEye manual page", "Creating a Git repository" và "Enabling Repository Management in FishEye".
Các bài viết trên blog "FishEye in Practice: Setting up your own Git repositories" cũng trình bày tính năng đó, danh sách các mục tiêu cho tính năng đó:

• Cho phép các doanh nghiệp để có được hoặc chuyển sang Git kho đằng sau tường lửa của họ
• Làm cho nó đơn giản để cấu hình các kho quyền cho các đội

Điều đó có nghĩa là FishEye sẽ tận dụng lớp truy cập (như máy chủ Apache mà FishEye đang chạy) cho nội bộ Git truy cập repo.

Nó cũng sẽ cung cấp cơ chế cấp phép cơ bản, có nghĩa là bạn không phải thiết lập cơ sở hạ tầng riêng như Apache + Gitolite khác để quản lý nội bộ: bạn có thể trực tiếp sử dụng máy chủ FishEye.

Answer 3

Chúng tôi di chuyển xa bằng fisheye gây ra nó còn chậm và cồng kềnh trên các máy chủ hạn chế của chúng tôi. Hạnh phúc hơn nhiều khi sử dụng JIRA cùng với Git trên GitHub. Một số tính năng trực quan mà FishEye chào hàng, cũng không được hỗ trợ trong Git. Tôi là một fan cuồng nhiệt của Atlassian, tôi chỉ nghĩ FishEye không phải là một trong những công cụ tốt nhất cho Git.

Answer 4

Cá nhân tôi thích Fisheye, nhưng đó là môi trường dev có kích thước trung bình và chiến lược phân nhánh/phát triển bán phức tạp, theo dõi trạng thái hiện tại của repo khá quan trọng.

Ở công việc cuối cùng, sản phẩm chính của chúng tôi là một dòng sản phẩm Java, hộp đóng hộp trắng, nơi tất cả thanh toán và tích hợp hệ thống được xử lý trong nhà. Mặc dù hầu hết mọi người đều là những kẻ tấn công Emacs/dòng lệnh, chúng tôi vẫn sử dụng Fisheye trên tất cả các dòng sản phẩm chính của chúng tôi.

Hãy cẩn thận

• nầy cũng ở với SVN, không git/hg, vì vậy thực hiện việc này với một hạt muối.
• Có móc SVN khác được xây dựng trong liên quan đến Bugzilla rằng tôi không chắc chắn 100% về cách họ làm việc

kỹ sư reshuffled làm việc trên sản phẩm mà không có Fisheye là thường không hài lòng vì những lý do sau đây:

• Refactoring file Điển hình là bạn đang di chuyển xung quanh, đổi tên, sáp nhập những thay đổi có liên quan và những thứ tương tự. Tìm kiếm Fisheye theo tên cơ sở sẽ trả về các tệp đã bị xóa từ lâu vì lịch sử của chúng được duy trì, vì vậy ngay cả khi bạn làm hỏng lịch sử trong repo, bạn có cảm giác về những thay đổi trước đó. Đối với một cơ sở mã đã được trải qua một số cơn đau ngày càng tăng rất thực tế từ một sự mở rộng đột ngột cho công ty, đây là một sự giúp đỡ rất lớn

• Mã sở hữu/giá Mặc dù không có một quá trình mã quyền sở hữu/tổng quan mạnh mẽ, bạn có thể chọn trong các thay đổi dự án/repo cụ thể với Fisheye. Đối với những người dẫn đầu nhóm và những thứ tương tự, đó là cách rất đơn giản để luôn cập nhật những gì người khác đang làm khi họ thay đổi mọi thứ và tại sao, cho dù bạn muốn nhận email spam hay thiết lập nguồn cấp dữ liệu RSS cho repo. Nếu bạn đang quản lý nhiều dự án cùng một lúc, đó có thể là một vấn đề lớn. Tôi đã có một RSS feed thiết lập cho dự án lớn đầu tiên của tôi vì vậy tôi có thể nhìn thấy nó như thế nào đã được thay đổi, nhưng lợi ích thực sự là để giám sát các dự án API liên quan đến khi họ thay đổi

• Có thể sử dụng Không phải tất cả các kỹ sư của chúng tôi là chỉ huy tin tặc. Điều này đặc biệt đúng đối với một số kỹ sư giao diện người dùng xử lý HTML/CSS. Cũng giống như một số người có xu hướng quay trở lại các công cụ dòng lệnh khi có thể, thực hiện các tệp khác nhau và 'Ai đã hoàn nguyên thay đổi của tôi và khi nào?' nó dễ dàng hơn trong việc xử lý các công cụ khác trong trình duyệt hơn là làm 'đổ lỗi svn' và tương tự.

Tất cả những gì đã nói, tôi sẽ nói nếu tôi làm một cửa hàng dev từ đầu, tôi sẽ không chạm vào nó trừ khi tôi cần trực quan hóa toàn bộ dự án thay vì một tệp cụ thể hoặc hai tất cả bây giờ và một lần nữa, mà có lẽ có nghĩa là những điều sau đây là đúng:

• Kích thước của nhóm tôi nhấn xấp xỉ khoảng 10+ các kỹ sư của nền có khả năng phi kỹ thuật và đang cần hoặc tổ chức lại từ một chiến lược quảng cáo hoc
• Phân nhánh/gắn thẻ phục vụ một số nhu cầu cụ thể nhiều như phiên bản chung
• Quyền sở hữu và xem xét mã tăng lực kéo là ý tưởng được thi hành lỏng lẻo ở mức tối thiểu thay vì lập trường cứng rắn chống lại nó do các ràng buộc tài nguyên
• Giao tiếp giữa các kỹ sư là một vấn đề ngày càng tăng (cho dù đó là tiếng ồn tuyệt đối hay thiếu)). Điều này bao gồm cuộc trò chuyện thông thường với tài liệu thẳng

Tôi cũng bỏ qua mọi tích hợp công cụ phân tích/công cụ. Một phần bởi vì tôi cho rằng nếu bạn so sánh Fisheye với bất kỳ thứ gì khác, bạn cũng nên xem xét thêm bao nhiêu công sức để duy trì Fisheye so với giải pháp khác so với việc sử dụng nó, nhưng cũng bởi vì tôi chưa bao giờ làm việc nhiều hơn một sản phẩm Atlassian tại một thời điểm.

Trong trường hợp của bạn, tôi cũng sẽ xem xét các bộ phận tích hợp Jira/Fisheye và xem liệu tính năng bạn cần vào lúc này (hay không) khi xem các tùy chọn thương mại khác.

Answer 5

Tôi thực sự thích sự tích hợp giữa fisheye và Jira. Có dự án của bạn trong jira liên kết với kho lưu trữ của bạn trong fisheye là tuyệt vời. Bạn nhận được tab "nguồn" trong jira. Sau đó, khi bạn cam kết với id lỗi/nhiệm vụ trong nhận xét cam kết, các tệp từ cam kết hiển thị trong tab nguồn trong jira và bạn có thể chỉ cần nhấp qua để xem chính xác những gì đã thay đổi trong cam kết cho lỗi/tác vụ đó. Phải thừa nhận rằng tôi đã chỉ làm điều đó trên SVN, vì vậy tôi không thể nói chắc chắn nếu nó hoạt động với git, nhưng nó sẽ là giá trị điều tra.

Một tính năng thú vị khác là bạn có thể tạo ra lỗi jira từ trong đánh giá nồi nấu. Tôi có thể làm nổi bật dòng mã vi phạm, tạo lỗi, sau đó người tạo sẽ nhận được cảnh báo nếu có lỗi chưa được giải quyết liên quan đến đánh giá khi họ cố tóm tắt/đóng bài đánh giá.

Làm việc trên một nhóm từ xa 100%, tôi thấy Crucible trên fisheye là vô giá đối với đánh giá mã.

Answer 6

Đối với tôi phần thú vị là tôi có thể nhanh chóng tìm ra cam kết nào liên quan đến vấn đề. Nó sẽ là một phần của JIRA. Vì vậy, nếu tôi repport một lỗi trên một dự án tôi không trực tiếp làm việc trên, tôi có thể kiểm tra như thế nào sửa chữa là như tôi mong đợi, mà không cần phải sao chép dự án, sau đó tìm kiếm các bản ghi lịch sử cam kết.

Nó cũng buộc các nhà phát triển đặt thẻ phát hành vào thư cam kết của họ.

Đánh giá mã cũng rất thú vị, nhưng cho đến nay chúng tôi không sử dụng nó thường xuyên.