Theo dõi vấn đề phân tán [đóng]

Theo dõi vấn đề phân tán có vẻ như là một ý tưởng vành đai đối với tôi, nhưng nó chưa bao giờ thực sự cất cánh theo một cách lớn. Có một lý do tốt cho điều đó?

Tôi nhận thức được:

bugz ở khắp mọi nơi
- quá phức tạp để thiết lập
- quá nhiều yêu cầu
- hợp lý thành công, được sử dụng bởi một số dự án lớn
hóa thạch
- cố gắng tích hợp quá nhiều thứ, và cuối cùng trở thành một phiên bản tồi tệ hơn của tất cả chúng - ngoại trừ phần theo dõi vấn đề phân tán, là điều tốt (có lẽ là tốt nhất tôi đã thấy)
một số dự án nhỏ khác
- không ai trong số họ đạt được bất kỳ lực kéo nào

Tôi đang suy nghĩ về việc làm cho riêng mình, nhưng trước khi tôi bắt đầu, tôi muốn biết tại sao không ai trong số những người khác đã cất cánh theo cách lớn.

Các vấn đề dự đoán: (Tôi nghĩ rằng tất cả chúng có thể được khắc phục)

hợp nhất các vấn đề phân tán khi chúng được cập nhật rất phức tạp, cũng như hợp nhất bất kỳ tệp mã nào
tính liên tục của cuộc trò chuyện có thể bị phá hủy, vì các bình luận có thể xuất hiện bất cứ lúc nào, có lẽ không đúng luồng
kỳ vọng của máy chủ trung tâm với các vấn đề cập nhật

version-control issue-tracking distributed-computing

— Billy Moon
nguồn

2c của tôi là theo dõi vấn đề phân tán không có nhiều ý nghĩa theo nhiều cách - quan điểm của theo dõi vấn đề là giữ cho tất cả mọi người trên cùng một trang để tập trung là tốt. Nếu tôi muốn phân phối, tôi chỉ cần sử dụng evernote.

— Wyatt Barnett

@WyattBarnett đó là một mối quan tâm hợp lệ, có lẽ được giảm nhẹ bởi các mẫu hành vi và có lẽ là phần mềm. Cá nhân tôi thấy sự khác biệt duy nhất giữa một blog và một trang web là tần suất bạn cập nhật nó, nó không giống nhau để theo dõi vấn đề phân tán? Nếu bạn cập nhật nó thường xuyên, nó có giống như kiểm tra một trang web về các vấn đề thường không? Nguy hiểm duy nhất là mọi người không cập nhật và gửi vấn đề thường xuyên, nhưng miễn là có giải pháp một cú nhấp chuột, đó không phải là vấn đề phải không? Tôi hiểu rằng nhu cầu kết nối này mâu thuẫn với một trong những lợi ích lớn của distributedviệc theo dõi vấn đề.

— Billy Moon

Không gửi vấn đề là vấn đề số 1 tôi đã thấy trong trình theo dõi lỗi. Như @JeffO chỉ ra rằng có một số khả năng ngoại tuyến quan trọng hơn nhiều so với việc có một hệ thống phân tán. Theo cách tương tự git là tốt nhưng github thực sự làm cho git đáng giá.

— Wyatt Barnett

@WyattBarnett thật khó để suy đoán mọi người sẽ phản ứng thế nào với một công cụ được hình thành tốt. Có lẽ họ sẽ có nhiều khả năng gửi các vấn đề hơn nếu có thể thực hiện ngoại tuyến và không có kết nối / đăng nhập rõ ràng. Có lẽ những người gửi vấn đề trực tuyến sẽ kết thúc việc trì hoãn bài đăng của họ nếu có sẵn ngoại tuyến. Trực giác của tôi, là nếu nó được tạo ra cực kỳ đơn giản, mọi người sẽ làm điều đó thường xuyên, bởi vì nếu họ đã tạo ra một vấn đề, họ sẽ muốn cả thế giới nhìn thấy nó.

— Billy Moon

Làm thế nào một người quản lý sẽ xử lý hai dự án khác nhau với một số thành viên trong nhóm? Họ sẽ muốn một số loại khả năng báo cáo rộng của công ty.

— JeffO

Câu trả lời:

Chỉ vì kiểm soát nguồn + phân phối là một thành công lớn, theo dõi vấn đề + phân phối không nhất thiết là một ý tưởng hay.

Chúng ta thu được gì từ kiểm soát nguồn phân tán và nó sẽ áp dụng để theo dõi vấn đề?

Dễ dàng phân nhánh và sáp nhập : không thực sự. Trên thực tế, điều quan trọng là tất cả mọi người đều ở trên cùng một trang. Vì vậy, phân nhánh sẽ rất không mong muốn.

Hiệu suất : lượng dữ liệu được truyền bởi một bộ theo dõi vấn đề khá nhỏ và tất cả các công việc nặng đều được thực hiện trên máy chủ, vì vậy đây không phải là vấn đề.

Quy trình công việc nâng cao (đẩy, kéo, dàn, v.v.): trình theo dõi vấn đề đã có quy trình công việc tốt (và thường có cấu hình cao). Vì vậy, chúng tôi không cần một hệ thống phân tán cho điều đó. Hoàn toàn ngược lại, nó sẽ khiến mọi thứ trở nên khó khăn hơn nhiều, vì bạn phải đối phó với những thay đổi mâu thuẫn.

Khả năng ngoại tuyến : chắc chắn, những điều này sẽ tốt đẹp. Tuy nhiên, những thứ này cũng có thể có mà không được phân phối đầy đủ.

Hơn nữa, kiểm soát nguồn (phân tán) được sử dụng hầu như chỉ bởi các lập trình viên. Theo dõi vấn đề cũng được sử dụng bởi người thử nghiệm, nhà thiết kế, nhà văn kỹ thuật, nhà quản lý, tiếp thị và đôi khi cả người dùng cuối. Những người ít hơn không có nền tảng khoa học máy tính có thể gặp khó khăn để hiểu được sự phức tạp của một hệ thống phân tán.

— oefe
nguồn

Tôi tưởng tượng theo dõi vấn đề phân tán để làm việc như một máy chủ, giống như git. Tôi hy vọng các nhà phát triển sẽ sử dụng nó, với thiết lập cục bộ (có khả năng ngoại tuyến đôi khi) và những người khác chỉ sử dụng nó từ máy chủ trung tâm. Bạn có nghĩ rằng giảm nhẹ một số mối quan tâm của bạn?

— Billy Moon

Tôi không nghĩ rằng xung đột hợp nhất sẽ là một vấn đề lớn, vì mỗi mục mới trong một vấn đề sẽ được kèm theo dấu thời gian, do đó, xung đột hợp nhất sẽ được giải quyết dễ dàng (tự động bởi chương trình) bằng cách sử dụng các dấu thời gian này. Tôi không mong đợi nội dung hiện tại sẽ được thay đổi nhiều. Bạn có nghĩ rằng điều này là thực tế?

— Billy Moon

Những người khác có sử dụng theo dõi vấn đề trước khi có repo để chia sẻ mã - hoặc trước khi repo được sử dụng để theo dõi mã?

— Billy Moon

Tôi tưởng tượng đối với các dự án / công việc tư vấn nhỏ, sẽ rất hữu ích khi có thể thêm theo dõi vấn đề vào dự án theo cách phân tán. Sau đó, nó tự động trở thành một phần của kho lưu trữ dự án và cũng giúp dễ dàng có một số hình thức theo dõi vấn đề tại chỗ, mà không cần quản lý nó như một thực thể riêng biệt. Bạn có thấy đây là một lợi ích tiềm năng?

— Billy Moon

Tích hợp chặt chẽ với VCS, sẽ cho phép trình theo dõi vấn đề dễ dàng được cập nhật. Nếu tôi mã hóa một cái gì đó trong khi ngoại tuyến, tôi có thể cập nhật trình theo dõi sự cố tích hợp - có thể đóng một vấn đề - và sau đó khi tôi được kết nối lại, tôi đẩy tất cả các thay đổi vào mã và các vấn đề cùng nhau. Bạn có nghĩ rằng điều này là thực tế / có vấn đề / hữu ích?

— Billy Moon

Tôi không nghĩ việc phân cấp cũng quan trọng như có khả năng ngoại tuyến. Tích hợp với kiểm soát nguồn là một lợi ích lớn, vì vậy bạn muốn mỗi người dùng có thể xử lý thuận tiện cả hai tác vụ. Họ càng làm gần nhau thì bạn càng có nhiều sự liên tục.

Ngay cả các nhóm phân phối nhất cũng có thể kết hợp một máy chủ web và hệ thống theo dõi. Sẽ có lợi hơn khi có một trình theo dõi lỗi trung tâm vì mọi người dùng chỉ cần một tập hợp con của cơ sở dữ liệu lỗi. Lỗi thường được gán cho một người có thể làm việc riêng lẻ. Không có gì sai khi không có sẵn cho những người khác nếu nó sử dụng một loại hệ thống "thanh toán" khiến nó ở trạng thái chỉ đọc. Một trang web cũng cho phép khách hàng / người dùng nhập và xem vé của riêng họ.

Bạn đang gặp phải vấn đề gì đó với nhu cầu ngoại tuyến, nhưng nhiều vấn đề bạn đã giải quyết có thể tránh được chỉ bằng cách kiểm tra các phần của trình theo dõi lỗi để xử lý trong khi ngắt kết nối.

Đối với nhiều người dùng, một trong những công cụ tích hợp tốt nhất là email đặc biệt là khi bạn có những người bên ngoài nhóm. Tôi sẽ không quay lại trang web của bạn để xem vấn đề của tôi đã được giải quyết chưa. Tôi muốn một email với một liên kết trả lời có thể để cung cấp thông tin phản hồi. Bất kỳ nhà phát triển nào trả lời email yêu cầu thay đổi, đều có thể gửi trả lời và theo dõi nó trong hệ thống.

— Jeff
nguồn

Đối với tôi, điều hợp lý nhất là bao gồm các vấn đề trong VCS dự án, để tất cả các vấn đề đều có sẵn và đó là vấn đề báo cáo để trích xuất các vấn đề có liên quan. Tôi nghĩ rằng chi phí trên repo là chấp nhận được, bạn nghĩ gì? Đối với một máy chủ trung tâm, tôi tưởng tượng một hệ thống sau git, nơi nó đang được triển khai, được phân phối hoàn toàn, nhưng bạn có thể tự do lưu trữ nó trên một máy chủ mà bạn gọi là trung tâm (ví dụ như github). Có suy nghĩ gì không?

— Billy Moon

Các vấn đề tích cực là những vấn đề có liên quan. Không chắc chắn bao lâu trong lịch sử tôi sẽ muốn cơ sở dữ liệu lỗi cục bộ của tôi đi. Tôi với bạn ở trung tâm tương tự như github. Tôi chỉ nghĩ về phần theo dõi lỗi như là một danh sách việc cần làm được liên kết với mã chứ không phải là bản sao của toàn bộ cơ sở dữ liệu.

— JeffO

mối quan tâm đó bắt nguồn từ vấn đề sàng lọc thông qua dữ liệu không liên quan? hoặc từ quan điểm của không gian lưu trữ?

— Billy Moon

@BillyMoon - Tôi không nghĩ việc lưu trữ cũng là một vấn đề như thời gian để đồng bộ các mục theo dõi của mọi người. Nó có thể không phải là một vấn đề lớn, nhưng tôi vẫn đặt nó trong bối cảnh theo dõi cuộc gọi phân tán so với chỉ thực hiện một mục vào một trang web.

— JeffO

Tôi sẽ thực sự cụ thể về các sản phẩm thực tế. Một số có thể sẽ thích điều này và những người khác có thể không, nhưng ở đây đi:

Tôi đã sử dụng một loạt các công cụ trong nhiều năm để theo dõi vấn đề, nhiệm vụ và dự án. Microsoft Project, Trello và Jira đều đã có vị trí của mình.

Bây giờ tôi sử dụng Pivotal Tracker. Tôi yêu sự tinh tế nhưng đơn giản trong sử dụng và tôi thực sự thích cách mà những người khác chỉnh sửa và cập nhật vé, những thay đổi đó cũng được thực hiện và làm nổi bật trong cửa sổ của bạn, vì vậy nó là loại công cụ 'mạng' tốt nhất mà tôi ' Đã thử.

Không hoàn toàn chắc chắn nếu đó là những gì bạn có nghĩa là phân phối, nhưng bạn đi.

Nếu có, tôi sẽ quen và sau đó xem xét các thiếu sót của Pivotal Tracker (nếu có) cho bạn trước khi phát triển một giải pháp thay thế.

— Michael Durrant
nguồn